Why Your Autotask Ticket Routing Issues Are Probably a Configuration Problem (Not a People Problem)

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.

The Automation Gap Most MSPs Never Notice

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:

• Workflow rules that never fire because conditions were set up against field values that changed when someone updated a picklist six months ago.
• Notification templates that go to resources who left the company, so nobody gets paged when a P1 hits the queue.
• SLA assignments that default to a generic tier because nobody mapped issue types to the right SLA at setup.
• Incoming email processing that dumps everything into one queue with one priority, regardless of subject line keywords or sender domain.

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 Are a Routing Engine. Most MSPs Use Them as Labels.

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:

• Exposes integration-specific user-defined fields (UDFs) on the ticket
• Assigns the ticket to the correct queue automatically
• Sets priority and due date as required fields so they can't be skipped
• Routes to the right resource or resource group

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:

1. Define ticket categories for each major source and type (manual, email, RMM, security alerts).
2. Create API-only categories for integration sources.
3. Map issue types and sub-issue types to categories in your workflow rules.
4. Assign SLAs at the category level, not just the contract level.
5. Build escalation rules that fire when category + time threshold conditions are met.

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.

Misrouted Tickets Don't Just Frustrate Technicians. They Kill Margins.

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 wrong work type gets logged, which affects billing rates.
• Time entries get created under the wrong contract, which breaks billing logic.
• Tickets get resolved without time entries because the technician didn't realize it needed to be tracked.
• Billable time disappears quietly, never to be recovered.

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.

A Practical Autotask Routing Audit Checklist

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.

1. Audit Your Queues

• Are queue names and purposes still accurate for your current service structure?
• Does each queue have an owner or notification rule assigned?
• Are there tickets sitting in queues with no assigned resource and no escalation rule?

2. Audit Your Ticket Categories

• List every active category and document what it's supposed to represent.
• Identify which categories are used by integrations vs. manual ticket creation.
• Determine which integration-created categories should be converted to API-only.
• Verify that category configurations expose the correct fields for each ticket type.

3. Audit Your Workflow Rules

• Open each active workflow rule and verify the trigger conditions still match your current field values and picklist options.
• Check that notification recipients are current employees with the right roles.
• Identify any rules that haven't fired in 30+ days (these are probably broken).
• Confirm that SLA assignment rules cover every combination of issue type and ticket source you actually use.

4. Audit Your Issue Types and Sub-Issue Types

• Are these still mapped to the right queues and priorities in your workflow rules?
• Do your technicians use them consistently, or do most tickets come in with generic issue types?
• Inconsistent issue type usage is usually a sign that the options are either too complex or not trained.

5. Audit Approve & Post Labor Items

• Run a 30-day report and look for labor entries with missing work types.
• Look for tickets with zero time entries that were closed as resolved.
• Identify tickets where billing was manually adjusted to zero after the fact.

6. Audit Incoming Email Processing

• Verify that each mailbox routes to the correct queue with the correct default category and priority.
• Check that ticket creation failure notifications go to someone who will actually act on them.

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.

What to Fix First

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.