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.
Queue Architecture Determines More Than Where Tickets Land
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:
- Visibility: Technicians can only work tickets in queues they've been explicitly assigned to. If a ticket lands in a queue with no assigned resources, it sits there invisibly until someone stumbles onto it.
- Assignment eligibility: Workflow rules that auto-assign tickets depend on queue membership. If your top-level engineer isn't assigned to the incoming triage queue, your automation skips them entirely.
- SLA inheritance: Tickets pick up SLA targets based on how they're routed. A misconfigured queue can silently strip SLA tracking from tickets, making your compliance numbers look better than they are.
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.
The Security Level Trap That Looks Like a Staffing Problem
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:
- All: The technician sees every ticket in the system.
- Mine + Organizations: The technician sees tickets assigned to them or tied to their accounts.
- Mine: The technician only sees tickets where they are a primary or secondary resource.
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.
Lines of Business Are Not Optional Decoration
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:
- Ticket search results pull across all client segments, making it harder for technicians to filter to relevant work.
- Billing visibility gets muddled when tickets from different service tiers land in the same queue.
- Backlog reports show aggregate numbers that hide which segment is actually causing the pile-up.
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.
The Queue Audit Every MSP Should Run Quarterly
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.
What Good Queue Architecture Actually Looks Like
To give you a concrete target, here's what a functional queue structure typically includes:
- A triage/intake queue with at least one designated owner and broad technician visibility, where all new unclassified tickets land before routing.
- Tier-specific queues (T1, T2, T3 or equivalent) with resource assignments matching actual technician skill levels.
- LOB-aligned queues if you serve multiple client segments with different service terms.
- Escalation queues that workflow rules can push tickets into when SLA thresholds are approaching.
- A monitoring alert queue that's actively reviewed, not just a landing zone for RMM noise.
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.
Fix the Architecture Before You Hire More People
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.