Managers often want to have a better understanding of where a ticket has been in terms of which Ticket Statuses have been used on a ticket. For example, you may want to know if a Ticket has ever been Waiting Customer or Escalated.
There are four ways to solve this:
- Autotask Data Warehouse. This is a SQL data warehouse that is roughly one day behind, but provides you with very rich reporting. The caveat is that you must use SQL reporting tools — this won’t show in your Autotask dashboards.
- Ticket History. This is a very underutilized button on every Ticket/Task (and Contact). It will show you every change of a Ticket, including status, and who prompted that change. The negative here is that it’s entirely tactical — you can’t properly manage using this feature.
- Ticket History via API. You can access the Ticket History via the REST API. This gives you the same rich reporting as the Autotask Data Warehouse but the data is current as you are accessing your “live” database. But, also like the Autotask Data Warehouse, the reporting won’t be integrated into the Autotask Dashboard.
- Track using UDFs and WFRs. You can create UDFs and Workflow Rules (WFRs) to trigger when certain statuses are used. This won’t be as granular as the approaches above, but it has the awesome benefit of resulting in Dashboard-ready data!
Track Using UDFs and WFRs
Of the four above, let’s decide to stay “inside Autotask” so that we can use Autotask Dashboards. This allows our managers to manage by exception and only worry about Tickets that have gone into a Ticket Status that warrants attention.
Let’s assume we have these categories of statuses:
- Escalated. Any ticket that has been escalated from one person to another, however that looks.
- Waiting Customer. Any ticket that has waited on a Customer for any reason.
- Waiting Other (parts, vendors, etc). Any ticket that has waited on something other than the Customer.
- Worked. Any ticket placed in a status where a tech should have done some work on it (useful to track vs when a ticket is fully resolved via automation, etc).
We could track EVERY ticket status, but that’s unwieldy and often doesn’t provide extra value. Typically, you just want to manage your categories of statuses.
So create these Ticket UDFs:
- Status – Escalated. Type: List (Single Select). Values: Yes, No
- Status – Waited Customer. Type: List (Single Select). Values: Yes, No
- Status – Waited Other. Type: List (Single Select). Values: Yes, No
- Status – Worked. Type: List (Single Select). Values: Yes, No
Next, create a WFR that triggers when the appropriate status is set. Be sure to use smart logic on this. Generally, you want the WFR to trigger like so: If UDF is NOT set to Yes and Status is <??> then UDF = Yes. By doing it this way you ensure the WFR triggers even if the UDF is null/empty vs No.
Like so:
Do this for each category. Notice that I am using an In List vs an Equals. This allows me to select every Ticket Status that belongs within a status category.
Once you do this, after a few days you’ll start seeing patterns in tickets. Which tickets tend to Waiting Customer? Helpdesk or NOC? That one is pretty obvious. But what if you find that NOC actually has a higher % of Waiting Customer? Does your team wait for a customer to approve a reboot of a laptop or server to push out a patch or fix? Is that delaying NOC tickets?
Questions like the above can help you streamline your support process, remove obstacles, and better improve efficiency (and profit).
