Key Takeaway: The communication standard that builds client trust requires three things: acknowledge within 15 minutes, update at defined intervals during the incident, and explain completely after resolution. The post-mortem is the communication that converts an incident from a trust-eroding event into a trust-building one.
The way an MSP communicates during an incident is the single most visible test of the relationship. Everything else about your service is invisible to clients most of the time. The monitoring, the patching, the backup verification, the security stack. Clients do not see any of it until something goes wrong. When something goes wrong, the communication is what they experience. It is what they remember. It is what determines whether they renew or start looking for alternatives.
Most MSPs communicate poorly during incidents. They go silent while they work the problem, then resurface with “it’s fixed” and no explanation of what happened. The client who experienced an hour of downtime and received no communication during it is not reassured by a resolution notification. They are frustrated by the silence and uncertain about whether the problem will happen again.
The Communication Standard That Builds Trust
The communication standard that builds client trust is not complicated. It requires three things: acknowledge quickly, update regularly, and explain completely.
Acknowledge quickly. When an incident is detected, the client should receive an acknowledgment within 15 minutes. Not a resolution. Not a diagnosis. An acknowledgment that the MSP is aware of the issue and is working on it. The client who receives an acknowledgment within 15 minutes knows someone is paying attention. The client who waits 45 minutes for the first communication is already frustrated before the resolution arrives.
Update regularly. During an active incident, the client should receive updates at defined intervals: every 30 minutes for a P1 incident, every hour for a P2. The update does not need to contain a resolution. It needs to contain current status, what is being done, and the next update time. The client who knows when to expect the next update is less anxious than the one who is waiting without a timeline.
Explain completely. After the incident is resolved, the client should receive a clear explanation of what happened, why it happened, and what changed to prevent recurrence. This is the post-mortem, and it is the communication that converts an incident from a trust-eroding event into a trust-building one. The client who understands what happened and what changed is more confident in their MSP than the one who received a resolution notification with no explanation.
The Communication Standard for Planned Changes
Incident communication is reactive. Planned change communication is proactive, and it is where most MSPs have the most room to improve.
Every planned change that could affect client operations should be communicated in advance: patch deployments, system updates, network changes, and any maintenance that requires downtime. The communication should include what is changing, when it is happening, what the expected impact is, and who to contact if something goes wrong.
The client who is surprised by a system restart during business hours because a patch was deployed without notice is a client who feels disrespected. The client who received a notification the day before explaining what was happening and why is a client who feels informed and cared for. The difference is a two-minute email.
The Communication Standard for Proactive Updates
The most underutilized communication opportunity in managed services is the proactive update: the communication that goes out when nothing is wrong, to tell the client what the MSP has been doing on their behalf.
A monthly summary of patches applied, security alerts reviewed, backup tests completed, and any issues identified and resolved proactively is a powerful retention tool. It makes the invisible work visible. The client who receives this summary every month understands what they are paying for. The client who never receives it wonders.
The monthly summary does not need to be elaborate. A brief email with four or five bullet points covering the most significant activities of the month is sufficient. The goal is not to impress the client with volume. It is to demonstrate that the MSP is actively managing their environment.
The Communication Standard for Bad News
The hardest communication in managed services is the one that delivers bad news: a breach, a failed backup, a mistake by a technician, or a service failure that caused significant impact. Most MSPs handle this poorly because they are afraid of the client’s reaction and hope that minimizing the communication will minimize the damage.
The opposite is true. The client who receives a prompt, honest, complete explanation of what went wrong is more likely to stay than the one who discovers the problem through their own investigation. The client who feels that the MSP is hiding something is the one who calls a competitor.
The bad news communication should be delivered by the account owner or the MSP’s principal, not by a technician. It should be delivered promptly, before the client discovers the problem on their own. It should be honest about what happened and what the MSP’s responsibility was. And it should include a clear explanation of what changed to prevent recurrence.
Building Communication Into Your Processes
The communication standard described above does not happen by accident. It happens because it is built into the workflow. The technician who closes a ticket without sending a resolution notification is not following the process. The account manager who does not send the monthly summary is not following the process. The MSP owner who does not send the post-mortem after a significant incident is not following the process.
Build the communication steps into your PSA as required tasks. The incident acknowledgment is a task that must be completed within 15 minutes of ticket creation. The post-mortem is a task that must be completed within 24 hours of incident resolution. The monthly summary is a recurring task that generates automatically on the first of each month. The communication standard is only as good as the process that enforces it.
Frequently Asked Questions
How do I communicate with clients who are not technical?
In business language, not technical language. The client who does not understand what a DNS failure is does not need an explanation of DNS. They need to know that their email was not working, that the problem has been resolved, and that a change was made to prevent it from happening again. Translate the technical explanation into business impact and business outcome. That is the communication that serves the client.
What if the incident is still ongoing when the update is due?
Send the update anyway. “We are still working on the issue. Current status: [status]. We expect to have an update by [time].” The client who receives a “still working on it” update at the scheduled time is less anxious than the one who receives nothing. The update does not need to contain a resolution. It needs to contain current status and the next update time.
How do I handle a client who is angry during an incident?
Acknowledge the impact before you explain the cause. The client who is angry because their business is down does not want a technical explanation first. They want to know that you understand the impact and that you are working to resolve it. Acknowledge the impact, confirm that you are working on it, and give them a timeline for the next update. The explanation comes after the resolution.
About Brent Lacy: Brent Lacy is a technology advisor and the voice behind Rewired MSP. He helps MSPs operate with greater maturity and helps business owners make IT choices that make them more secure and more efficient. He is the author of Rewired MSP: Mastery, Scalability & Performance, vCIO Rewired: Virtually Conquering IT Obstacles, and Near Miss: Preventable IT Failures Threatening Your Business Security.
