Reporting on reassignment

[jleyco]

Hello,

I'm not sure how to implement this enhancement, if anyone can advise?

The business requirement is:

When a ticket (incident or catalog task) is reassigned from one group to another, they would like to have a reassignment reason (whether it's because it was assigned to the wrong group or because it is missing information). They would like to be able to report on: this "reassignment reason", current assignment group and new assignment group.

[JJ1]

There is a field 'reassignment_count' which stores the number of times reassignment happens.This will help in your reporting for count.For reason,You can add a dropdown menu and can make it mandatory using Onchange script except for new records.

Can someone explain the Reassignment Counter?

[Uncle Rob]

The business is suggesting a solution, not expressing what hurts.
I suspect what hurts is LOTS of wasted time while tickets transition teams.   Is the answer to punish all teams?

What do I mean by punish?

In my Prod instance I had 266 assignments across 15 groups this week.   Lets assume that we implemented your business users' solution and it takes 1 minute to conceive, type, and save the re-assignment reason.

266 minutes of work have been created.

That's 4.4 hours.   That's half a day of human labor, which is a 10% reduction in one staff member's efficiency.

That's just to fill in the reasons.   Who's going to read all these reasons!?

The Problem Needs a Razor, not a Bulldozer

I'd make sure I was measuring the Assignment Group metric (link to wiki included).   I'd then build a bar chart report on task, grouped by Assignment Group that Sums Reassignment Count.   Take the top 3 groups, and run another report for each of those three.   The second report will be off the Metric Instance table (possibly joined to Task in a database view)... configured as a pie chart showing metric instances where the Task's assignment group = <group X of 3> grouped by Instance Value.   You now see the history of assignments on the way to the Groups with the most assignments.

(Note: In my prod instance 40% of all tickets that had a re-assignment were currently sitting in ONE of the 15 teams the total was spread against)

Armed with that information you can start a dialog between the very few groups who are likely at the root of this issue.

And you don't have to cripple performance by having another interrupt/mandatory field.