Nick QuirkYou know the thread. It started as "quick question about the meta titles." Fourteen replies later it includes your strategist, two designers, the client's CMO, someone from their dev agency, and a forwarded PDF nobody opened. Somewhere in the middle a scope change got approved by accident. Nobody can find it.
Reply-all chaos isn't a personality problem. It's a systems problem. Clients default to email-everyone because you never gave them a better default. Fixing client communication for agencies is less about etiquette lectures and more about building channels so obviously useful that the inbox stops being the path of least resistance.
Why reply-all happens (and why it's expensive)
Clients CC everyone for three reasons, and none of them are malice:
- Uncertainty about ownership. They don't know who actually handles the request, so they hit everyone and let you sort it out.
- Fear of being ignored. A previous message went unanswered for four days. More recipients feels like more insurance.
- No visible record. They can't see status anywhere, so email becomes their project tracker.
The cost is real and measurable. Run a rough count on your own team: if five people are on a thread and three of them read every one of 14 messages, that's 42 reads for a question one person could have answered. At 90 seconds per read with context-switching, you burned an hour of billable time on a meta title.
Worse is the decision-loss problem. When approvals live in threads, nobody can prove what was agreed. I've watched agencies eat a full month of work because a client "approved" a sitemap change in the sixth reply of a thread the PM had muted. There was no dispute about intent — just no findable record.
Build a channel map before you build anything else
The single highest-leverage fix is a one-page channel map that you walk through during kickoff. Not buried in an appendix — actually read aloud on the call, then pinned in your shared space.
A channel map that works for SEO and marketing retainers
- Project comments (in your PM tool): feedback on deliverables, approvals, anything that changes scope or timeline. This is the system of record.
- Shared chat channel: questions needing an answer within a few hours. "Is the Q3 report still going out Thursday?" Explicitly labelled as not a place for approvals.
- Email: contracts, invoices, legal, and anything involving people outside the project.
- Calls: strategy, bad news, and anything that took more than three rounds of written back-and-forth.
That last rule is underrated. Institute a three-reply rule: if a written thread hits three exchanges without resolution, someone books a 15-minute call. It kills the 20-message threads that consume a Tuesday.
Name one owner, loudly
Every client gets exactly one named point of contact, with a named backup for holidays. Put both names and the response-time commitment in the channel map: "Sarah responds within one business day. If Sarah is out, Mark covers." Clients CC broadly when ownership is fuzzy. Remove the fuzziness and the CC habit fades on its own.
The weekly update that kills 80% of inbound email
Most "just checking in" emails are anxiety, not information requests. A predictable written update removes the anxiety. Same day, same time, same format, every week — even in quiet weeks. Especially in quiet weeks.
Keep it to four blocks and under 200 words:
- Shipped this week. Three to five bullets with links to the actual deliverable.
- Next week. What's in flight, with dates.
- Blocked / needs you. Named person, specific ask, deadline. "Need dev access to staging by Wednesday or the Core Web Vitals sprint slips a week."
- Numbers. Two or three metrics that matter — not a 40-tab dashboard dump.
The "needs you" block does double duty. It documents client-side delays in writing, week after week. When a timeline slips because you waited 11 days for CMS credentials, you have a paper trail that isn't accusatory — it's just the update you always send. That's a big part of why deadlines get missed and how to avoid taking the blame for them.
Make the work the conversation
The structural fix behind all of this: conversations should live attached to the thing they're about. Feedback on a content brief belongs on the brief. Questions about an audit finding belong on that finding. When the thread and the artifact are the same object, three things stop happening — lost context, duplicate questions, and "which version is current?"
This is where generic tools struggle for agencies. Many are built for internal teams, so client-facing views are an afterthought: you either expose your whole workspace including internal notes and margins, or you don't invite the client at all and end up back in email. If you're evaluating options, the best project management tools for agencies roundup compares how each one handles client access specifically, and the tool comparison hub goes deeper on individual platforms. PeakKR was built around this problem — client-facing project views and reporting that show progress without exposing internal time and margin data.
Keep a decision log
One running list per project. Every entry has four fields: date, decision, who approved it, and the impact on scope or timeline. Add an entry the moment a decision lands, before you do the work.
Example: "2024-03-12 — Client approved changing target keyword for /pricing from 'seo pricing' to 'seo agency cost.' Approved by Dana Reyes. Adds 4 hours (competitor re-analysis + brief revision), pushes publish from Mar 22 to Mar 27."
Two lines. It ends 90% of scope arguments before they start, because the trade-off was visible when the decision was made rather than three weeks later on an invoice.
Handle the requests hiding inside threads
Reply-all threads are where scope creep breeds. Someone writes "and while you're in there, can you fix the blog category pages?" — a four-hour job buried in paragraph two of a message about something else.
Build a reflex: every inbound request gets routed, not answered inline. Move it into the project as a task with an estimate, then reply with the trade-off. "Happy to take the category pages on — that's about four hours. I can pull it into this sprint if we push the internal linking work to next month, or add it as extra hours. Which do you prefer?"
Notice that isn't a no. It's a priced choice, which clients respond to far better than refusal. If you struggle with this, the guides on saying no to out-of-scope requests and client boundary setting have scripts you can lift directly.
Migrating a client who lives in email
You can't announce a new system and expect compliance. You have to redirect, patiently, for about three weeks.
When a reply-all lands, do this: answer the question in one sentence, then move it. "Short answer: yes, we can. I've logged this as a task here [link] with the timing — let's keep the detail there so it doesn't get lost." Then reply only to the sender, not all.
Do that four or five times and most clients switch, because the new channel genuinely gets them faster answers and a visible status. The ones who don't switch usually have an internal reason — often they're forwarding your updates to a boss who demands email. Ask directly, then send them a short email summary with a link to the real thread. Solve their actual problem and the resistance disappears.
Reduce the number of places a conversation can happen
If your agency runs Slack, email, a PM tool, Google Docs comments, Loom replies, and a shared spreadsheet, clients will use all six — and you'll answer the same question three times. Consolidation is a communication fix, not just a cost fix. If that sounds like your setup, curing the Franken-system is the prerequisite to any of this working.
Aim for two client-facing surfaces. Three maximum. Anything more and the channel map becomes fiction.
Your reply-all fix checklist
- Write a one-page channel map: which channel for which purpose, read aloud at kickoff
- Name one account owner plus a backup, with a stated response-time commitment
- Adopt the three-reply rule — book a 15-minute call instead of a fourth exchange
- Send a weekly written update, same day and format, with a "needs you" block
- Keep a decision log with date, decision, approver, and scope/timeline impact
- Route every inbound request into a task with an estimate before answering it
- Reply to reply-alls sender-only, with a link to where the conversation now lives
- Cut client-facing channels to two or three; kill the rest
- Review the channel map at the 90-day mark and fix whatever drifted
None of this requires a hard conversation about email etiquette. Give clients a place where answers are faster and status is visible, and reply
