A technician finishes a replacement and writes a great update. Hi Sarah, we’ve swapped the failed drive, the array is rebuilding, and we’ll confirm once it’s healthy tomorrow morning. Clear, polite, specific. Exactly what you’d want a client to read.
The technician saves it as a discussion note and moves on to the next ticket. The “send as email” box stays unchecked.
From the technician’s point of view, the client has been updated. From the ticket’s point of view, there’s fresh, well-written activity. From Sarah’s point of view, nobody has said anything in three days.
At one MSP I talked with, someone finds these by hand, roughly twice a week. Every one of them is a multi-day silence that the client experienced and nobody inside the MSP could see.
Why nobody notices
This is one of the hardest service problems to catch, because every internal signal looks healthy.
The ticket was updated recently. The notes are thorough. The technician did the work and documented it. If you check “last activity,” the ticket looks fine. If you read the notes, it looks better than fine.
The only person who knows something went wrong is the client, and clients rarely complain about a specific missing email. They complain in aggregate, months later: we never know what’s going on with our tickets. By the time that sentence shows up at a QBR, it’s attached to a dozen tickets nobody can reconstruct. It’s one of the quieter patterns in the churn signal buried in your ticket queue.
The same mistake, in the other direction
Another MSP described the mirror image. Technicians mix internal working notes into the resolution. The client-facing resolution ends up including things like left voicemail, no answer, tried calling again at 2, or a half-finished email draft pasted in for reference.
Nothing confidential, usually. But it reads badly, and it teaches the client that the notes they see are the technician’s scratchpad.
Both problems have the same root cause: in most PSAs, the difference between “internal” and “client-facing” is one checkbox in the same text box. In ConnectWise it’s the note type and the email option. In HaloPSA, discussion notes are hidden by default and “email user” is the external path. Technicians working fast choose the wrong one a few percent of the time. At a few thousand tickets a month, a few percent adds up to a lot of silence.
Why checking at close is too late for this one
I’ve argued before that monthly ticket QA is too late and that the right moment to check a ticket is when it closes. For short tickets, I still believe that.
But one MSP pushed back with numbers I couldn’t argue with. About half their tickets stay open for weeks. Their median support ticket takes 10 to 11 days to close. Timesheets are submitted weekly. By the time a long-running ticket closes and gets reviewed, the unsent update is ten days old, the timesheet it belonged to is already approved, and the client has already sat through the silence.
Their rule of thumb is worth stealing: if your median time to close is more than five business days, QA that only runs at close loses most of its value. For communication problems especially, the check has to happen while the ticket is still open, ideally within hours of the note being written.
What to check while the ticket is still open
These are the checks that catch communication gaps before the client feels them:
A client-facing note with no outbound message. A note written in the second person, addressed to the client by name, describing next steps, with no email or portal reply sent around the same time. This is the unsent update. It’s easy to detect once you look at the note’s wording, not just its type.
Days since the last client-visible message. Not “last activity.” Last message the client actually received. An open ticket with a person waiting and no client-visible update in two business days deserves a nudge.
Status that contradicts the conversation. A ticket set to “waiting on client” where nothing was ever asked of the client. Or “in progress” for a week with no update sent. The status says one thing and the client’s inbox says another.
Internal content in client-facing fields. Voicemail attempts, internal names, draft text, and troubleshooting chatter in a resolution note that the client will read.
None of these require judging whether the technician did good work. They only check whether the client heard about it.
Who should hear about it
When a check finds an unsent update, the goal is a quick fix, not a performance conversation. That shapes how the finding should be delivered.
Tell the technician directly and privately, inside the PSA or in a personal notification, while the ticket is still in their head. Posting findings to a shared team channel turns a two-minute correction into a public callout, and technicians respond to that by getting defensive, not more careful. Save aggregated reports for the service manager, where the useful question is whether one person is struggling or the whole team has a process problem.
And make the fix a single click. If the note was meant for the client, the technician should be able to send it as it is, not rewrite it in a different window.
That’s the bet Mizo made
Most AI agents for MSPs focus on triage and resolution. Mizo also treats client communication as its own job rather than a side effect of documenting work.
The Communication Agent watches ticket activity for moments the client should hear about, drafts a clear update in your voice, sends it over email, Teams, or Slack, and logs it to the ticket so the timeline matches what the client actually received. The Quality Review Agent checks the communication side of every closed ticket, including tone and professionalism on the messages the client actually saw, and flags findings internally so the technician can act on them.
It’s also why partners have pushed us to run these checks while tickets are still open instead of only at close. They’re right. For long-running tickets, the silence happens in the middle.
Where to start on Monday
- Pull ten open tickets older than five days. For each, find the last message the client actually received, not the last note. Note how many days ago it was.
- Look for notes in those tickets that start with the client’s name or “Hi.” Check whether each one was sent.
- Check your median time to close. If it’s over five business days, close-only QA isn’t enough for communication problems.
- Look at your PSA’s note templates. If the default note type is internal, consider whether that’s the right default for tickets where a client is waiting.
- Decide who gets told when an update wasn’t sent, and make sure the answer is “the technician, privately, the same day.”
Built by a former MSP operator. The update your client never received is the one your technician is proudest of writing.