RITM VS Catalog task when working a Service Request

[bcrose623]

I would like to know what people are doing when it comes to Service Requests and how you handle the ticket management. 

In my old company, we created the Service Request (REQ) which would create the Requested Item (RITM).  The RITM was where we updated the ticket as we completed the work.  We would only create a Catalog Task/s if the Request Item required more than one team to complete some work for the original request.  So then multiple Tasks could be created if needed. When the Request was completed the RITM was updated and closed.  If there were any TASK's those would need to be closed before the RITM could be closed.

In my new company, there would be a Service Request (REQ), which would create a Requested Item (RITM) and then they would automatically create a Catalog Task (TASK).  Who ever the assigned to was, would update the catalog task and when they finished the work would close out TASK which should/would automatically close out the RITM ticket.  Assigned to person was not able to create additional TASK tickets to complete the work.

I am looking for input from folks as to one, which way listed above is a better "best Practice" or what your company does to complete Requests.  Does anyone have there instance setup to either of the ways described above or if you have a different way.  Responses will help move us forward to make the user experience better for those who are working tickets.

If you have any questions for need more clarification let me know.  Thanks.

Brian

[Jan Cernocky]

Hi Brian,

I admit the structure of the request fulfilment is not ideal. In my previous company, we had all 3 levels - REQ/RITM/SCTASK whereas we somehow ignored REQ (pointing user to RITM only, including notifications, etc.), used RITMs as the record facing user and SCTASK to do the actual work. 

If you look at out of the box, you notice that RITM only contains additional comments, no work notes (user facing) + it does not even contain assignment group and assigned to in the OOB layout, ... SCTASK only contain work notes (internal comments) + the assignment details.

I would suggest sticking to this scenario, although it will be in most of the cases 1:1:1 relationship between REQ:RITM:SCTASK. Sooner or later you will discover some hick ups if you customize that will be costly to redesign.

We tried to experiment and initiate email communication with user on SCTASK level but when we introduced portal, we found out the widgets are simply designed the way user sees RITM, not SCTASK. It involved a lot of burned hours to somehow make it work and in the end it was still not ideal. And there were other topics we had to address but I guess you get the point.

[bcrose623]

Jan,

You mention that in OOB the RITM only contains additional comments.  Is that for the portal view or in the RITM form?  As I am looking at my personal instance, I see both work notes and customer facing notes as OOB for just about every OOB service request on the form.

As for Assignment group, in the old company we just added Assignment group and assigned to to the form.  What I have seen in the OOB service request on personal instance is that most do not create the TASK when the service request is submitted.  It only creates the REQ and RITM.  The only time I have seen a task created is if there were multiple teams ask to perform work to complete the request (example: install software).

Thanks for your response.

[Jan Cernocky]

Is there a chance you played with the layout in the past? I have fresh Quebec and it is as I written and I am pretty sure it was always like that in OOB. I am talking about the backend form view.

When you submit a request, most of the OOB workflows include approval so no task is created unless the RITM is approved (some actually have approval on REQ level as well - e.g. 'Service Catalog Item Request').

[bcrose623]

Jan,  we did modify the layout of the backend form that the person the ticket is assigned to sees.  Your second statement actually helps answer my question.  Most OOB service requests do not create any Tasks unless they were created to have multiple Tasks required, Like the "Install Software" request.  That one has two tasks created by default.

Thank you for your input!!