The Tech You Praise the Most Is Probably Your Worst Ticket Updater

You have a tech everyone loves.

Fast. Sharp. Clients ask for him by name. He closes tickets efficiently and rarely needs to be told the same thing twice. By every visible measure you use to evaluate your team, he is one of the best people you have.

Go pull up his last ten closed tickets right now.

Half of them have a resolution note that says something like "fixed" or "resolved issue" with no detail about what was actually wrong or what he actually did about it. A few of them have no note at all. If another tech had to pick up where he left off tomorrow, on any of these tickets, they would be starting from nothing.

He fixed the problem. He marked it resolved. He moved on. In his mind, the job was to fix the issue, not to narrate it. Nobody has ever told him otherwise, because nobody has ever separated two things that feel like the same thing but aren't.

Resolving a ticket and owning a ticket's lifecycle are different jobs. Most MSPs only ever measure, praise, and reward the first one.

WHY THE BEST TECHS ARE OFTEN THE WORST AT THIS

This isn't carelessness. It's the opposite dynamic, and understanding that matters, because it changes how you have the conversation about fixing it.

The fastest techs are fast specifically because they are deeply focused on the technical problem directly in front of them. That focus is exactly what makes them good at the job. It is also exactly what makes ticket documentation feel like friction, an interruption in the flow of actually solving the problem. To a tech who takes real pride in his technical work, stopping to write a clear note can genuinely feel like it is slowing him down from doing the part of the job that matters.

There is also a status dynamic quietly reinforcing this every single day. The tech who resolves things fast gets praised for resolving things fast. Nobody has ever specifically praised or corrected the quality of his ticket notes, because the notes were never treated as part of what was actually being evaluated. He is optimizing correctly for the thing that is actually being measured and rewarded. If ticket ownership isn't explicitly part of what gets recognized, a smart, high-performing tech will rationally deprioritize it. He still cares about doing good work. Nothing in his environment has ever told him this specific piece counts too.

WHAT OWNING THE LIFECYCLE ACTUALLY MEANS

This needs to be specific, because a vague request to "document better" produces exactly the vague results you are already getting.

Owning a ticket's lifecycle means the technician is responsible for the ticket from first touch to verified close, not just for the technical fix somewhere in the middle of that timeline. Concretely, that means updating the ticket with what was found and what was done, in language another technician could read cold and fully understand without having to track him down and ask a single follow-up question. It means updating the client proactively, at the standard cadence your business has already documented, instead of going silent until the exact moment of resolution. It means leaving the ticket in a state where, if he is out sick tomorrow and the issue resurfaces, anyone else on your team can pick it up from the notes alone and keep moving without losing a step.

The technical fix is necessary. It isn't sufficient on its own. A brilliant fix with no record of what was actually done is a fix that only exists in one person's memory, which means it isn't actually resolved as far as your business is concerned. It is resolved as far as that one tech's head is concerned, which is a much smaller and far more fragile thing than a resolved ticket should ever be.

WHY THIS HAS TO BE NAMED EXPLICITLY

Most owners assume good ticket hygiene is implied by being a good tech. It isn't, and the evidence is sitting in your queue right now, in exactly the tickets you just pulled up.

A technician can be genuinely excellent at diagnosis and repair while having never once been told, directly and specifically, that narrating the ticket is a required, evaluated part of doing the job well, not an optional courtesy he can skip when things get busy. Vague encouragement doesn't work here, the same way it doesn't work anywhere else in your business. "Try to keep your notes updated" isn't a standard. It is a suggestion, and suggestions get deprioritized the moment something more urgent shows up, which in an MSP is constantly, every single day.

What works is the same thing that works everywhere else you have already built a standard: a specific, documented expectation, paired with direct, individual feedback when it isn't being met. Especially with the technicians whose technical skill has been letting them coast on this specific dimension without anyone ever calling it out to their face.

Your best performer needs to hear, specifically, that his ticket ownership isn't yet where it needs to be, even while everything else about his work is genuinely excellent. That conversation feels uncomfortable to have with your best person. It is also exactly the conversation that closes the gap, because he is fully capable of doing this well the moment he understands it is actually required, not optional, not a nice-to-have, not something he can keep skipping as long as the technical fix lands.

Have that conversation this week. Tell him specifically what you pulled up in his last ten tickets. Tell him why it matters, not just that it matters. Watch how quickly it changes once he actually understands the standard was real the whole time and nobody had ever said so out loud.

WHY THIS MATTERS BEYOND ANY SINGLE TICKET

Ticket ownership done well is what makes escalation actually work. A senior engineer stepping in on a spinning ticket needs accurate notes to guide the junior tech efficiently, rather than starting from zero and burning the exact time the twenty-minute escalation rule was designed to save.

It is what protects your business when a tech is out sick and someone else has to pick up an open ticket cold, with no warning and no time to track down the original tech for context.

And it is a direct driver of your open ticket to endpoint ratio staying healthy. Poorly documented tickets tend to get reopened. They get misunderstood by whoever touches them next. They take longer to close cleanly the second time around, after the client is already frustrated that the same issue came back. All of that quietly pushes your ratio in the wrong direction, one under-documented ticket at a time.

WHERE THIS LIVES IN YOUR FIELD GUIDE

Ticket lifecycle ownership belongs in your field guide's service delivery system as an explicit, documented standard, not an assumed professional norm you hope everyone already understands.

Document exactly what a properly owned ticket looks like at each stage. First touch. In-progress update. Resolution note. What each of those needs to contain to count as actually done correctly, not just technically closed. Document the standard for proactive client updates during an open ticket, tied to the communication SLA you have already established elsewhere in your field guide. And document that ticket ownership quality is an explicit part of how technical performance gets evaluated, not a separate, softer conversation that only comes up if something goes visibly wrong.

When this is written down and applied consistently, even to your team's best performers, ticket ownership stops depending on any individual tech's personal habits or how much friction they personally feel toward documentation. It becomes the standard every ticket meets, regardless of who resolved it.

Your best tech needs to be told, specifically, that this counts. That a fix without a clear record is only half the job. That the tickets you pulled up from his last ten closed cases aren't good enough, even though the actual technical work behind every one of them almost certainly was.

Tell him. Not vaguely. Specifically, with real examples, this week.

Then document the standard in your field guide so the next conversation like this one isn't a surprise to anyone, and the tech after him never has to learn it the hard way, three months in, the same way he did. Start at builttorunmsp.com.

FREQUENTLY ASKED QUESTIONS

What is the difference between resolving a ticket and owning a ticket's lifecycle?

Resolving a ticket means the technical problem itself has been fixed. Owning a ticket's lifecycle means the ticket record is accurate, current, and useful to anyone who touches it after the original technician, from first contact through a verified, well-documented close. A technician can be excellent at the technical fix while completely neglecting lifecycle ownership, since these are genuinely different skills that most businesses only measure and reward one of, typically the technical fix, while leaving ticket documentation as an unmeasured afterthought.

Why do highly skilled technicians often have the worst ticket documentation habits?

Skilled technicians are often fast specifically because they stay deeply focused on the technical problem in front of them, and that same focus makes documentation feel like an interruption to the real work. There is also a reinforcing status dynamic: technicians typically get praised and recognized for resolving issues quickly, while the quality of their ticket notes rarely gets evaluated or discussed at all. A smart, high-performing technician will rationally optimize for whatever is actually being measured and rewarded, which means ticket ownership gets deprioritized unless it is explicitly named as something that counts.

What should a properly documented ticket include at each stage of its lifecycle?

A well-owned ticket includes a clear first-touch note describing the initial issue, ongoing updates as work progresses that another technician could read cold and understand without needing to track down the original technician, and a detailed resolution note explaining what was actually found and what was actually done to fix it. It should also reflect proactive client communication at the cadence already defined by the business's communication standards, rather than the client hearing nothing until the moment of resolution. The end goal is a ticket that any other team member could pick up and understand fully if the original technician were suddenly unavailable.

Why is it important to give specific, individual feedback about ticket documentation rather than general reminders to the whole team?

General reminders like asking the team to "keep notes updated" function as suggestions rather than standards, and suggestions are easy to deprioritize the moment something more urgent comes up, which happens constantly in managed services. Specific, individual feedback, especially directed at high-performing technicians who have never had this particular gap named to them, is far more effective because it removes ambiguity about whether the expectation is optional. A technician who is excellent at the technical work is usually fully capable of meeting a documentation standard once he understands, specifically, that it is genuinely required rather than a soft preference.

How does poor ticket documentation affect an MSP beyond the individual ticket itself?

Poorly documented tickets undermine the effectiveness of escalation, since a senior engineer guiding a junior technician through a difficult issue needs accurate notes to help efficiently rather than starting from zero. It also creates risk if a technician is unexpectedly unavailable, since another team member has no reliable way to pick up an open ticket without those notes. Additionally, poorly documented tickets are more likely to get reopened or misunderstood by whoever handles them next, which increases the ratio of open tickets to endpoints, a metric closely tied to overall client satisfaction across the entire client base.