Your help desk team is drowning in tickets, but the problem isn't volume—it's your Autotask configuration. I've seen MSPs struggle with ticket backlogs, blown SLAs, and frustrated technicians, all while their PSA quietly sabotages them through misconfigured settings that seemed harmless during initial setup.
These seven configuration issues fly under the radar because they don't break anything outright. Instead, they create friction that compounds over time, turning your help desk into a bottleneck that chokes your entire operation.
Autotask's workflow automation should streamline your processes, but poorly configured rules often do the opposite. The most common mistake? Creating rules that trigger additional actions without considering the cascading effects.
Here's what typically goes wrong:
The fix requires auditing your Service Desk automation settings and mapping out rule interactions. Look for rules that fire simultaneously on the same triggers—these often conflict or duplicate effort.
Quick audit checklist:
Document every active workflow rule and its triggers
Test rule combinations with sample tickets
Remove redundant notification rules
Add conditions to prevent rule conflicts
Your routing logic might look perfect on paper but fail spectacularly in practice. Most MSPs configure routing based on skillsets or contract types while completely ignoring current workloads and availability.
The typical scenario: Your Exchange expert gets every email-related ticket because the routing rule checks for keywords like "Outlook" or "email." Meanwhile, they're already juggling a server migration project, so those tickets sit in their queue for hours while other technicians handle easier issues.
Common routing problems:
Rules that only check skills, not availability
No priority weighting in assignment logic
Failure to account for scheduled time off or project commitments
Round-robin assignment that treats all technicians as interchangeable
Review your ticket routing configuration with actual workload data. The best routing considers both competency and capacity.
This one's subtle but expensive. Your contract configurations might be technically correct but structured in ways that prevent proper automation of time tracking and billing.
The most damaging issue: contract exclusions that are too broad. I've seen MSPs set up exclusions for "administrative tasks" that accidentally exclude legitimate billable work like user setup or system documentation. The result? Hours of billable time vanish into the ether.
Contract configuration red flags:
Exclusion sets that use vague work type categories
Service bundles with overlapping billing codes
Default contracts that don't align with actual service delivery
Time and materials contracts without proper work type mapping
The contract features documentation explains the technical setup, but the business impact requires careful planning. Every exclusion rule should have a specific business justification.
Your time tracking configuration might be hemorrhaging revenue without obvious symptoms. The problem often lies in how work types map to billing codes and which activities default to non-billable.
Revenue-killing configurations:
Internal time codes that capture billable work (like "training" that should be "knowledge transfer")
Work types with unclear billing status
Default settings that require manual intervention to mark time as billable
Approval workflows that timeout and default to non-billable
I've audited MSPs losing 15-20% of potential revenue because their time tracking setup made it easier for technicians to mark work as internal rather than navigate billing codes.
The fix requires mapping every work type to its billing implications and adjusting defaults to capture revenue rather than convenience.
Your queue organization might seem logical but create unnecessary handoffs and delays. The classic problem: too many specialized queues that fragment work and prevent cross-training.
Problematic queue patterns:
Separate queues for each technology (Exchange, SQL, networking) when issues often span multiple systems
VIP queues that bypass normal prioritization logic
Escalation queues that sit empty because criteria are too restrictive
Regional queues that ignore timezone realities for remote work
The most efficient queue structures group tickets by resolution complexity and resource requirements, not by technology silos. A printer issue at a critical client should escalate faster than a complex but non-urgent server optimization.
SLA configurations often focus on response times while ignoring resolution times or customer satisfaction metrics. Worse, many MSPs set up SLAs that create perverse incentives for their technicians.
SLA configuration problems:
Response time SLAs that encourage quick acknowledgments without meaningful progress
Resolution time SLAs without complexity weighting
Escalation SLAs that bypass skilled technicians for artificial urgency
Customer communication SLAs that generate noise instead of value
The most effective SLAs balance speed with quality and account for the reality of complex technical work. A database corruption issue shouldn't have the same resolution timeline as a password reset.
Your dashboards might be full of data but empty of insight. The most common issue: measuring activity rather than outcomes. Ticket volume, response times, and closure rates tell you what happened, not whether you're improving.
Misleading metrics configurations:
First-call resolution rates that don't account for issue complexity
Customer satisfaction surveys sent immediately after ticket closure
Technician productivity metrics based on ticket count rather than value delivered
SLA compliance metrics that ignore customer impact
The metrics that actually matter focus on customer outcomes and business results: repeat issues per customer, escalation rates for specific problem types, and revenue impact of resolution delays.
These issues compound over time, but the fixes are straightforward once you identify them. Start with a configuration audit that maps your current settings against actual business outcomes.
Priority order for fixes:
Audit workflow rules for conflicts and redundancies
Review contract settings for billing impact
Analyze time tracking for revenue leakage
Optimize queue structures for efficiency
Align SLAs with business goals
Reconfigure metrics for actionable insights
Test routing logic against real workloads
The key insight: Autotask's default configurations work for generic scenarios, but your specific business model, client mix, and team structure require intentional customization. What worked during implementation might be sabotaging efficiency as your business evolves.
Take the time to align your PSA configuration with how you actually deliver service, not how you thought you would when you first set it up.