Enhancement idea: "Directed Assignments". Allowing teams to set next (return or onward) assignment; preventing partial resolutions

[Berto2002]

Pre-amble: Obviously we are always looking to capture our working practices in BPMs to 'automate' the flow between people and teams....

Reality: But still most requests, and some incidents, are things we have not coded for so they are just 'tickets' that get assigned from one team to another and then resolved.

Problem statement: we very often find that Team A needs to assign to Team B for work to be done but that the ticket must then come back to Team A or go onward to Team C before it is resolved. The only way to do this is by adding notes which go into the Timeline and thus get forgotten. Net result: Customers get partial resolutions & we get re-opened tickets to finish the job; or we spend a lot of time explaining, chasing or watching what others are doing to 'catch' them.

Solution: What I am after is a way for my teams, who can usually see this very basic "next step" workflow after triage, to be able to make that happen on a ticket-by-ticket basis. I can then use that as a way to get ideas on which types of tickets need BPMs configured to take-over from repeated manual assignments like this.

Suggestion:

• An option, on assignment, for Team A to dictate/suggest what must/should happen to the ticket after Team B have done their work
• It's a checkbox option or radio button with two options: "Require Return Assignment" or "Require Onward Assignment" (with a choice of team). You could even make this one option of "Require next Assignment" (with choice of team) and if you want return you just list your own team
• For that to be enforced by reminding Team B of this requirement should they attempt to Resolve
• For this status to be displayed somewhere suitable like an system-generated Notice or a flag in the Information box

Example 1:

• Service Desk need Infrastructure to update something on AD for a User but then Sdesk need to use that data to do something for the user
• Service Desk assign it to Infra with the flag set to "Require Return Assignment"
• Infra do the work and instinctively go to resolve it but are reminded to send back to Service Desk
• There could even be a button to "Assign as Required" to make it quick
• Service Desk get the ticket back and do their work and resolve

Example 2:

• Security need applications team to alter a config setting in the app but they then need Service Desk to check if that allowed their access before resolving
• Security assign it Apps with the flag set to "Require Onward Assignment" and they select Service Desk
• Apps do the work and instinctively go to resolve it but are reminded to send onwards to Service Desk
• Apps have just spoken to Service Desk and know it worked so they over-ride the warning and resolve it anyway

[HHH]

An alternative solution that we are currently testing is to have the BPM create a linked ticket and then adding a "wait for linked requests completion node" in the original BPM. Then Team B has their own ticket to work with.
I suspect this can be done in parallell too if there are also a Team C and D involved but we don't have anything like that yet.

[Berto2002]

@HHH do you use a Custom Button / Autotask to spawn these additional tickets as it could be at any time in the lifecycle so cannot prescribe in BPM? It helps with half the issue (allows a return) but not the other (onward). It also means there becomes more than one ticket reference for a customer issue and that bothers me that it could get messy if it itself gets banded around and spawns another...

[HHH]

@Berto2002No we don't use a custom button since in our case where we use this process is very static and clearly defined.
We also set the analyst as customer in the linked ticket since in this case it's a matter of what the other department needs to do for "me" so I can fulfil the requests of my customer. That way my original customer's portal won't get cluttered.

[Steve Giller]

1 hour ago, Berto2002 said:

It also means there becomes more than one ticket reference for a customer issue

It shouldn't, in the scenarios you describe the main Request is for the Customer, any internal Requests you need to raise with another Team/Department are your concern (e.g. the Parent Request Owner becomes the Child Request Customer) and the Customer should remain unaware.

A good analogy would be sending your car for repair - if the garage needs to order parts or send it to the welders, you don't get purchase orders, delivery notes, bodyshop bookings etc, you just get an eta for completion.