How to Use the Ticket Category
Autotask Ticket Categories are one of the most underused features in the Autotask PSAutomation software. The purpose of the Ticket Category is to provide different views for different folks. For example, the fields required and most used for Incidents is completely different than the fields needed for Projects. In the middle are Service Requests. Whereas some Service Requests (Quick Hits and Moves/Adds/Changes less than 4 hours are treated like an Incident, they still need a slightly different list of fields. And while Moves/Adds/ Changes greater than 4 hours or Installations are more like projects, they still do not need the same field view – and that is where Ticket Categories come in best.
Another reason to consider leveraging Ticket Categories more is that they can be a mid-point or trigger in PSAutomations. Read on for more information on how this works.
Or if it would help, please schedule a Ticket Category conversation with Steve Here.
The sole reason for creating Ticket Categories is to provide different views for different folks. For myself, coming from a project coordination perspective, the fields used by Break/Fix are meaningless to me, and the fields I needed most were either buried at the bottom of the ticket or non-existent. For example, Issue and Sub-Issue are critical for Incidents, but meaningless for Projects. What’s critical for Projects is a link to the Opportunity, which is meaningless to reactive work. And the list goes on and on.
But the different views for different folks doesn’t end there. Moves/Adds/Changes may need a different view if over 4 estimated hours. Also, monitoring alerts, preventative maintenance, procurement, and sales if you use tickets to track sales.
I used to think having a different view at each stage of the Client journey would be an advantage. Such as Triage, Level I, II & III support and QC. But having different views is more closely aligned with which of the 11 MSP procedural workflows the Client requests are in than where the ticket is in the MSP engagement process.
7 Steps for a Collaborative Ticket Category Creation Meeting
It takes a collaboration process and a meeting devoted just to Ticket Category creation to know what’s right for any one MSP Service Delivery process. Here are the steps to take in a collaborative Ticket Category creation meeting:
Have someone with System Administrator rights project their laptop to a big screen
Log into the Admin module, and navigate to the Service Desk -> Ticket Categories
Copy the Standard Ticket Category
Rename the Ticket Category to map to the corresponding workflow (Incident & small Service Requests, IMACS > 4 hours, Projects, Preventative Maintenance, Procurement, Sales, etc.)
Go through the General, Detail, and Insight tabs and discuss
Which fields are not used, and hide them
Which fields are used a little, move them to the bottom, if they’re a moveable field
Which fields used 1st, 2nd, 3rd, etc. and order them accordingly
Review the hidden fields to determine if any are needed
If so, move them into the visible area
Place them where needed in the engagement process workflow
Save, and check back in a week for improvement, consensus, and adaptation
Note: Be sure to stay on the workflow topic. So many times, when Advanced Global is leading these discussions, someone will bring up needing a field when they are doing work in some other workflow. Whoever is leading the discussion must be vigilant to remind everyone that the question applies to a different workflow.
Since releasing the Ticket Category, Autotask has floated the idea of using the Ticket Category as a third-level Issue and Sub-Issue. I'd argue there’s some merit to this idea. In leveraging The Tech Tribe's recommended Issue and Sub-Issue list, which is based on a MSPs technology stack, it looks like this:
Ticket Category – Workflow
Issue – Family of Devices
Sub-Issue – Device
Once again, the Ticket Category follows the workflow. By making the Sub-Issue level follow the Technology Stack Devices, the devices can come and go as the Industry, Technology, and MSP change, without needing a total Ticket Category and Issue level refresh.
There are 3 ways to update/change the Ticket Category field in an existing ticket:
Manually (best done when the ticket’s in Triage)
Workflow Rules (WFRs) based on fields modified in Triage
Assigned Resource
Queue
Issue/Sub-Issue
Specified within profile defaults
As a Project Coordinator, most of the tickets I created were for projects. I may have triaged thousands of tickets, but very seldom did I work the phones. Most of my Triage coverage was picking up from the Incoming Email Processing. So, for me, it was best to have my default Ticket Category set up in my profile as a Project Ticket Category. As you can see, Ticket Category usage depends on the individual, team, and MSP. We’re grateful Autotask has the flexibility to accommodate all our unique situations!
While manually setting the Ticket Category is probably the best, we at Advanced Global detest manual processes when they can be automated. To whom the ticket is assigned almost always requires critical thought during the Triage process, which means it can’t be automated. Many have tried to automate the assignment of tickets, but are unaware of a viable MSP process that every MSP could use. We don’t advocate the use of queues and opt instead for use of dashboards and widgets over queues – so using the queue field to automate the Ticket Category selection just doesn’t work in an Advanced Global world.
A combination of assigned resources and status should work.
But at the end of the day, Advanced Global, based on our 31+ years of MSP Service Delivery experience and by working with MSPs from around the world, promotes leveraging the underutilized Priority Field to identify what workflow this Client request is in. If an MSP follows the recommendations, the Priority Field is the best one to use to automate the Ticket Category selective via WFRs.
Schedule a strategy call with Steve Here.
