Communication to requestors

[Community Alums]

I'm looking for some input on how best to communicate with users after they submit a request via the Service Catalogue. Incidents are very straight forward, there is one record. There are three records created when a request is submitted:

REQ
RITM
TASK

So, when a technician needs to confirm something with the end user, what is the most ideal record to communicate from? In the case of a single task request item, such as a request for additional access, it would seem feasible to communicate with the user at either the task or requested item level. However, in the case of something like a hardware request, where there are multiple items and multiple tasks, it wouldn't make sense to communicate with the end user and attempt to confirm things about their order at the task level. The inquiry might be regarding the entire order, or multiple items in the order. The idea is also to design a process everyone follows consistently, so if another technician ends up taking over the request, they know where to look for any updates/notes/emails to and from the requestor- they don't need to check down the REQ->RITM->TASK chain to determine what has been actioned. All the pertinent information is in one record.

We don't have multiple levels of tasks to assign like the catalogue is setup to handle out of the box. As in, there is no procurement process or task to check stock or configure items. Users submit requests, and they are assigned to the group who is responsible for fulfilling said request. Aside from Hardware Requests, the majority of our workflows simply make a few checks (approvals, etc), then assign a single task to a fulfillment group to process. There may be instances where we need to verify some information before proceeding with the fulfillment.

We have enabled email client attribute on the sc_task, sc_request, and sc_req_item tables, as well as implemented the email notifications on the task level to trigger notifications to the user and assigned to when additional comments are added (same functionality as the Incidents). I'd just like some input from other admins on how best to approach this.

Thanks!

Tim

[Uncle Rob]

For my part, I just abstract out the request layer.   I know its handy when you want to control approvals on orders totaling over X, but I find those cases are the exception more so than the rule.

That makes coms a lot easier.   Communicate via the Request Item.   In fact, put the Request Item's "Additional Comments" field on the Sc_Task to make it even easier for   your Task executors.

[TrevorK]

We send out the email's based on the Requested Item. Our thought is that, through the Catalog, a Request is a collection of one or more Requested Items. Each Requested Item is really what the client is interested in (new computer, new email account, etc.). Because of this, we communicate with the client at the Requested Item level, as this is what they are concerned with.

Our interpretation is that, to the client, most Catalog Tasks are irrelevant. Those are what take place to complete the Requested Item. Using a new computer as an example, at the end of the day, does it matter that we: ordered the computer, shipped the computer, marked as received in our financial application? No, what matters is that the client received the computer. The behind the scenes processes are strictly that, behind the scenes and not applicable to the client.

We just leave Request alone. Even with having multiple RITMs associated to a single Request, we have never saw the need to communicate in/out of it. In my mind, it is more of a container of shopping cart items and nothing more.

What we have done to allow our technicians to communicate with the client is have a checkbox on the Catalog Task to send the Close Notes to the client. This allows them to communicate specific information to them. But, this is more an exception than a standard practice. Unless there is ambiguity to the catalog item, a simple "Request Fulfilled - New Computer" is often all the client needs to see.

One piece of advice - you may not use multiple Catalog Tasks on a RITM now, but will you in the future? If so, try to bring in a process that will accommodate it now so that everyone has learned it and used it. Since you are having to do a change anyways, might as well might one that can scale out as you increase usage.

[Vladi1]

We are emailing requestors from the task adding assigned user to "cc' and sometimes we would add requester to "work notes list" so they would receive updates