How to Leverage Ticket Categories in Autotask – SOP
What a waste! Most MSPs are not fully using the Autotask PSA software that they pay big bucks for. Nor are they using the software to drive MSP procedures. For example, Ticket Categories are so useful in driving MSP Service Delivery efficiencies and yet go unused or misused.
Want another pair of eyes on your Autotask PSA Software to see if YOU are fully using it? We can complete an evaluation that will tell you exactly what you need to fix or improve. Best part? It’s free. Click here to book a call & get started.
The sole reason for creating Ticket Categories was 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:
1) Have someone with System Administrator rights project their laptop to a big screen
2) Log into the Admin module, and navigate to the Service Desk -> Ticket Categories
3) Copy the Standard Ticket Category
4) Rename the Ticket Category to map to the corresponding workflow (Incident & small Service Requests, IMACS > 4hours, Projects, Preventative Maintanence, Procurement, Sales etc.)
5) Go through the General, Detail, and Insight tabs and discuss
a. Which fields are not used, and hide them
b. Which fields are used a little, move them to the bottom, if they’re a moveable field
c. Which fields used 1st, 2nd, 3rd,, etc. and order them accordingly
6) Review the hidden fields to determine if any are needed
a. If so, move them into the visible area
b. And place them where needed in the engagement process workflow
7) 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:
1) Manually (best done when the ticket’s in Triage)
2) Workflow Rules (WFRs) based on fields modified in Triage
a. Assigned Resource
b. Queue
c. Issue/Sub-Issue
3) 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 we’re 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.
Want another pair of eyes on your Autotask PSA Software to see if YOU are fully using it? We can complete an evaluation that will tell you exactly what you need to fix or improve. Best part? It’s free. Click here to book a call & get started.
- Steve and Co
