Looking for guidance on how best to use REQ, RITM and SCTASK.

[bostonsnow]

Hello,

We went live with SNOW in May and the biggest pain point across the board by far has been using the Service Request module, specifically how to use REQ, RITM and SCTASK. The 3 record system is causing major confusion across the requestors, fulfillers and even the admins.

Requestors track their Service Requests on the Service Portal via the RITM record. However, request fulfillers work out of the SCTASK. If they have all the required information, they fulfill the request and close the SCTASK which we have set up to auto-close the RITM and REQ.

However, there are situations where there is 2 way communication required between the fulfiller and the requestor. Currently, when this situation arises we have the fulfiller post their message to the Additional Comments field on the RITM. The requestor then replies and the response is posted back to the RITM. The issue is that this requires the fulfiller to monitor 2 records (RITM and SCTASK) for one request.

The problems I am trying to solve are:

        1. Ensure fulfillers only need to work out of one record for a request.

        2. Ensure fulfillers can have a 2 way conversation with the requestor from this one record.

I am considering adding the Additional Comments field to the SCTASK form and have these comments auto-post to the RITM so they are visible to the requestor. However, when the requestor responds their reply gets posted to the RITM and the fulfiller would then need to check the RITM. Should I then have the reponse posted to the SCTASK? I feel like we are bending over backwards and applying excessing custom configuration just trying to make this 3 record request model work for us.

Has anyone else run into this situation? If so, how do you resolve it?

Any guidance here would be greatly appreciated.

Thanks!

Mike

[Chuck Tomasi]

Hi Michael,

This is often confusing to new people. I dealt with it as a customer years ago. It is meant to be scaleable and flexible, but often just confuses. The best explanation I came up with was to have them think of the Request as the cart. The request items are what you put in the cart (tied to a common parent) and the tasks are for workers to carry out to fulfill the RITM.

Most commonly, there's only one RITM to one REQ, so most people don't find the value until they start doing something like onboarding where a new employee needs a laptop, desk space, phone, business cards etc. 1 REQ, 4 RITM.

The SC task usage is really up to you. Some try to drive all their work from the RITM, until you get in to something that requires a sequential set of steps with different fulfillers.

I would recommend starting with the reporting requirements. What do you need for information to ensure your request process is being completed effectively? What SLAs are there? What do you want to measure (today and tomorrow.) That will help drive your inputs and how you use the three tier structure.

Hope that helps.

[bostonsnow]

Hello Chuck,

Thanks so much for the response. So our integrator set us up to use REQ, RITM and SCTASKs so all of our engineers are working out ot SCTASKs.

Any recommendations for how to configure 2 way communication from the SCTASKs? Our clients use the RITM to track status. We added Additional Comments to SCTASK and we have them copying from the SCTASK to the RITM. However, if the client responds to the comment they are doing so at the RITM level so we are stuck with the engineering having to check the RITM for the update. We considered having RITM Additional Comments post to SCTASK but that would put us in a loop. Any advice is greatly appreciated.

Thanks!

Mike

[dvp]

We have faced a similar issue with respect to the communication between full filler and requester. This is how we approached.

We are pushing the comments only one way (SCTASK -> RITM -> REQ)

Any comments entered in tasks are pushed to requested items and requests.

Any comments entered in RITM are pushed to REQ.

When requester enters comments, based on the stage whether its in approval or fulfillment we send the notification to respective members. i.e.

                  Approval stage -> Comments notification to all approvers

                  Fulfillment stage -> if assigned to is empty then send to all members of a group else send it to assigned to of all the active tasks tied to the RITM

If requester replies to an email sent from task table, then by using inbound action we updated the sc task comments and send an email to only assigned to person and also as mentioned above task comments be pushed to RITM and REQ.

[Chuck Tomasi]

I don't recommend copying every comment on RITM to every child SCTASK (or even just the active ones, because really, do you need to be updated on closed tasks?)

Instead, I would create an event when the requester adds a comment to the RITM that triggers a notifcation to all the assigned_to of the open child SC tasks. This might be best done by first triggering a script action that does a lookup of the active child records, then that script action sends the emails. I don't like doing a lot of record lookups in notification scripts if I don't have to. It seems a bit backwards from a design perspective.

Script actions