Before you hire another dispatcher or send your team to yet another training session, consider this: most Autotask ticket routing issues aren't human error. They're baked into how your PSA was set up in the first place. The good news? Configuration problems have configuration solutions.
I've watched MSPs spend months blaming the wrong thing. Technicians get blamed for missing SLAs. Dispatchers get blamed for misrouting tickets. The real culprit sits quietly in your Admin panel, looking completely innocent.
Autotask ships with default settings designed to work out of the box. That's fine when you're getting started. The problem is that most MSPs never revisit those defaults after they've grown past the point where defaults make sense.
The Service Desk automation settings give you control over workflow rules, form templates, notification templates, and incoming email processing. Most Autotask admins configure email-to-ticket conversion once, verify it creates a ticket, and call it done. What they skip is defining what kind of ticket gets created, where it lands, who gets notified, and under what conditions it escalates.
The specific failure modes I see regularly:
Each of these is a silent failure. No error message, no alert—just tickets sitting in the wrong place or aging past SLA thresholds while everyone wonders why the numbers look bad.
The fix starts with understanding that "configured once" is not "configured correctly." These settings need a regular review cadence, not just an initial setup.
Ticket categories control what fields and tools are visible on a ticket. Most MSPs use them to make the interface look cleaner for different ticket types. That's legitimate, but it's about 20% of what categories can do.
The ticket settings configuration in Autotask lets you combine categories with queues, priorities, issue types, and sub-issue types into a routing architecture that works without a dispatcher touching it. When a ticket enters with a specific category, it can automatically land in the right queue, carry the right priority, and trigger the right workflow rules.
The part most MSPs miss entirely is API-only categories. These are categories hidden from manual selection, used exclusively when tickets are created via API integrations. If you have tickets coming in from an RMM tool, a security platform, or any other integration, you can create a dedicated API-only category that:
Without this, every alert from your RMM lands as a generic ticket in a generic queue with no differentiation from a password reset request. Your P1 infrastructure alert and someone's "my Outlook is slow" ticket are now competing for the same dispatcher attention.
The architecture that works looks like this:
This is not a complex implementation. It's a planning exercise that most MSPs skip because they were too busy when they set up Autotask and never went back.
There's a financial consequence to routing failures that goes beyond SLA penalties and client complaints. When a ticket lands on the wrong resource, several things happen:
The Approve & Post workflow is where this becomes visible, usually too late. Approve & Post shows you the stream of pending billing items before they hit an invoice. If a ticket was misrouted, the labor entry might show the wrong hours, the wrong rate, or might not appear at all because time was never logged.
The diagnostic question to ask in Approve & Post: Are you regularly seeing labor items with missing or incorrect work types? If yes, the problem almost certainly traces back to how tickets are categorized and routed, not to technicians being careless.
Time tracking configuration compounds this. Autotask time tracking distinguishes between customer-facing time (tracked via work types, feeds Approve & Post) and internal time. If your routing sends a ticket to the wrong queue and a technician resolves it informally without creating a formal time entry, that labor never reaches Approve & Post at all. You did the work. You just didn't get paid for it.
This is the sequence I'd run through if I were auditing an Autotask instance with routing problems. Work through it in order since later items depend on earlier ones being correct.
This audit takes a few hours for a typical MSP environment. The findings usually generate a backlog of configuration fixes that, when implemented, reduce dispatcher workload and improve SLA compliance without any new training or headcount.
Configuration audits tend to surface more issues than expected. Prioritize fixes in this order:
Fix broken workflow rules before anything else. A workflow rule that misfires or never fires is invisible chaos. You have no idea what tickets are being mishandled because there's no error to chase.
Then fix your incoming email processing defaults. If tickets are arriving with incorrect categories, priorities, or queue assignments from the start, everything downstream is fighting upstream garbage.
Then clean up your ticket categories and add API-only categories for integrations. This is where you recover the routing logic that should have been in place from day one.
Finally, verify the billing chain. Run your Approve & Post audit after the routing fixes are in place. Some missing time entries can't be recovered, but the pattern of leakage should stop once tickets consistently land in the right place with the right work type expectations.
The goal is a routing system that handles the predictable cases automatically. Dispatchers exist to handle exceptions, not to manually sort every ticket that comes through the door. If your dispatcher is touching every ticket, your configuration is doing too little work.
Your PSA should be doing more of the heavy lifting. If it isn't, the problem almost certainly has a configuration fix waiting for you in the Admin panel.