The problem: silence or a wall of jargon
Most agencies fall into one of two traps when something breaks on a client site. Either they say nothing until the client discovers the problem themselves and calls in a panic, or they send an email full of terms like "502 error," "DNS propagation" and "cron job" that the client doesn't understand — and that still leads to the same anxious phone call. Both paths cost time and trust.
The fix isn't more technical detail. It's the right information, in the right order, at the right time. Clients rarely call because they want to know why a server timed out. They call because they want to know three things: is this serious, do you know about it, and when will it be fixed.
Build communication around three questions, not technical facts
A good incident update always answers:
- What do you notice from it? Describe the symptom from the client's point of view — the site won't load, checkout can't be completed, login isn't working. Not "the monitor reported a timeout on the synthetic flow."
- Do we know about it, and since when? Give a timestamp. It shows you caught the problem before the client did — or very close to when it started.
- What happens now, and when will you hear from us again? A concrete next step and a time for the next update — not "we're working on it."
Everything else — error codes, log excerpts, which plugin was involved — belongs in an internal log or a follow-up report, not in the first message.
An example of the structure
Instead of: "We saw a 503 error from the load balancer that correlates with a plugin update at 14:02, investigating whether it's cache-related."
Write: "The site was unavailable to visitors between 14:02 and 14:19. Our monitoring flagged it within a minute and we identified a likely cause within 15 minutes. A fix has been applied and we're watching the site closely for the rest of the day. No further action is needed on your end."
Same event, same honesty about what happened — but the client gets answers to their questions instead of new ones.
Be transparent about uncertainty — without guessing out loud
Sometimes you don't know for certain what caused a problem, especially early on. It's completely fine to say that — but do it in a way that builds confidence rather than worry.
Use graded confidence in your internal analysis (for example: low, medium, high, confirmed) but in client communication it's enough to say: "We've identified a likely cause and are verifying it now" or "The cause has been confirmed and resolved." Avoid stating that a specific change caused the problem unless you've actually verified that through a test — say it coincided in time with the problem if that's all you know in the moment.
This isn't just semantics. If you point to the wrong cause and then have to walk it back, you lose credibility faster than if you'd said nothing at all.
Proactive communication beats reactive every time
The single biggest factor in how many worried calls you get isn't how good your message is — it's whether you reached out before the client called. A client who gets a message saying something is resolved feels looked after. A client who has to call and ask "are you aware of this?" feels forgotten, even if you were already working on it.
This requires knowing about the problem before the client does. External monitoring that checks the site every minute, with alerts confirmed from a second location before they go out, means you're usually able to send that first message before the phone rings.
Status pages make communication scalable
For agencies with many client sites, individual emails become unmanageable during larger incidents. A public status page per client or per service solves this: the client can check status themselves instead of calling, and you can link the same page in every channel. The status page should show the same three things as above — current status, timeline, and next update — without technical jargon.
After the incident: the report is the other half of client dialogue
Once the incident is resolved, it's worth sending a short summary — ideally as part of your recurring reporting. Here you can go a little deeper, but still without drowning the client in log data:
- What happened, in plain language
- How long it lasted and what impact it had
- What was done to fix it
- What you're doing to reduce the risk of it happening again
This closes the loop and shows the client you were in control throughout — which is exactly what prevents the next worried phone call.
Set a clear internal process, not just a template
A good template doesn't help if nobody knows when to send it. Decide in advance:
- What type of incident requires client communication (and what doesn't)
- Who writes and sends the first message, and within what time of the alert
- How often follow-up updates go out if the incident drags on
- Where status information is shown publicly, if at all
With the right monitoring underneath — flagging problems before the client does, and giving you a likely cause to lean on instead of guesswork — this whole process becomes much easier to sustain. You communicate from facts you already have, rather than chasing information while the client is on the phone.
