A client communication plan is a one-page agreement covering five things: the cadence of formal updates, which channel is used for what, response time expectations in both directions, who the single named approver is, and the escalation path when something goes wrong. Agree it during kickoff, not after the first misunderstanding. Start new clients at a weekly cadence for the first 60 to 90 days regardless of project size - it calibrates expectations while the stakes are low - then reduce it once the rhythm is established. Most agency-client friction is not a communication failure, it is the absence of an agreement about communication.
Ask an agency why a client relationship went wrong and "communication" is the answer roughly half the time. It is almost never the real answer.
Communication is where the problem surfaces, not where it originates. The client who complains they were "kept in the dark" usually means something more specific: they did not know a decision was being made, or they found out about a delay from someone else, or they sent a message on Friday and heard nothing until Tuesday and had no idea whether that was normal.
None of those are failures to communicate. They are failures to agree, in advance, what communication would look like.
This guide covers the five components of a communication plan, how to set the cadence, the channel discipline that prevents most confusion, how to handle response times honestly, and what changes when the project is in trouble.
Why a plan beats good intentions
Every agency intends to communicate well. Intentions produce inconsistency, because in the absence of a rule, communication frequency tracks how busy you are - which means it drops precisely when the project is under pressure and the client most needs to hear from you.
That inverse relationship is the whole problem. A client hearing less from you during a difficult phase concludes, reasonably, that something is being hidden. Usually nothing is; the team is heads-down and nobody has capacity for an update.
A written plan fixes this because it makes the update a commitment rather than a courtesy. It also gives you something to point at when a client's expectations drift - which they will, without malice, simply because nothing anchored them.
The five components
Keep the whole thing to one page. A communication plan nobody reads is worse than none, because it creates the illusion of agreement.
1. Cadence
When formal updates happen, in what format, and from whom.
A workable default for a multi-week project:
- Weekly written update, same day each week, sent whether or not there is news.
- Fortnightly call, 30 minutes, with an agenda sent in advance.
- Milestone reviews at agreed points, longer, with decisions required.
The detail that matters most: the weekly update goes out even when nothing has happened. "This week: continued build on the checkout flow, no blockers, on track for the 14th" takes ninety seconds to write and prevents the single most common client anxiety, which is silence.
An update that only appears when there is news teaches the client that silence is ambiguous. An update that always appears makes silence impossible, and it means a genuinely bad week's update lands as part of a rhythm rather than as an alarm.
Start new clients weekly for the first 60 to 90 days, regardless of project size, then reduce. The early period is when expectations are being set and misalignment is cheapest to correct. Rework's guidance on communication cadence makes this point directly, and it matches what most agencies discover the hard way: the cost of over-communicating early is a few hours; the cost of under-communicating early is a relationship that never quite settles.
2. Channels, and what each is for
The most common source of low-grade confusion, and the cheapest to fix.
Without a rule, requests arrive by email, chat, comments, phone and occasionally text. Some get actioned, some get lost, and nobody can reconstruct what was agreed because the record is spread across five systems.
A simple, workable allocation:
- Project system - anything that is a request, a decision, or feedback on work. If it needs doing, it lives here.
- Chat - quick questions and coordination. Explicitly not a place to make requests, because chat has no state and no owner.
- Email - formal matters: scope changes, contracts, invoices, anything either side might need to reference in six months.
- Calls - discussion, decisions and anything with emotional content. Followed by a written summary, always.
The rule that makes this work: if it is not written in the project system, it is not a request. State it kindly, early, and hold it consistently.
The holding is the hard part. A client sends a request by chat, and the path of least resistance is to just do it. Do that twice and chat is now a request channel, whatever the document says. The right response takes ten seconds: "Good idea - can you drop that in as a task so it doesn't get lost?"
That sentence protects the record, and the record is what makes scope conversations possible later. Our guide to preventing scope creep covers why an unwritten request is effectively an invisible one.
3. Response times, both directions
State what the client can expect from you, and what you need from them. The second half is the one agencies leave out, and it is the one that saves projects.
From you: something like acknowledgement within one working day, substantive response within two. Note that acknowledgement and resolution are different promises - "I've seen this, I'll come back Thursday" satisfies the first and buys time for the second. Most clients are entirely happy with a slower resolution and very unhappy with silence.
From them: feedback within three working days, approvals within five. Say plainly what happens if that slips - not as a threat, as arithmetic. "Each week of delayed feedback moves the launch date by a week, because the team scheduled for the next phase moves on."
Naming the dependency at kickoff, when nobody is defensive, is enormously easier than raising it in week six when the date is already at risk. It also reframes lateness from your failure to a shared timeline, which is what it actually is.
4. One named approver
Write down who signs things off.
Projects with three stakeholders and no named decision-maker generate contradictory feedback, and contradictory feedback generates rework that nobody agreed to pay for. It is one of the largest hidden costs in agency delivery.
The plan should say: feedback may come from anyone, but it is consolidated by one named person, and that person's approval is the approval. If two pieces of feedback conflict, you go back to them rather than guessing - and guessing is what happens by default, usually in favour of whoever spoke most recently or most loudly.
Also worth naming: who deputises when the approver is on leave. Two weeks of absence with no delegate has stalled more projects than any technical problem.
5. The escalation path
What happens when something is wrong, agreed while nothing is.
Two directions:
When they are unhappy: who they raise it with, and what happens next. Usually: account lead first, and if unresolved within a stated window, whoever is above them. Naming a route makes escalation feel legitimate rather than dramatic, which means problems surface earlier and smaller.
When you have a problem: how you will tell them. A commitment to raise risks as soon as they are known rather than when they become certain. This is worth writing down because it is a promise about behaviour under pressure, which is exactly when it is hardest to keep.
What changes when a project is in trouble
The plan above describes the normal state. Trouble requires a deliberate change, and the instinct - communicate less until there is something good to report - is exactly wrong.
Increase the frequency, not decrease it. A project that is late needs more contact, not less. Move to a short daily note if necessary. It feels counterintuitive because you have nothing good to say; the client's anxiety is not about the news, it is about not knowing.
Lead with the situation, not the explanation. Forbes Agency Council's piece on communicating with difficult clients is useful on framing here. The structure that works: here is the situation, here is our plan, here is what we need from you. That reads as professional problem-solving. Opening with why it happened reads as a defence, regardless of how valid the reason is.
Say the bad news first, at the top. Not paragraph four. A client who finds a delay buried after three paragraphs of progress concludes it was hidden, and that inference is far more damaging than the delay.
Never let them find out from someone else. The worst version of a delay is a client hearing about it from their own developer, their agency partner, or a date that simply passes. Whatever the plan says about frequency, a material change gets communicated immediately.
Our guide to difficult client conversations goes further into the specific conversations - scope, delays, non-payment, results.
Reporting, and how it differs from updating
Two different things, often conflated.
An update answers "what is happening?" Short, frequent, operational.
A report answers "what did we achieve, and what did it cost?" Longer, periodic, tied to objectives and money.
Both are needed and they serve different readers. The update is for your day-to-day contact. The report is for whoever approved the budget - and it is the document that determines renewal, whether or not anyone says so.
Swydo's guidance on client reporting is worth reading on the structure. The single most useful principle: a report should open with the answer, not the data. What happened, what it means, what you recommend - and then the numbers that support it. Reports that open with a wall of metrics make the reader do the analysis, and busy readers do not.
The practical constraint is that building reports by hand across a dozen accounts is genuinely a part-time job, which is why it degrades by month four. Reporting has to be largely a by-product of the work rather than a separate deliverable, which is the argument for a client portal where status is continuously visible rather than periodically assembled.
Cadence by project type
The default above suits a multi-week project. Three variations worth knowing.
Short projects (under four weeks). Weekly updates are too coarse - a quarter of the project passes between them. Move to twice-weekly written notes and drop the formal call entirely; a short project rarely justifies a standing meeting, and the meeting tends to become the project's main risk to the timeline.
Long projects (three months or more). Weekly updates become noise by week eight, and people stop reading them - which is worse than not sending them. Shift to a fortnightly written update plus a monthly review tied to milestones, and be disciplined about the review having decisions on the agenda rather than being a status recital.
Retainers. The cadence question is different, because the client's real question is not "is it on track" but "what am I getting for this". A monthly summary tied to the allocation - hours used, work delivered, what is queued - matters more than frequent progress updates. Our guide to retainer models covers why visible burn is the single most important reporting element in an ongoing arrangement.
When there are several stakeholders
Most communication problems on larger accounts are stakeholder problems wearing a communication costume.
Map who cares about what, once, at kickoff. The marketing manager wants weekly detail. The director wants a monthly outcome summary. Finance wants the invoice to match the PO. Sending all three the same update means two of them ignore it, and the one who needed something different concludes they were not kept informed.
Write for the least-contextual reader. Any update that might be forwarded upward should be intelligible to someone who was not in the room. In practice this means expanding acronyms, restating the objective in a line, and leading with the outcome rather than the activity.
Route feedback through the named approver anyway. Multiple stakeholders can receive updates; only one consolidates feedback. If a second stakeholder starts sending direct instructions, redirect early and kindly - "let me pull that into the main thread so Sarah can weigh it against the other priorities" - because the alternative is contradictory direction that produces rework nobody agreed to fund.
What to do when the plan is being ignored
Plans drift. Two failures are common and both have a straightforward repair.
The client keeps using the wrong channel. Requests arriving by chat or in reply to unrelated emails. The repair is consistent, low-friction redirection - "great, can you drop that into the workspace so it gets picked up?" - every single time, without exception. Two exceptions and the rule is gone. It feels pedantic for about a fortnight and then it simply becomes how you both work.
Your own cadence slips during a busy phase. More damaging, because it is the exact moment the client most needs to hear from you. The repair is to lower the bar rather than skip: a three-line update sent on time beats a thorough one sent late, and beats nothing by an enormous margin. If the update becomes something that requires an hour to prepare, it will not survive a difficult month - so design it to take ten minutes.
If both sides have drifted, reset explicitly rather than quietly. "I don't think we've been sticking to what we agreed on updates - let's go back to Wednesday summaries from this week." Naming it takes thirty seconds and restores the agreement; letting it drift means you no longer have one.
Async and distributed clients
If the client is in another timezone, the plan needs two adjustments.
Written-first becomes mandatory. Anything that would have been a quick call has to be a well-structured message, because the round trip is 24 hours. That is a real skill: state the context, the question, the options, and what you will do by default if you do not hear back. That last clause is what prevents a timezone gap from becoming a week of blocked work.
Overlap hours get protected. Whatever window you share, treat it as the escalation channel and keep it clear. Two hours of genuine overlap, used well, is enough for almost any project.
Writing the plan
The whole thing fits on one page. A workable skeleton:
Communication plan - Northwind website rebuild
Cadence. Written update every Wednesday. Fortnightly call, Tuesdays 10am, 30 minutes, agenda in advance. Milestone reviews at design sign-off and pre-launch.
Channels. Requests, feedback and decisions in the project workspace. Quick questions in chat. Contracts, invoices and scope changes by email. Calls followed by a written summary.
Response times. We acknowledge within 1 working day and respond substantively within 2. We need feedback within 3 working days and approvals within 5; each week of delay moves the delivery date by a week.
Approver. Sarah Chen is the named approver. Feedback may come from anyone and is consolidated by Sarah. In her absence, decisions go to Mark Ellis.
Escalation. Concerns to James (account lead) in the first instance. If unresolved within 5 working days, to Priya (director). We will raise risks to the timeline or budget as soon as we identify them, not when they are confirmed.
Six short sections. Agreed at kickoff, sent in writing, and referred to when something drifts.
The weekly update, in detail
Since the weekly written update is the highest-return element, it is worth being specific about the format. Five short blocks, in this order, and it should take under ten minutes to write:
Status in one line. On track, at risk, or off track. Say which, plainly, at the very top. A client who has to infer status from a paragraph of activity will infer wrongly.
What moved this week. Three or four bullets, outcomes rather than tasks. "Checkout flow built and in internal QA" rather than "worked on checkout."
What is next. The coming week, briefly. This is what stops the client wondering whether the right things are being prioritised.
Anything we need from you. The most important block, and the one most often omitted. Name the person, the item and the date. If nothing is needed, say "nothing this week" - the absence of the block reads as an oversight.
Risks or changes. Anything that might affect date, scope or cost, however tentative. Raising something that later turns out to be fine costs nothing. Not raising something that turns out to matter costs a great deal.
The discipline that makes this work is sending it on the same day every week whether or not there is news, from the same person, in the same format. Predictability is most of the value: a client who knows Wednesday's update is coming does not send Tuesday's "any progress?" email.
The three habits that matter more than the document
Having written all that: the plan is necessary and not sufficient. Three habits carry more weight.
Send the update even when there is nothing to say. Discussed above, and it is the highest-return habit on this list.
Write down what was decided on every call. Three bullets, sent within an hour. Not minutes - decisions and owners. This single practice eliminates most "I thought we agreed" conversations, and it costs five minutes.
Tell them early when something is wrong. The instinct is to wait until you have a solution. The cost of that delay is that the client loses the ability to help - and quite often they could have, by relaxing a constraint or moving a date you did not know was movable.
A communication plan is really just these three habits made explicit enough that they survive a busy month. Which is the point: good communication under calm conditions is easy and tells you nothing. The plan exists for the fortnight when everything is on fire, and its value is that it removes the need to decide, in that fortnight, how much to tell the client.