REQ vs RITM Best Practices

[adamrauh]

Hey all,

I understand the answer will always be, 'do whatever works best for your organization' - but I was wondering if anyone has any experience and/or best practices of working with the service catalog at the RITM level vs. the REQ level.

I recently gave an initial run-through of our opening Service Catalog offering, and the feedback I got from my techs were, 'Why do we need a REQ # when we'll be working at the RITM level' (right now we're not using tasks, though theoretically that would still not apply to the above as it's a layer down).   I explained to think of things from the user's perspective, and that the REQ was the "shopping cart", and the RITM's were the individual items in the shopping cart, waiting to be fulfilled.

Their feedback was, OK...but then since most of our requests are one for one's (one item requested at a time...rarely more), why not just give the the user the RITM (or multiple RITM's if multiple item's are ordered) vs. 1 REQ, because otherwise they have to manage and provide notes/input at the REQ and RITM level.

Most of their feedback stems from previously only working w/ Incidents, where there is only just 'an incident', not multiples combined together, and they view the REQ as unnecessary overhead that could skew reports or slow down throughput since it's something else they have to keep up with.

I was wondering if anyone else has ever dealt with this as well, and/or found it advantageous to drive their workflows off of multiple RITM's vs. (1) REQ ---> (multiple) RITM's.

[marcguy]

As most others say here, you can stay away from the requests themselves by just ensuring they are shut down automatically when the items are complete so your technicians don't have to waste time filling in that REQ record.

Even go so far to hide/ignore it but as others have warned, I wouldn't remove it.

Marc

[Dlam]

I dug out this aged thread, hoping this is still a relevant topic after a decade.

Similar to some of the previous comments above, we work in our ServiceNow instance basically with no attention to REQ (sc_request).

Customer raise a service request via Service Portal -> created a REQ which subsequently created a RITM (sc_req_item) with SCTASK (sc_task) generated as built in catalog builder.

Customer receive an email notification on RITM opened, agents received email notifications on RITM assignment, comments added, etc. 

Agents work on SCTASK then closed all tasks which will close complete the RITM.

Customer receive an email that RITM is closed complete.

The only unusual thing is that customer also receive an email that REQ is completed.

I was not around when the above workflow and practice wer introduced.

Recently, I received a request to have this whole practice reverted to OOB (although I am not even sure if this is OOB): Customer raise a service request on Service Portal to create a REQ then multiple RITM are created with no SCTASK created.

Is this a better practice?