Ask your Tier 3 engineers how they spent their day. Not what they were supposed to work on but what they actually did.
Odds are, a significant chunk of their time went to tickets that never should have reached them. Password resets. Basic troubleshooting. Issues with documented procedures that any Tier 1 tech could have handled.
Your senior engineers aren't complaining because they're problem-solvers by nature. When a simple ticket lands in their queue, they just handle it. It's faster than sending it back. Less friction. Gets the client taken care of.
But this quiet accommodation is costing your MSP more than you realize.
The Math No One Does
Consider what happens when a Tier 1 ticket incorrectly escalates to Tier 3:
The Tier 1 tech spends 5-10 minutes documenting and escalating. The ticket sits in the Tier 3 queue, often for hours waiting for pickup. The Tier 3 engineer context-switches from whatever they were working on, reviews the ticket, and realizes it's a simple issue. They either handle it anyway or send it back, which triggers another round of queue time and context-switching.
A ticket that should have taken 15 minutes at Tier 1 has now consumed 30-45 minutes of combined labor, plus queue time that may have pushed it past SLA thresholds.
That's the direct cost. The opportunity cost is worse.
Every hour your Tier 3 engineers spend on Tier 1 work is an hour they're not spending on complex projects, infrastructure issues, and escalations that actually require their expertise. You hired them for their skills. You're paying for their experience. And you're deploying them as expensive generalists because your routing system can't tell the difference.
Why It Happens (And Why Training Won't Fix It)
The instinct is to blame training. If Tier 1 techs would just handle more issues themselves, the problem would disappear.
But this misses the real cause. Your Tier 1 techs aren't escalating because they're lazy or undertrained. They're escalating because your system makes escalation the rational choice.
Think about it from their perspective. When facing an unfamiliar ticket, a Tier 1 tech has two options:
Option A: Spend time researching and attempting a fix, with the risk of making things worse or exceeding time expectations.
Option B: Escalate to someone more experienced, which takes two minutes and carries no personal downside.
The cost of escalating is invisible. Someone else handles it. The ticket disappears from their queue. No one tracks whether the escalation was appropriate. The cost of attempting a fix and failing is immediate. The client might be upset. The manager might ask questions. The tech's metrics might suffer.
Without explicit criteria that define what belongs at each tier, the rational choice is always escalation. You haven't trained people to escalate, you've designed a system that rewards it.
The Three Forces Behind Tier Drift
Once you start looking, you'll notice three forces that consistently erode tier boundaries:
Force 1: Boundaries Were Never Explicit
Most MSPs inherit their tier structure rather than designing it. Someone decided "junior techs handle easy stuff, senior techs handle hard stuff," and the details filled themselves in over time.
What's obvious to a five-person team becomes ambiguous at fifteen and chaotic at thirty. The boundaries that existed in everyone's heads were never written down—and different heads hold different boundaries.
Force 2: The Path of Least Resistance
Escalation is easy. Resolution is hard. When the criteria for "should I escalate?" are unclear, the answer will always drift toward yes.This isn't a character flaw. It's basic human behavior in response to ambiguous rules and invisible costs.
Force 3: Senior Engineers Enable the Dysfunction
Your Tier 3 engineers absorb misrouted tickets without feedback. They solve the immediate problem (the ticket) while reinforcing the systemic one (the inappropriate escalation).
Every time a senior engineer handles a Tier 1 ticket without sending it back, they teach the escalating tech that their judgment was correct. The boundary erodes a little more. And the senior engineer wonders why they can never get to their "real" work.
What It Looks Like When Boundaries Work
Contrast the common scenario with a service desk where tier boundaries are intentional:
Tiers are defined by capability, not complexity.
A Tier 1 ticket isn't one that's "easy", it's one that can be resolved using documented procedures without elevated permissions. The criteria are objective.
Escalation has explicit triggers. Techs don't escalate based on gut feel. They escalate when specific, documented conditions are met: troubleshooting exceeded 30 minutes, resolution requires admin access, the issue involves multiple integrated systems.
Routing is skills-based. Tickets don't just go to "whoever's available." They route to technicians with the specific skills required, balanced against current workload.
Feedback loops exist. When tickets get misrouted, there's a mechanism to identify and correct the pattern. Not punishment but calibration.
The result isn't a more rigid system. It's a more intentional one. Tickets land with the right technicians more often. Senior engineers focus on work that requires their expertise. Training becomes possible because there are actual standards to train against.
The Question Most MSPs Avoid
Here's the uncomfortable question: If you asked each of your technicians to define the difference between a Tier 1 and Tier 2 ticket, would you get the same answer?
If the answer is no, if you'd get vague approximations that differ depending on who you ask, then your tier boundaries exist in name only. And every unclear boundary is a ticket waiting to be misrouted.
Your technicians are capable. Your tier structure makes sense. The missing piece is the explicit criteria that turn organizational theory into operational reality.
Start Fixing the Problem
We've put together a comprehensive guide to building tier boundaries that actually work. It covers defining tiers by capability, creating explicit escalation criteria, and implementing feedback loops that prevent drift.
Download The Tiered Support Optimization Guide
It's free, practical, and built specifically for MSPs who are tired of watching senior talent get wasted on junior work.
Giant Rocketship provides service management orchestration for MSPs automating ticket triage, skills-based dispatch, and workload optimization. Schedule a Demo now!
Share via: