Incident and reassignment

Sue L
Tera Contributor

an hour ago

Does anyone do this?  Is it a good idea? We have a new ServiceDesk keen on incident metrics, especially if they pertain to them.  

We are looking for a way to capture the reason for an incident to be re-assigned. Perhaps it's a field on the incident form with a selectable list of 4-5 items (no support info; incorrect routing; no access to fix; etc).

As incidents may get re-assigned multiple times: it's not likely to work well to have a static field at the top of the incident, unless it is able to be used multiple times during the life of an incident (selecting again, inserts the info to the Activity Log or something).

 

Basically need to know if this is something OOB (doubtful) that we could add, or if not OOB, if there is a reasonable way to accommodate it.

0 Helpfuls
  • 72 Views
1 REPLY 1

Kieran Anson
Kilo Patron

20m ago

Hi,

It's not something OOTB but it's a requirement I've seen implemented a few different instances in instances I've come across.  

 

In several of those instances, I've removed the functionality. The idea sounds nice, but what actual benefit does it provide? If there's no close loop process it's just another piece of data your support teams have to populate to get to the point of resolving the ticket. That friction quickly devalues it.

 

Now, in terms of doing this I see two equally valuable options. Both focus on Workspace UI

 

1. Make the assignment group read only and implement a "reassign" declarative action. This produces a model that asks for the new assignment group, and the reason as a drop-down. You can then capture the reassignment details as some form of metric in another table. 

 

2. Allow the assignment group field to be modified, but on change produce a pop up immediately to capture the reason why 

0 Helpfuls