You should be updating your issues/subissues on a regular basis in Autotask. In this blog, I’ll discuss when you should update them and, as important, how to update them so that you don’t lose important information but you also reduce issue type bloat.
When Should I update my Issues list?
The largest group of Autotask shops create a large list of issues and subissues and then live with those forever. The second largest group of users will constantly add subissues and try to parse out every possible detail in their helpdesk. The third group, the smallest group, sits between these two camps and follows a much easier road: quarterly or semi-annual updates as their customer base and tech stack changes.
In general, the issues list won’t change often. Those are broad categories most often like: New Installs, Repairs, Alerts, Recurring, etc. Where most changes happen are the subissues. And subissues are where you should most align with your business. For example, if you mostly focus on cloud-enabled customers, then your Hardware Repairs issue may have very few subissues. Perhaps as limited as Repairs:PC and Repairs:Network. But in that situation, you may have a lot more under your Software Changes issue, such as: SharePoint Online, Teams, Azure Hosted VMs, etc. Because of that, you may update your Subissues for that category every few months as Microsoft and Google adjust their own offerings.
Side note: The best way to look at Issues and Subissues is not “how do I best track my cost” but “how do I best route the ticket to the right person?” (Rocketship customers typically use issues/subissues to route to various escalation teams via Rocketship in fact.) The cost component is important but secondary when it comes to how you really get productive with your staff when it comes to Issues/Subissues.
How should add new issues/subissues?
First, do not reuse old issues/subissues. The reason is that Autotask, like pretty much every app out there, tracks the issues/subissues by ID. So you can rename them all you want, but they are attached to the same tickets as before. So if you change Repair:Printer to Duo MFA Setup, that is going to lead to VERY poor reporting of historical data.
That said, sometimes it does make sense to rename or merge issues/subissues. For example, you may have started with overly complex options and decide later on that it makes more sense to have fewer categories. In that situation, here is how you “merge” them:
- Decide on the new name and update the issue/subissue
- Rename the old ones as OLD_issuename.
- In Ticket Search, find all tickets where Issue=OLD_issuename
- Use the Forward feature (you can do up to 100 tickets) to update the tickets to the new issue.
Once all tickets are “detached” from OLD_issuename, you can go into Autotask Admin and delete it. You can’t delete it before then because, well, it’s in use.
When should I disable vs delete issues?
You should disable issues when you want to retain the information they provide for historical reporting. Also, sometimes merging issues/subissues is too painful (perhaps you have several thousand tickets), so disabling the legacy issue will make more sense in that situation.
Disabling issues/subissues merely removes them as an option in the dropdowns. It does not hide them in existing tickets or reports.
