Detect bottlenecks by automating the count of ticket reassignments/reopens

[#1]

Hello, community!

Would you like to find out an automation trick to make your life easier? Hopefully, the answer is yes, because today I’ll share a good life hack with you. You can configure a rule that counts how many times a ticket was reassigned or reopened and how many times any custom field was changed. 

Why dive into automation here? Because reassignment and reopen counts are essential metrics for business. They help you see whether issues get to the right people and understand the efficiency of every team that works on a ticket. You can use this knowledge to improve your business processes and determine bottlenecks, if any.

Of course, to detect anomalies, we need to understand what’s the regular count of reopens and reassignments. It heavily depends on a particular process and team. For instance, to fulfill a request for regular equipment replacement you are most likely to engage one assignee and close the ticket within a day. However, if your customer, for example, has a 25-step workflow with a complex process and several responsible agents, it would be normal to have 5-7 ticket assignees. So, there is no one-fits-all metric, but keeping track of reassignments and reopens helps control processes and find room for improvement. 

I’ll provide you with one extreme example. Our team once encountered a case of up to 100 reassignments of one ticket – that was a sign for our customer to investigate what was going on. But what could be the cause of the problem? Here are some examples from my experience:

1. Low employee motivation, unclear tasks, or unrealistic deadlines for task completion can lead to a ticket circling from one engineer to another
2. There could be a problem with ticket categorization and classification. If the first level of support incorrectly categorizes the ticket, it takes more time for it to reach the necessary team. This could indicate the necessity to change processes or provide additional training for the team 
3. One complex task may require input from different specialists and therefore the number of reassignments can grow, making it difficult to keep track of SLA fulfillment. In this scenario, it makes sense to break a big, complex task into several small ones
4. Similarly, an overcomplicated business process can also lead to an increase in task reassignments and difficulties in keeping up with SLAs. It may damage relations with customers. The solution lies in reviewing the processes, simplifying them whenever possible 

Now let’s see how you can achieve visibility into the above-mentioned data with automation. Say we have a custom field “Assignment team group” (side note: you can find out more about the value of group-based assignments here). And we want to know how often a specific ticket was reassigned. Firstly, let’s add a new custom field, called “Reassignment count”. It will contain the number of reassignments. The field type is “Number field”, and the default value is zero.

Then we create a new automation rule.

The trigger is a changed Field value.

We calculate all changes when the Assignment team group is set. So, we add “Assignment group” as a field and change it from “Change types” to “Value added”. The rule is triggered whenever the “Assignment group” field is changed but not if it’s clear.

Then, optionally, we can add conditions related to issue types. After that, actions related to the Assignment team group are calculated by adding 1 every time the Assignment team group is changed:

{{#increment}}{{issue.Re-assignment count}}{{/}}

Voilà! Now we know how often the Assignment team group was changed and can use this information for planning, reporting, and other management tasks. We utilize the filter below to quickly see all tickets that were reassigned many times:

Project = "A" and issuetype = "[System] Incident" ORDER BY cf[10300] DESC

where cf[10300] is Re-assignment count.

To track any custom field changes in the same way — for instance, to calculate how many times a task was reopened — we just apply the same rule. In the scenario of counting the number of reopens, we check the “Resolution” field to see if it was cleared. The action is:

{{#increment}}{{issue.Re-open count}}{{/}}

where Re-open count is a custom field. The field type is “Number” field, and the default value is zero.

The same principle works for counting the number of changes made to any field that is important for business, whether it’s your or your customer’s: Assignee, Issue type, Request Type, etc. Generally, managers know the average number of changes made to tickets, so they know when it’s time to investigate what leads to the increase. 

How do you deal with situations when certain tickets are often reassigned or reopened? Have you encountered any extreme metrics with your tickets? Share your stories in the comments, please.

All the best!

[Jack Brickey]

Thanks for the article @Natalya Ozhigova . Indeed keeping a count of various workflow events is a useful Automation task. Another thing I have used in addition to the count is a "why" custom field (either select list or text field) that is required on certain transitions, e.g. reopen. The select list is of particular use since metrics can be assessed. Thanks again for sharing your learnings with the Community!

[Natalya Ozhigova]

Hi @Jack Brickey Thanks for sharing your experience. It's a good idea to add a select list field with the most common cases why the ticket is reopened. Initially, it can be just a required comment.