How to Manage Client Communication: An Agency Playbook

A slow reply is rarely what costs an agency a client. An unowned message is. When a question lands in email, Slack and the project chat, each person who sees it assumes someone else has it. The client then asks a second time, and a third. By then the question is no longer the problem. The silence is.

Knowing how to manage client communication starts with a few rules that every person on the team follows: where clients are allowed to reach you, who answers, how fast, and where decisions get recorded. Set those rules on purpose and client communication gets quiet and predictable. Leave them to habit and every client invents their own system.

This playbook walks through those rules in order, from channels to weekly status. Where a tool helps, we'll say so. A product such as 3 Loop can pull client email, Slack and project chats into one inbox, but the rules matter more than the software.

Key Takeaways

Choose the channels clients may use before the project starts, and say which one is for urgent matters.
Give every client exactly one named owner, so a message is never "someone's job."
Write reply-time rules your team can keep on a bad day, and track the messages that break them.
A decision only counts once it is written down and attached to the work it changes.
A short weekly status on a fixed day prevents most "any update?" messages.

Pick Your Channels on Purpose
Give Every Client One Owner
Set Reply Times You Can Actually Keep
Run the Waiting Routine Twice a Day
Get Decisions in Writing and Into the Work
Send a Weekly Status Clients Actually Read
Which Tool Fits Which Agency

Pick Your Channels on Purpose

Most channel trouble starts with a missing decision, not a difficult client. Nobody said which channel is for what, so clients choose by habit. One asks by email, one by Slack, one by voice note. The agency pays for that gap with duplicate replies and, sooner or later, one missed answer.

Give Each Channel One Job

Decide the job of each channel and write it down on a single page. Ours would look like this:

Email: decisions, approvals, files and anything you may need to find in six months.
Slack or project chat: quick questions that have a short answer.
Calls: anything tense, tangled or likely to take more than three back-and-forths.

Keep the page short. A rule nobody remembers is not a rule.

Tell Clients at Kickoff

Put the rules to the client in two or three plain sentences. For example: "We use email for anything you want us to act on. Slack is for quick questions. If something feels messy, let's jump on a call." Then ask where they already like to talk.

If a client lives in WhatsApp, you can bend a little, as long as the bend costs you almost nothing and decisions still end up in writing.

Handle the Client Who Uses Every Channel

Some clients will send one request across email, WhatsApp and Slack anyway. Do not fight it. Reply in the channel they used, so the conversation feels natural to them. Then log the request once, in one place, so your team has a single record instead of three half-copies.

A shared inbox with no owner rule fails in a predictable way. Everyone can see the message, so everyone assumes someone else has picked it up. Write the owner rule first, then pick the tool that supports it.

Give Every Client One Owner

Every client needs one named person who is answerable for every reply. Not a team. Not "whoever is online." One person, written down where everyone can see it.

What an Owner Is, and What They Are Not

An owner does not answer every message. A designer can reply to a layout question, and a developer can explain a bug. The owner makes sure every message gets an answer from someone, and that the client never has to chase.

Think of the owner as the person who can say, at any moment, "Here is who is waiting on us, and who has it." That is the whole job.

A Handover That Carries Context

When work changes hands and the context stays behind, the client has to explain everything again. They may also get an answer that contradicts what they were told last week, or see a closed decision reopened. They notice, and they start to wonder who is really running their project.

The fix is a short note in the shared thread, not a private message. Here is a worked example for someone going on leave:

Handover, Northside account. I'm out from Monday for two weeks. Priya is the owner until I'm back. Open items: the revised homepage mock is with the client and they promised feedback by Thursday. If it arrives, Priya sends it to Tom to apply. The invoice question is parked until I return. Last decision, in writing on the 3rd: the client chose option B for the footer. Do not reopen it.

That note holds four things: who owns it now, what is open, what is parked, and what was already decided. Use the same shape when you pass a request to a freelancer or change roles. Because it lives in the thread, the new person reads the history without asking anyone.

Name the Backup Before You Need One

Sickness and holidays do not send warnings. So agree on a backup for each client up front, and put the name next to the owner's.

One backup per client, never "the team."
The backup has read the thread and knows the open items before the owner leaves.
The client is told who covers, and for how long.

When an owner is out, the backup should open the list of waiting clients and start with the oldest.

Set Reply Times You Can Actually Keep

A reply-time policy is a promise, and a missed date does more damage than a slow answer. Clients can plan around a two-day turnaround. They cannot plan around a date the agency gave and then missed. Once that happens, they stop trusting every date and start chasing. So write a policy you can keep.

Split the Promise Into Four Parts

"We reply fast" means nothing. Break it into four commitments:

Acknowledgement: a short note that says "got it, we're on it."
A real answer: the first reply that moves the issue forward.
Resolution: the issue is closed, or a new date is agreed in writing.
Out-of-hours escalation: what a client does when something breaks at 9 p.m.

Here is an example policy for a ten-person agency. Acknowledge within the same working day. Give a real answer within two working days. Agree a resolution date in that answer. For genuine emergencies, clients call one named number, and only for site-down or launch-day problems.

The times above are examples, not industry claims. Pick times your team can hit on a bad Tuesday, when two people are out and a launch is slipping. Then tell clients those exact times in your kickoff doc.

Compare this with "we reply ASAP." To a client, ASAP can sound like "within the hour." To the team, it often means "when we can." That gap is where "any update?" messages come from. A stated time closes it, because the client already knows when the next reply is due.

Make the Policy Visible With Waiting Rings

A policy nobody can see gets ignored by week three. 3 Loop's features put client email, Slack and project chats in one inbox, and each conversation carries a waiting ring. The ring turns amber after an hour and red after a day.

You don't open every thread to find the problem. The oldest wait stands out at a glance. WhatsApp per agency is coming soon, but it is not available yet.

Ranking by wait time also fixes a common bias. Most inboxes sort by newest message or unread count. Both favour loud clients who send ten messages a day. The quiet client who wrote once, politely, sinks to the bottom and gets forgotten. Sorting by how long someone has been waiting puts that person back on top.

Gut feeling about urgency fails the same way. We tend to answer the message that feels tense, not the one that has waited longest. A visible clock removes the guesswork.

Tip: Review all red rings at the start and end of each day. If the same client keeps turning red, the problem is ownership or workload, not the tool.

Protect Deep Work

Fast replies should not mean constant interruption. Instead of reacting to every ping, set a few reply blocks a day. In 3 Loop, Focus mode then shows everyone who is waiting, one card at a time, longest wait first. You reply, send a card to the back, or mark that no reply is needed. The rings keep watch between blocks, so nothing quietly goes stale.

Run the Waiting Routine Twice a Day

Set two ten-minute passes: one at the start of the day, one mid-afternoon. In each pass, do three things. Find the oldest unanswered client request. Give it one owner. Write down the next action and when it will happen.

Do not turn this into a meeting. One person per client runs it alone, or the account lead does a quick sweep across the team. The point is that nothing sits unowned overnight.

The Six States

Every conversation sits in one of six states. Keep the list short so people actually use it.

New: a client message nobody has picked up yet.
Assigned: someone owns it and has said so.
Waiting on agency: we owe the client a reply, file or answer.
Waiting on client: we sent our part and need something back.
Escalated: the owner is stuck or the client is unhappy, so a lead steps in.
Resolved: the request is done and the outcome is written in the thread.

A typical path: a logo feedback email arrives (New), Priya takes it (Assigned), she sends revised files (Waiting on client), the client approves (Resolved).

Waiting on Us Versus Waiting on Them

Be strict here. If the ball is in our court, the clock is ours. If it is in theirs, the owner chases. We suggest one polite nudge after two working days of silence. If that goes unanswered, the account lead calls or escalates.

Red Ones First

Start with the oldest items. For each one, pick one move: reply, reassign, or call. Then write the outcome back to the thread so the next person sees it. A shared view makes this fast, because the oldest client sits at the top of your pass without any digging.

Get Decisions in Writing and Into the Work

A client saying "looks good" is not a decision. A decision has four parts: what was approved, who approved it, which version they saw, and how many revision rounds are left. If any of those is missing, you will argue about it later.

Your clients are rarely the problem here. Vague sign-off is. Treat approval as a record, not a mood.

Walk One Request Through Three Channels

Here is how a single approval often travels. A client emails "approved, go ahead." Two days later they send a WhatsApp message asking if the footer can change. A teammate nudges them in Slack about the final logo. That is one decision spread over three places.

Pull it into one record:

Log the email approval against the version and the project.
Treat the footer question as a scope check. Is it inside the current round or a new one?
Attach the Slack nudge to the same thread so the history reads in order.

Once these land in one inbox, the approval can sit on the task it belongs to. Nobody has to search three apps to prove what was said.

Close the Loop With a Same-Day Recap

Calls and chat decisions need a written echo. Send a short recap the same day:

"Confirming we agreed to use version 3 of the homepage."
"One revision round remains."
"Final files due Friday unless you tell us otherwise."

Ask for a one-word reply. That reply is your record.

Let Sign-Off Update the Work

A recorded decision should change something. When a client approves, the task closes. If scope grew, the deadline moves. The client-facing status then shows the change without anyone retyping it. This chain, from approval to task to delivery date, is what stops "I thought we agreed otherwise" from eating your week.

Send a Weekly Status Clients Actually Read

A weekly status works because it is predictable. Clients learn where to look, and you stop writing a new email every Friday. Keep the format fixed and short.

The Five-Line Format

Done this week: three to five items, plain language.
Planned next week: what you will start and finish.
Waiting on you: each item with an owner and a date.
Decisions made: what was agreed, and where it was confirmed in writing.
Risks: anything slipping, stated early and without drama.

Bad news belongs in that last line, not buried in a call. A client who hears "this may slip by two days" on Tuesday is calmer than one who finds out on Friday.

Cut What Clients Tune Out

Put your ask in the first two lines. If the client needs to approve a design or send a login, say so before anything else. Most people read the top of an email and skim the rest.

Drop task-level detail, internal debates and hour counts unless the client asked for them. Short bullets beat paragraphs. If a status takes more than a minute to read, it is too long.

Let the Portal Do the Chasing

A client portal at your agency's own address gives clients one place to see status and approvals. They stop writing "any update?" because the answer is already there. Approvals stay with the work, so nobody digs through a thread to find who said yes.

Use one rule to split the two. Status and approvals live in the portal. Questions, quick opinions and urgent changes stay in the inbox. A status is something the client looks up, so it should never need a reply. A question is something your team owes an answer to, so it belongs where your team can track the wait.

Which Tool Fits Which Agency

Choose by three things: team size, the channels your clients actually use, and whether project work must sit in the same place. Each kind of tool wins somewhere.

A full help desk suits larger teams with many agents answering high volumes. It beats an agency-focused tool on queues, reporting and automation, but project work and approvals sit outside it.
A simple project tool with client logins suits a small team whose clients are happy to write inside it. If almost nobody emails, it is the easier pick.
A heavy task manager suits teams that want deep task control and will train clients to use it. It takes real setup, and clients who reply by email still need someone to copy their answers into tasks.
One inbox for client email, Slack and project chat suits small and mid-size agencies whose clients stay in the channels they already use. It shows who is waiting, with tasks and approvals alongside.

Whichever you pick, it will not repair a missing owner. The rule that does the most work is also the simplest: one named owner per client, and a reply-time promise your team can keep on a bad day. On Monday, write the owner's name and the backup's name next to every active client. Then send each client the reply times you will meet.

If you want that owner to see every waiting client in one place, Request early access and try one inbox with waiting rings across client email, Slack and project chat.

Frequently Asked Questions

How many channels should an agency allow clients to use?

Two or three is plenty: email for decisions and files, Slack or project chat for quick questions, and a call for anything tense or tangled. Add a fourth only when a client already lives there and the cost to you is close to zero. The rule that matters more than the count is that every decision still ends up in writing, attached to the work it changes.

What should we do when a client keeps ignoring our process?

Reply in the channel they used so the conversation feels natural, then log the request once in your own system. Do not lecture them about the rules in the thread. Raise it calmly on a call or in the weekly status, and restate the two or three channel rules in plain words. Most clients follow the process once they see that it gets them faster answers.

Does one shared inbox replace a project management tool?

No. An inbox shows who is waiting on you, while a project tool tracks tasks, deadlines and approvals. Keeping the two connected is what stops decisions from drifting away from the work. 3 Loop is built for that pairing, with client email, Slack and project chats in one inbox and tasks and approvals alongside. If your team already runs on another project tool and only needs shared email, a simpler setup may be enough.

Can we use WhatsApp with 3 Loop today?

Not yet. WhatsApp per agency is coming soon in the platform, so please do not plan around it today. For now, build your process around email, Slack and project chat. If clients message you on WhatsApp in the meantime, log each request once in your shared record so nothing lives only on a personal phone.

How do we keep fast replies from wrecking focus time?

Separate being responsive from being interrupted. Set your reply-time rules so a short acknowledgement is enough, and answer in a few set blocks a day instead of on every ping. Waiting rings keep tracking each client between blocks, turning amber after an hour and red after a day. When a block starts, Focus mode shows the longest wait first, so nothing quietly goes stale.

How to Manage Client Communication Without Losing Replies