Why Your Best Techs Are Losing Clients to Silence

A client emailed your team on Tuesday afternoon.

Nothing urgent. A question about her firewall configuration and whether a change she was considering would create any exposure. Not a fire. Not an outage. Just a client trying to make a good decision and wanting your team's input before she moved forward.

Your senior tech saw the email Tuesday night. He glanced at it, decided he needed to look at her environment before he could give her a real answer, and made a mental note to look at it first thing Wednesday.

Wednesday got busy. A ticket blew up mid-morning. Two clients had outages by lunch. He never got back to the firewall email.

Thursday came. He remembered the email at 4pm. He thought about responding then but decided he didn't want to send a half-baked answer, so he pushed it to Friday morning when he could look at it properly.

Friday morning he had it on his list. Then a client called at 9:15 with an emergency and his day was gone. By Friday afternoon he was clearing tickets and forgot about the email again.

Monday morning he woke up thinking about it. He looked at his inbox. She had sent a follow-up on Sunday night. It was polite. It said "just checking in on my question from last week." He felt terrible. He wrote her back immediately with a full, thoughtful answer.

Here is what he didn't know.

Sunday night she was in her home office thinking about her IT provider. She was thinking about the six days she had been waiting for a response to a reasonable question. She was thinking about whether the relationship she had with your business was the relationship she wanted going forward. She wrote you the follow-up because she was giving you one more chance before she started looking for someone else.

Your senior tech isn't lazy. He isn't neglectful. He isn't bad at his job. He's one of the best people on your team.

He is losing her because nobody told him what "responsive" is supposed to mean in your business.

WHAT SILENCE ACTUALLY IS

Most owners think communication problems come from techs who are careless or overloaded. Sometimes that is true. Most of the time it isn't.

Most of the silence in your business comes from techs who are doing exactly what they think you would want them to do. They believe silence until they have a real answer is respectful. They believe picking up the phone to say "we are still working on it" is annoying. They believe an email response that doesn't include a resolution is a waste of the client's time.

Every one of those beliefs is wrong. And nobody has told them.

Your senior tech in the firewall story wasn't ignoring the client. He was trying to give her a good answer. He held off responding because he wanted his answer to be complete. Every day he pushed it, he was doing what he believed was the professional thing.

The client didn't experience it as professional. She experienced it as silence. And silence, from a client's perspective, isn't the absence of communication. It is a decision your team made in the absence of a standard.

The client doesn't know your tech is thoughtful. She doesn't know he wanted to give her a good answer. She doesn't know he was busy. All she knows is that she asked a question and nobody responded. Her brain fills in the gap with the story that best matches what she is seeing. Usually the story is that her business doesn't matter enough to you.

That story isn't true. Your team does care. Your tech does think about her. The problem is she can't see any of that. She can only see the empty inbox.

THE PART YOUR TEAM WILL NEVER FIGURE OUT ON THEIR OWN

Here is the pattern I saw over and over in my MSP and in every MSP I have coached since.

The techs on your team who are best at the technical work are usually the worst at communication. They aren't uncaring. They are wired to solve the problem first and communicate second. They see communication as a distraction from the work of actually fixing things. They believe getting the client an answer matters more than sending updates while they are still working on the answer.

Their instinct is a mercy their brain is doing for them and for the client. They think they are respecting the client's time by not filling their inbox with updates that don't resolve anything.

Their instinct produces the opposite result of what they intend.

Your clients want the phone call that says "we are still working on your issue, here is what we have found so far, we will have an answer by end of day tomorrow." Your clients don't experience that call as an interruption. They experience it as evidence that someone is thinking about them. The mental math they are doing on the other end isn't "did I get a resolution yet." It is "does this MSP have my back."

The tech who calls to say nothing new but confirm the work is happening is producing the exact experience your clients are paying for.

The tech who waits until they have something concrete to report is producing silence the client interprets as neglect.

Your team has to be told this explicitly. They won't figure it out on their own. Their instinct to under-communicate is producing the opposite of what they intend, and unless you name it, they'll keep doing it because to them it feels like professionalism.

THE STANDARD I RUN AT BUILT TO RUN

I built this standard the hard way. For years I ran my MSP without a documented communication SLA. My team was competent. They cared about clients. They worked hard. And balls got dropped. Emails went unanswered longer than they should have. Voicemails sat. Updates that should have gone out didn't go out because nobody explicitly owned them.

The frustrating part was that nobody was being lazy. Everyone was doing what they thought was the right thing. The techs who leaned toward under-communicating were doing it because they didn't want to bother the client. The techs who leaned toward over-communicating were doing it because they thought that was what excellent service looked like. Both groups were guessing. Both groups were doing their best. And the client experience was inconsistent because there was no standard telling them what to do.

The day I documented the communication SLA was the day the guessing stopped. Here is the standard I use now and that I tell every MSP owner I coach to adopt.

Email response within 24 business hours. Every email from a client gets a response within 24 business hours. Not necessarily a resolution. A response. Confirmation the message was received, acknowledgment of what is being done, and a timeline for the next update. That is the floor.

Voicemail response within 4 business hours. Voicemail is the highest urgency signal short of a client walking in the door. A voicemail means the client wanted to talk to a human. Four business hours is the standard. When possible, sooner. Voicemail isn't a note in a queue. It's a request for connection that has to be honored fast.

Chat and portal message response within 4 business hours. Slack DMs, Teams messages, and portal chats typically expect faster response than email because clients experience them as more immediate. Four business hours is a reasonable standard.

Proactive ticket updates every 48 hours minimum. Any ticket open more than 48 hours gets a proactive update from the tech, even when there is nothing new to report. The update confirms the work is happening, sets expectations for the next update, and prevents the client from having to chase. This is the standard your best techs will resist because they see it as unnecessary noise. It is the standard that separates the businesses that keep clients from the ones that lose them to silence.

Escalation acknowledgment within 30 minutes. Client-initiated escalations override every other SLA. An escalation gets acknowledged within 30 minutes and gets an owner assigned within two business hours regardless of how deep the queue is.

These five standards run my business. They will run yours if you document them and hold your team to them.

URGENCY OVERRIDES THE FLOOR

The 24-hour standard is the floor. It isn't a permission slip to wait 24 hours on every email. Urgent items require faster response than the floor.

Emails during an active outage. Faster than the floor. Get back within an hour if the client is down.

Emails marked urgent by the client. Faster than the floor. If the client said it's urgent, treat it as urgent until proven otherwise.

Emails from executive-level contacts. Faster than the floor. When the client's owner or COO or CEO emails, they are watching how fast you respond. Their perception of your business gets set in that response time.

Emails where the content signals frustration. Faster than the floor. When you can hear tension in the client's writing, that email is a warning shot. Respond to it fast.

Emails about security concerns. Faster than the floor. If the client is worried about a possible breach or vulnerability, they need to know you are on it immediately.

Your team needs to be able to read an email, categorize the urgency, and respond appropriately. When in doubt, respond faster than the floor. The floor exists to make sure nothing falls through the cracks. The urgency overrides exist to make sure your best clients feel your responsiveness when it matters most.

WHY THE STANDARD ENDS THE BABYSITTING

Here is the reframe most owners need.

You don't want to babysit your team's communication. You have been doing it because there was no standard for them to work against. Every ticket where you had to remind someone to reach out. Every conversation with a frustrated client whose tech went silent. Every email you had to forward with a note saying "please respond to this client." Every one of those moments was you babysitting because the standard was missing.

Once the standard is documented and the team is held to it, the babysitting ends. The standard is doing the work.

The tech knows the 24 hour SLA. The tech knows voicemail requires a four hour callback. The tech knows a ticket open three days needs an update. When the standard is clear, the tech executes it without needing to be told individually every time. The rare moments where the standard slips become coaching opportunities against a documented expectation rather than surprises to the tech who thought they were doing fine.

The team also feels the difference. They stop wondering whether they're doing enough. They know. They can measure their own performance against the standard. They own their communication because they finally know what good looks like.

The team members who used to under-communicate start over-communicating slightly at first. They call clients with updates that feel unnecessary to them. They send emails confirming work in progress. They watch clients respond warmly to the extra contact. Then they realize what they thought was respect was actually silence, and they never go back to the old pattern.

The team members who already communicated well feel validated. The standard tells them the thing they were doing on instinct is the thing the business officially expects. They stop wondering whether they're over-doing it. They know they're doing it right.

Everyone operates at the same level. The client experience becomes consistent. And you stop having to catch communication failures because they stop happening.

WHERE THIS LIVES IN YOUR FIELD GUIDE

The communication SLA belongs in the client experience section of your field guide. Four components.

The response time standards for every communication channel. Email at 24 business hours. Voicemail at four business hours. Chat at four business hours. Ticket updates at 48 hours minimum. Escalations at 30 minutes. Documented specifically enough that no tech has to guess.

The situations that override the baseline standards. Active outages. Client-marked urgency. Executive contacts. Frustration signals. Security concerns. Documented with enough specificity that every tech recognizes them in the wild.

The specific language the team uses for common communication scenarios. The "we are still working on it" update. The escalation acknowledgment. The ticket-closing confirmation. The difficult conversation with a frustrated client. Language your team can use without having to invent it in the moment.

The measurement and cadence. The number that tells you whether the team is hitting the SLA, checked weekly, with a defined owner responsible for spotting drift and coaching against it.

When all four are documented, communication stops being a personality-dependent operation. Your business delivers a consistent client experience regardless of which tech is on the ticket. Your team owns their communication because they know what the standard is and how to hit it. The client who sent the firewall email gets a response within 24 hours regardless of what else is happening in the business, because the standard runs the response, not the individual tech's memory.

Silence isn't the absence of communication.

Silence is a decision your team is making in the absence of a standard. They're choosing what feels professional to them. They're guessing at what respects the client's time. They're trying to do the right thing. And they're producing the opposite result of what they intend because nobody ever told them what right actually looks like.

Give them the standard. 24 business hours on email. Four business hours on voicemail. Four business hours on chat. 48 hours minimum on ticket updates. 30 minutes on escalations. Document the urgency overrides. Give them the language for the standard responses. Hold them to it.

Watch the babysitting end. Watch the client experience get consistent. Watch the clients who used to quietly consider leaving decide instead to send you a referral because the responsiveness they experience finally matches the business they thought they were paying for.

Your best techs aren't losing clients because they are bad at their jobs. They are losing clients because they are guessing at a standard that was never given to them.

Give them the standard. Start at builttorunmsp.com

FREQUENTLY ASKED QUESTIONS

What is a communication SLA in a managed services business?

A communication SLA is a documented set of response time standards for every communication channel a client uses to reach the business. The standard specifies how fast the team responds to emails, voicemails, chat messages, portal messages, and escalations. It also documents the situations that override the baseline standards, such as active outages, urgent client requests, executive-level contacts, and security concerns. The purpose is to give every tech a clear expectation of what responsive service means so they can execute it consistently. Without a documented communication SLA, techs guess at the standard and produce inconsistent client experiences that erode retention slowly over time.

What is a reasonable email response SLA for an MSP?

Twenty-four business hours is the standard I recommend and use myself at Built to Run. Every email from a client gets a response within 24 business hours. The response doesn't have to be a resolution. It has to acknowledge receipt, confirm what is being done, and set a timeline for the next update. The 24-hour standard is the floor, not the ceiling. Emails during outages, from executive contacts, marked urgent, or that signal client frustration warrant faster response. The floor exists to make sure nothing falls through the cracks. The urgency overrides exist to make sure your most important communications get handled at the appropriate speed.

Why do MSP techs tend to under-communicate with clients?

The pattern comes from a belief most technical people share. They believe silence until they have a resolution is respectful of the client's time. They believe sending an update without a real answer is a waste of the client's attention. They believe picking up the phone to say "we are still working on it" is an interruption rather than a service. Every one of those beliefs is wrong from the client's perspective, but techs won't figure that out on their own. They have to be told explicitly that clients experience regular updates as evidence of care rather than as noise, and that the update confirming work in progress is exactly what the client is paying for. Once techs hear this explicitly and see clients respond warmly to more frequent contact, they change the pattern. They won't change it on their own.

How do you get an MSP team to follow communication standards without constant reminders?

The team follows the standards when the standards are documented, trained against, measured weekly, and reinforced through recognition of the tech who lives them. The reason most teams need constant reminders is that no standard was ever documented in the first place. The owner is reminding people individually because the shared expectation doesn't exist. When the SLA is written into the field guide with response times for every channel, urgency overrides for every scenario, and specific language for common situations, the team executes it because they know what good looks like. The weekly measurement catches drift before it becomes a pattern. The reminders end because the standard is doing the work the owner used to do.

Where should communication standards be documented in a field guide?

Communication standards belong in the client experience section of the field guide. Four components are required. The response time standards for every channel, including email, voicemail, chat, portal messages, ticket updates, and escalations. The situations that override the baseline standards, such as active outages, executive contacts, frustration signals, and security concerns. The specific language the team uses for common communication scenarios so nobody has to invent wording in the moment. The measurement and cadence for tracking whether the team is hitting the standards weekly, with a defined owner responsible for spotting drift. When all four are documented together, communication becomes a designed system rather than a personality-dependent operation, and the client experience becomes predictable regardless of which tech is on the ticket.