"Tier 2 handles the harder stuff."
If that sounds like a tier definition at your MSP, you have a problem. Not because your team is unclear, but because "harder" is a judgment call. And judgment calls made under pressure, hundreds of times per day, produce inconsistent results.
The traditional approach to tiered support defines tiers by complexity. Simple issues go to Tier 1, complex issues go up. The logic seems sound until you try to operationalize it.
What makes a ticket complex? How complex is too complex for Tier 1? When exactly should a tech stop working and escalate?
The answers depend on who you ask. Which means escalation decisions depend on who's working. Which means your tier structure exists on paper but not in practice.
Here's a different approach.
Define Tiers by Capability, Not Complexity
Instead of asking "how hard is this ticket?" ask "what capabilities are required to resolve it?"
This reframe changes everything.
Tier 1: Tickets that can be resolved using documented procedures and standard tools, without requiring elevated permissions or specialized knowledge.
Tier 2: Tickets that require elevated permissions, cross-system troubleshooting, or application-specific expertise beyond documented procedures.
Tier 3: Tickets that require infrastructure-level access, architectural knowledge, or vendor coordination.
Notice what's different. These definitions don't mention complexity. A Tier 1 ticket might involve multiple steps and take thirty minutes, but if those steps are documented and don't require special access, it stays at Tier 1. A Tier 3 ticket might be a quick configuration change but if it requires server access, it belongs at Tier 3.
Capability-based definitions are objective. Either the ticket requires admin access or it doesn't. Either there's a documented procedure or there isn't. Your technicians don't have to guess whether something is "hard enough" to escalate.
Create Escalation Triggers, Not Guidelines
Once you've defined tiers by capability, you need explicit triggers for when tickets move between them. Triggers, not guidelines. The difference matters.
A guideline says: "Escalate if you can't resolve the issue in a reasonable time."
A trigger says: "Escalate if troubleshooting has exceeded 30 minutes without resolution."
Guidelines leave room for interpretation. Triggers don't.
Effective escalation triggers are:
Objective - Based on observable factors. "Requires admin credentials" is objective. "Too complicated for Tier 1" is not.
Documented - Written down and accessible. Not stored in tribal knowledge or Sarah's head.
Verifiable - Possible to check after the fact whether the escalation was appropriate.
Here's an example set of Tier 1 → Tier 2 escalation triggers:
Troubleshooting has exceeded 30 minutes without resolution
Resolution requires permissions the technician doesn't have
The issue involves integration between two or more systems
The documented procedure specifies Tier 2 handling
The client's SLA requires senior-level response
Each trigger is specific. A ticket either meets the criteria or it doesn't. There's no "use your judgment" escape hatch that makes every decision a coin flip.
Why This Approach Works
Capability-based tiers with explicit triggers solve three problems simultaneously:
Problem 1: Over-Escalation
When the criteria for "should I escalate?" are clear, technicians don't escalate uncertain tickets by default. They check the triggers. If no trigger is met, they keep working. The decision is objective, not emotional.
Problem 2: Training Gaps
How do you train a new Tier 1 tech without explicit criteria? You have them shadow someone and hope they absorb the right judgment calls. With documented triggers, training has standards. You can test whether someone understands the criteria before they start handling tickets independently.
Problem 3: Inconsistency
Different dispatchers apply different rules. Monday morning tickets get different treatment than Friday afternoon tickets. Explicit triggers are applied the same way every time, regardless of who's working or how busy the queue is.
The Missing Piece: Enforcement
Definitions and triggers are necessary but not sufficient. Without enforcement, even the best criteria drift.
Enforcement doesn't mean punishment. It means feedback loops.
When a ticket gets escalated inappropriately, someone needs to identify the pattern. Not to discipline the tech but to understand why. Was the criteria unclear? Was training insufficient? Does the trigger need revision?
This requires tracking escalation patterns systematically. Which ticket types get misrouted most often? Which technicians escalate most frequently? Are there specific triggers that get misapplied?
Manual tracking works at small scale. You review escalated tickets daily, note patterns, provide feedback. At larger scale, you need automated visibility, systems that flag potential misroutes and surface trends before they become entrenched.
Skills-Based Routing: The Next Level
Capability-based tiers determine which tier should handle a ticket. But within each tier, you still need to decide which technician gets it.
The simple approach is availability-based: whoever's free gets the next ticket. This ensures quick pickup but ignores specialization. Your Tier 2 tech who knows Microsoft 365 inside and out shouldn't be picking up network infrastructure tickets just because they're next in the queue.
Skills-based routing matches tickets to technicians based on:
Technical skills: What systems and applications the tech is proficient with
Client familiarity: Whether they've worked with this client before
Current workload: How much they already have on their plate
Availability: Whether they're actually free to take new work
This requires maintaining a skills matrix and tagging tickets with required skills. More work upfront, but tickets land with technicians who can actually resolve them efficiently.
Where to Start
You don't have to implement everything at once. Start with the highest-impact change: documenting explicit escalation criteria.
1. Audit current state: For two weeks, track why tickets escalate. Look for patterns.
2. Draft criteria: Based on your audit, write explicit triggers for each tier boundary.
3. Train the team: Walk through the criteria with real examples. Practice applying them.
4. Track and iterate: Monitor escalation patterns. Refine criteria based on what's working and what's not.
The goal isn't perfection on day one. The goal is moving from "use your judgment" to "here's how we decide."
Get the Complete Framework
We've published a comprehensive guide covering everything in this post and more, capability-based tier definitions, escalation trigger templates, skills-based routing frameworks, and implementation roadmaps.
Download The Tiered Support Optimization Guide
It's the playbook for building tier boundaries your team can actually follow.
Giant Rocketship automates ticket triage and skills-based dispatch for MSPs. Schedule a Demo!