Most MSPs blame their technicians when tickets pile up. More headcount gets requested. More overtime gets approved. Meanwhile, the actual problem is sitting quietly in Admin, untouched since the day you went live with Autotask: your Service Desk queue configuration.
A poorly structured queue isn't just an inconvenience. It's a funnel that turns every incoming ticket into a routing coin flip, and those flips cost you SLA compliance, client satisfaction, and technician morale.
Here's what's actually happening inside your queue architecture, and what to do about it.
Most MSP owners think of queues as simple buckets: tickets go in, technicians pull them out. The reality is more consequential than that.
In Autotask, Service Desk queue settings control three things that directly affect throughput:
Autotask's own documentation flags this directly: "Make sure at least one resource is assigned to each queue, or tickets placed into it will fall through the cracks." That warning exists because it happens constantly.
The fix isn't complicated, but it requires knowing what you're looking at. Go to Admin > Features & Settings > Service Desk (Tickets) > Queues and check the Active Resource Count column for every queue. Any queue showing zero active resources is a black hole.
Here's a scenario I see regularly: a technician insists they can't find certain tickets. Their manager assumes they're not paying attention. The tickets are sitting in a queue the technician literally cannot see due to security level configuration.
Autotask's Service Desk security settings control ticket visibility at the object level. The relevant permission is the Ticket View setting, which has three states:
If a technician's security level is set to Mine and they're not assigned as a resource on a ticket, that ticket doesn't exist in their world. They won't see it in queue views, search results, or dashboards. The ticket sits unworked. The manager sees a backlog. The technician sees nothing wrong.
This configuration problem looks exactly like a staffing or attitude problem from the outside. It isn't. It's an admin settings mismatch that takes about five minutes to identify and fix once you know where to look.
Check your security levels against your queue assignments. If you have technicians set to Mine ticket visibility who are supposed to be monitoring shared queues, they're functionally blind to half their workload.
Many MSPs set up lines of business (LOB) during initial configuration and then never connect them to their queue structure in any meaningful way. This creates cross-contamination that distorts your backlog reporting.
When you don't map queues to lines of business, a few things go sideways:
If you have separate service tiers (say, managed clients vs. project-based clients), they should have separate queues with LOB associations configured. The lines of business filtering documentation explains how LOB affects search and reporting visibility across the platform.
The practical consequence of skipping this: you can't tell if your backlog is concentrated in one client segment or spread evenly. That distinction matters a lot when you're deciding whether to hire, redistribute work, or renegotiate a contract.
Queue configuration drift is real. Technicians leave, clients change tiers, workflow rules get added without corresponding queue updates, and six months later your queue structure reflects a business that no longer exists.
Here's the audit I'd recommend running every quarter:
Step 1: Pull the queue list
Navigate to Admin > Features & Settings > Service Desk (Tickets) > Queues. Export or review every active queue. Note the Active Resource Count for each.
Step 2: Cross-reference against ticket volume
Use dashboard widgets or ticket reports to see how many tickets flowed through each queue over the past 90 days. Queues with high volume but low resource counts are bottlenecks. Queues with zero ticket volume are candidates for deactivation.
Step 3: Check queue ownership
Every queue should have a designated owner. Owners can be used as dynamic recipients in workflow rules, which lets you build automatic escalation paths. Queues without owners have no one accountable for tickets that fall through.
Step 4: Verify security level alignment
For each queue, confirm that the technicians assigned to it have security levels that allow them to actually see and edit those tickets. This sounds obvious, but it breaks more often than you'd expect after role changes or security level template updates.
Step 5: Review system queues
Don't ignore the three system queues: Client Portal, Post Sale, and Monitoring Alert. These can't be deactivated, but they can accumulate tickets if they're not actively monitored. Client Portal tickets in particular often sit unacknowledged because technicians assume they come through a separate process.
To give you a concrete target, here's what a functional queue structure typically includes:
Every queue should have at least one active resource, a designated owner, and a clear description of what ticket types belong there. The description field in Autotask's queue settings isn't cosmetic. It's documentation for whoever comes after you.
Ticket backlog feels like a people problem because people are the ones dealing with it. But if your queue structure is routing tickets into black holes, restricting visibility through misconfigured security levels, and blending client segments into unreadable reporting, you can double your headcount and still have a backlog.
The quarterly audit above takes a few hours the first time and less than an hour on subsequent runs. The fixes it surfaces are almost always configuration changes, not hiring decisions.
Run the audit. Check your resource counts, security level alignment, and LOB associations. Then look at your backlog numbers again.
I suspect you'll find the problem is smaller than you thought, and also more fixable.