The ticket lands in tier two with no context. The tech calls the client, asks what's already been tried, and the client starts the story from the beginning: the outage that cost them thousands, the machine that stopped, the tech they spoke to twenty minutes ago. You've watched this happen a dozen times this week. The client isn't being difficult. The ticket has no memory.
The fix is plain: a handover note that travels with every escalated ticket, and a weekly escalation review that shows you where tier one keeps getting stuck. The note stops the client from repeating themselves. The review stops the desk from rediscovering the same problems.
Picture a client whose CNC tooling machine drops off the network for five minutes, then comes back. Tier one tries a cable swap, reboots the switch, and escalates with no note. Tier two calls the client, asks what happened, and the client re-explains the outage and the damage to their production. The next tech doesn't need a detective. They need a note.
What Goes in a Handover Note Worth Reading
A handover note has five parts. Keep it short enough that a tech will actually fill it, and specific enough that the next tech never has to ask.
- Client context: what the environment is, what the machine or system does, why it matters.
- What was tried: the exact steps, not "troubleshooting".
- What failed: which of those steps didn't help.
- What the next tech should try: a concrete next action.
- Client-specific quirks: anything the next tech must know before calling, like a machine that tolerates no downtime.
The CNC ticket's note reads: "Client's machine drops off network for 5 min, then recovers. Tried replacing cable and rebooting switch, still happens. Next tech should check if the AP is failing. Client's machine is costly, so call them before any change." That's four lines. It tells the next tech everything they need.
Make the Note Part of Escalation, Not an Afterthought
A note format only works if techs actually fill it. The way to make that happen is to make the note a condition of escalation. Use a custom field in your PSA, or a required template, so a ticket can't move to the next tech without it. The service manager rejects any escalation that lacks the note. That's the enforcement. Without it, techs will skip the note or paste in generic text to get past the field.
My view: make it a hard rule, not a suggestion. The moment you accept an escalation without a note, you've told every tech the note is optional. The cost is a few minutes per escalation for the writing tech. The cost of not doing it is a client repeating their whole story to a stranger.
The Weekly Escalation Review: Spot the Skill Gap in 30 Minutes
Once the notes exist, you can see patterns. Once a week, pull the week's escalated tickets, put them side by side with their notes, and look for repeated topics or failure points. The service manager and tier one techs go through them together. Each recurring issue becomes a candidate for a one-page guide or a training session.
Say three different clients had the same UniFi access point going offline. The notes all say "tried reboot, still offline." That's not three separate problems. That's one skill gap: UniFi AP troubleshooting. The review flags it, and next week tier one gets a short session on it. You've turned a pattern of escalations into a fix.
The review costs 30 minutes of team time, which pulls techs off the board, plus a bit of prep time for you to pull the reports. It's worth it if you have more than two escalations a week that repeat a similar pattern. If the volume is lower, or tier one coverage is too thin to take everyone off the board, run it biweekly, or asynchronously with a shared doc.
When This Whole System Breaks Down
This approach fails in three ways, and it's worth naming them so you can head them off.
- Techs treat the note as paperwork. If the culture says notes are for the manager, not for the next tech, they'll write something useless. The fix is to make the note the thing that gets the ticket unstuck, not a chore.
- The review becomes a blame session. If tier one feels punished for escalating, they'll stop being honest. The review has to be about skill building, not fault.
- The volume is too low to find patterns. If you escalate once a month, a weekly review is wasted time. Run it ad hoc, after a repeated incident, or monthly.
A one-off legacy server issue that doesn't repeat doesn't need a weekly review. The note alone handles it. The review exists for the patterns, not for the exceptions.
And a caution: if no one owns the follow-up actions, the same issues will recur next week. The review has to end with a named owner for each training item or process fix. Otherwise you're just meeting.
What to Change on Monday Morning
Start with the template. Draft the five-part handover note, post it in the team channel, and update the escalation workflow so no ticket moves without it. By Monday afternoon, the CNC ticket and every future ticket carries the note. Then schedule the first weekly review for Friday, same time every week.
After two weeks, look at the log of recurring issues. If the patterns are thinning out, you're on the right track. If they're not, check whether the notes are actually being filled, and whether the review is producing follow-ups that stick. Adjust the cadence from there: weekly, biweekly, or monthly, whatever the volume supports.
The client who had to repeat their story to three techs is the reason this matters. The note is how you make sure they only tell it once.
mspoutpost.com/articles/write-a-handover-note-so-the-client-never-repeats-themselves
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
