Your Best Tech Just Wasted Two Hours. He Doesn't Know It Yet.

A tech picks up a ticket and tries an approach. It doesn't work. He tries a slightly different version of the same approach. Still nothing. He tries a third thing out of pure persistence, because giving up after two attempts feels premature.

An hour passes. Then two.

He has been working the entire time. Nothing about his effort was fake. He has not been sitting idle or scrolling his phone. He has been genuinely trying, the whole way through, to solve a real problem for a real client.

And the ticket is no closer to resolved than it was twenty minutes in. Except now the client has waited two hours instead of twenty minutes, and your business has burned two hours of labor cost with nothing to show for it.

This is spinning. It is one of the most expensive, least visible problems in a growing MSP, because it never looks like a problem while it is happening. It looks like diligence. It looks like someone who cares enough not to give up. Nobody walking past that desk sees a red flag, because there is no red flag to see. There is just a person quietly working on something that was never going to resolve the way they were approaching it, for far longer than anyone should have let it go.

WHY TWENTY MINUTES

The fix isn't telling your techs to work faster or try harder. It is giving them a specific, honest, non-negotiable rule for when persistence stops being useful and starts being expensive.

Twenty minutes.

If the issue has not moved toward resolution in the first twenty minutes of real work, it escalates. Sooner than that, the moment a tech genuinely believes they won't solve it within that window, it escalates immediately. Not as a failure. As the standard.

Twenty minutes is long enough for a competent tech to properly diagnose most issues and either resolve them or clearly see the shape of what is actually wrong. It is short enough that if the first approach has not worked by then, continuing down the same path rarely produces a breakthrough. What usually happens instead is the tech keeps trying variations of an approach that was fundamentally the wrong one from the start, because stepping back and admitting the current path isn't working feels harder than trying one more thing.

Twenty minutes is also short enough that escalating at that point costs almost nothing. The client has barely noticed a delay. The senior engineer who gets pulled in isn't walking into a disaster. They're walking into a fresh problem with clear, recent context, which is exactly the situation where a second set of eyes is most useful and least expensive to provide.

Every additional hour past that first twenty minutes multiplies the cost on every dimension at once. Client patience erodes. Labor cost climbs with nothing resolved to show for it. And the eventual escalation, when it finally happens two hours in instead of twenty minutes in, often comes after the tech has already tried and ruled out several approaches in a disorganized way. That actually makes the senior engineer's job harder, not easier, because now they have to untangle everything already attempted before they can even figure out what to try next.

WHY TECHS DO NOT ESCALATE ON THEIR OWN

Most teams have some informal sense that escalation exists as an option. The barrier is rarely a lack of a rule. It is emotional.

Escalating can feel like admitting failure, especially to a tech who takes pride in their work and wants to be seen as capable. There is a quiet story a lot of techs carry that a good technician solves the problem themselves, and asking for help after only twenty minutes feels premature, like giving up too soon, even when every bit of evidence says otherwise.

There is also a real fear about how it will be perceived. If a team's culture, even unintentionally, treats frequent escalation as a sign of weaker skill, techs will hide their struggle instead of surfacing it. They will keep spinning quietly rather than raise their hand and risk looking less capable in front of a senior engineer or you.

This is exactly why the twenty-minute threshold has to be a documented, non-negotiable standard rather than a vague cultural encouragement to ask for help if needed. A standard removes the personal judgment call from the moment. It isn't the tech deciding they aren't good enough to solve this on their own. It's the tech following the rule everyone on the team follows, the same way everyone follows the SLA on ticket acknowledgment. People don't feel embarrassed following a documented standard. People feel embarrassed making an individual judgment call that might read as weakness.

WHAT ESCALATION SHOULD ACTUALLY LOOK LIKE

Escalation should never mean the junior tech hands the ticket off and disappears from the process. That produces two bad outcomes. The junior tech never actually learns anything. And the senior engineer becomes a permanent bottleneck who has to personally solve every hard ticket for the rest of time.

The right model puts two people in the room, not a handoff. The senior or tier three engineer steps in to guide the technician scheduled to do the work, rather than simply taking over and solving it themselves while the junior tech watches from the sidelines. The senior engineer's job is to ask the right questions, point toward the right diagnostic path, and help the junior tech actually reach the resolution, with the senior engineer's experience accelerating the process instead of replacing the junior tech's involvement in it.

At the same time, the junior tech documents the process as it unfolds. What was tried before escalation. What the senior engineer suggested. What actually worked and why. That documentation becomes the exact thing that prevents the same spin from happening again the next time a similar ticket comes in, either for that same tech or for anyone else on the team who runs into the same pattern later.

Done this way, escalation isn't just a rescue mechanism for one stuck ticket. It is a training mechanism and a documentation mechanism at the same time, every single time it happens.

WHY THIS MATTERS BEYOND ANY ONE TICKET

This connects directly to something we have written about before. Once the ratio of open tickets to endpoints crosses roughly 7 percent, client satisfaction starts degrading consistently, even when individual techs are doing solid work on individual tickets.

Spinning is one of the primary hidden drivers behind that ratio climbing past the danger threshold in the first place. A single ticket that should have taken twenty minutes and instead consumed two hours doesn't just cost that one client's satisfaction. It ties up capacity that should have gone toward the next ticket in the queue, which is exactly the mechanism that pushes the open ticket ratio upward and starts degrading service across every other client at the same time.

One tech quietly spinning on one ticket can be the difference between your team sitting comfortably under the threshold and crossing it. The twenty-minute escalation rule is one of the most direct, practical ways to keep that ratio from climbing in the first place, before it ever gets close to triggering a swarm.

WHERE THIS LIVES IN YOUR FIELD GUIDE

This belongs in your field guide's service delivery system as a specific, documented rule, not a cultural suggestion your team is supposed to intuit.

Document the twenty-minute threshold explicitly, including the earlier trigger. The moment a tech genuinely believes they won't resolve the issue within that window, they don't have to wait for the clock to actually run out. Document exactly who escalation goes to, tier three or the designated senior engineer, so there is no ambiguity or hesitation about the right person to pull in. Document the collaborative model for what escalation actually looks like: senior engineer guiding rather than taking over, junior tech documenting the resolution as it happens. And document where that resolution documentation goes, so it becomes searchable, reusable knowledge instead of disappearing the moment the ticket closes.

When this is written down as a real standard, escalating stops being a personal judgment call that feels like admitting weakness. It becomes exactly what following the SLA already is. The expected, professional way your team operates, every time, for everyone.

The tech who spun for two hours wasn't lazy. He wasn't incompetent.

He was following an unwritten rule that asking for help too soon looks weak, a rule nobody ever wrote down but everyone on the team somehow absorbed anyway.

Give him a written rule that says the opposite. Twenty minutes, or the moment he genuinely believes he won't get there, whichever comes first. A senior engineer who guides instead of takes over. A documentation habit that turns every escalation into training for next time.

That is how you stop losing hours you never needed to lose, on tickets that were never going to resolve the way your team kept trying to force them to. Start at builttorunmsp.com.

FREQUENTLY ASKED QUESTIONS

What is a resolution timeout rule in an MSP service delivery system?

A resolution timeout rule sets a specific time limit, often around twenty minutes, within which a technician must show real progress toward resolving a ticket before it automatically escalates to a senior or tier three engineer. If the technician recognizes earlier than the timeout that they won't resolve the issue within that window, escalation happens immediately rather than waiting for the clock to run out. The rule exists to prevent technicians from spending excessive time on an approach that isn't working, which drives up labor cost and delays client resolution without producing any measurable progress.

Why do technicians often delay escalating a difficult ticket even when a process exists?

The barrier is usually emotional rather than procedural. Many technicians associate asking for help with admitting failure or appearing less capable, especially if a team's culture, even unintentionally, treats frequent escalation as a sign of weaker skill. This leads technicians to keep working on a problem alone far longer than is productive, hiding their struggle instead of surfacing it early. A documented, non-negotiable time threshold removes this as a personal judgment call, since the technician is simply following a standard everyone on the team follows rather than making an individual decision that could be perceived as weakness.

What does effective ticket escalation look like beyond simply handing off the work?

Effective escalation involves the senior or tier three engineer guiding the technician who is scheduled to do the work, rather than taking the ticket over entirely and solving it without their involvement. The senior engineer asks diagnostic questions and points toward the right path, while the junior technician remains actively involved in reaching the resolution. At the same time, the junior technician documents what was tried before escalation and what ultimately worked, turning the escalation into both a training opportunity and a documented reference for handling similar issues in the future.

How does slow ticket resolution affect overall service delivery across an MSP's client base?

When a technician spends excessive time on a single ticket without progress, it ties up capacity that should be available for other open tickets in the queue. This directly affects the ratio of open tickets to available endpoints, which is closely linked to overall client satisfaction. A rising ratio of open tickets to endpoints tends to correlate with declining client satisfaction, even when individual technicians are doing competent work, because response times slow and proactive communication becomes harder to maintain across every client at once, not just the one tied up in a lengthy ticket.

Why should a resolution timeout threshold be documented rather than left as an informal expectation?

An informal expectation to escalate "if needed" leaves the decision entirely up to individual judgment in the moment, which is exactly when a technician is most likely to feel pressure to keep trying rather than ask for help. A documented, specific threshold, such as twenty minutes, removes ambiguity and makes escalation a standard procedure rather than a personal choice that could be perceived as an admission of weakness. This mirrors how other service level agreements function within a field guide, where a clear, written standard makes consistent behavior far more likely than a general cultural encouragement ever could.