If your techs are constantly asking "why did this land on my queue?" you don't have a people problem. You have a configuration problem.
Autotask's Service Desk automation is powerful, but out of the box it's built to work generically. It doesn't know that your senior network engineer shouldn't be triaging password resets. It doesn't know that your Tier 1 queue is already underwater. It just routes based on whatever rules were set up during onboarding and never touched again.
The good news: most Autotask routing problems have specific, fixable causes. Here's where to look.
The Silent Saboteur: Default Automation Settings That Don't Match Your Business
Most MSPs configure Autotask once during onboarding and move on. The problem is that default Service Desk automation settings are designed to be generic enough to work for any MSP, which means they're not optimized for yours.
Autotask's Service Desk automation settings cover a range of automation features including workflow rules, form templates, notification templates, and incoming email processing. These aren't set-it-and-forget-it features. As your team grows and specializes, your automation needs to grow with it.
The most commonly misconfigured areas I see:
- Workflow rules that assign to a queue instead of a resource. When a ticket hits a general queue, it sits until someone grabs it. If you have specialized teams, tickets should route to the right queue based on issue type, not just land in a catch-all.
- Ticket statuses that don't reflect your actual process. Default statuses rarely match how a mature MSP actually moves work through the pipeline. When statuses are wrong, your workflow rules fire at the wrong time.
- Missing issue types and sub-issue types. Autotask lets you define these for routing, searching, and reporting purposes. If you're using generic categories, your automation rules have nothing specific to key off.
The fix starts with a critical question: when did someone last audit your workflow rules against your current team structure? If the answer is "never" or "we hired three new techs ago," that's your starting point.
API-Only Categories: The Routing Layer Most MSPs Don't Know Exists
This one catches a lot of MSPs off guard. Autotask allows ticket categories to be flagged as API-only, meaning they're invisible in manual workflows but fully active in automated ones.
Per the Autotask documentation on API-only categories: these categories are hidden everywhere you manually select a category. They're only used when organizations, tickets, and devices are created via the API.
Here's a practical example of how this causes problems. Say you integrated your RMM tool with Autotask. The RMM creates tickets via the API and assigns them an API-only category built for that integration. That category controls which fields are exposed, what queue tickets land in, and what priority they get. If you set up that category during the RMM integration and never revisited it, it's quietly routing tickets based on stale logic while your techs wonder why alerts from one client keep landing in the wrong queue.
API-only categories are assigned to tickets in several ways:
- The API creates a ticket and assigns an API-only category directly
- A ticket is imported or updated via the importer with an API-only category name in the spreadsheet
- A ticket created via the API is copied, or marked as Incident with a new Problem created
The tricky part is that these categories won't appear when you're manually reviewing your category list in normal workflows. You have to know to look for them in the admin category management area. Once you find them, audit each one: does the queue assignment still match your team structure? Are the priority and due date settings still correct? Are RMM-specific user-defined fields still relevant?
Incoming Email Processing: Where Triage Goes Wrong Before Anyone Sees the Ticket
A large percentage of MSP tickets originate from customer emails. If your incoming email processing rules aren't configured correctly, you're essentially letting clients drive their own triage.
The Autotask incoming email processing feature automatically converts support emails into tickets. That's enormously useful. But the default settings determine what queue the ticket lands in, what category it gets, and what priority it's assigned, all before a human ever looks at it.
Here's where it goes wrong in practice. A client sends an email with the subject "URGENT server down" to your support inbox. If your email processing rules aren't looking at that subject line and mapping it to an appropriate queue and priority, it gets created with whatever defaults are configured. That ticket might land in a general queue at Normal priority, while your senior engineer sees it three hours later.
The other scenario: a client figures out that certain words in the subject line trigger faster response, so they start writing "URGENT" on everything. Without rules to normalize that, your senior tech's queue fills with Tier 1 noise.
Key things to audit in your email processing configuration:
- Default ticket category: What category does an email-generated ticket get if no specific rule matches? Is that category correctly configured for routing?
- Queue assignment: Are tickets landing in the right queue based on the sender's organization, or are they all hitting one catch-all?
- Priority mapping: Is priority being set by rule, or defaulting to Normal for everything?
- Notification settings: The documentation recommends configuring defaults so the email originator is notified on success or failure. Many MSPs skip this, which leads to clients submitting duplicate tickets.
The Fix: A 4-Point Audit Checklist for Autotask Ticket Routing
You don't need a six-month PSA overhaul to fix most routing problems. Here's an audit sequence you can work through in an afternoon.
Audit your Service Desk automation workflow rules
Go through every active workflow rule and ask: does this rule still reflect how our team is structured? Look specifically at:
- Queue assignments (do these queues still have the right techs?)
- Status triggers (are workflows firing at the right point in your process?)
- Issue type and sub-issue type conditions (are these specific enough to route accurately?)
Review your ticket categories, including API-only ones
Pull up your full category list in the admin area. For each category, API-only or not:
- Confirm the queue assignment matches current team structure
- Check that priority defaults are appropriate
- For API-only categories, verify they still match the integration they were built for
Audit incoming email processing rules
For each configured mailbox:
- Trace what happens to an email that matches no specific rule (the default path)
- Review each rule's conditions and confirm they're still accurate
- Check that queue and priority assignments are intentional, not leftover defaults
Verify queue assignment logic end-to-end
Create a test ticket using each major entry point: manual creation, email, and API/RMM integration. Check where each ticket lands and whether the category, queue, priority, and assigned resource match your expectations. This is the fastest way to find gaps between what you think is configured and what's actually happening.
What Accurate Routing Actually Gets You
Fixing ticket routing isn't just about reducing tech frustration, though that's a real benefit. Accurate routing affects SLA compliance, client satisfaction, and your ability to report on workload distribution.
When a Tier 1 ticket lands on a senior tech's queue, that tech is either working below their skill level or ignoring the ticket in favor of more complex work. Neither outcome is good. When a critical issue gets misclassified at intake and lands in the wrong queue, you're losing response time before anyone even knows there's a problem.
The Autotask ticket settings documentation covers the full range of configurable elements: user-defined fields, queues, ticket sources, statuses, priorities, and issue types. Most MSPs use a fraction of these to their potential.
Automation built on a shaky routing foundation will always feel like it's broken, because functionally, it is.
Getting routing right is foundational. Once tickets are landing where they should, you can build reliable workflow rules on top of that, set SLAs with confidence, and actually trust your queue metrics.
Start with the audit checklist. Pick one area, fix it, and verify the result before moving to the next. Small, targeted changes beat a wholesale reconfiguration every time.
Share via: