Client communication tool: A 40-point test before you add another channel

Pick a client communication tool on one criterion: whether it turns what a client says into something you can retrieve, unchanged, months later. Channels are easy to add and almost impossible to search. A tool earns its place by leaving behind a record — a filled-in field, a time-stamped approval, a named file sitting next to the question it answers.

That criterion splits a crowded category in two. Most roundups line up ten products as if they were substitutes: a help desk beside a video app beside a messaging platform. They are not substitutes. Some carry conversation. Some capture decisions. You need both, and the expensive mistake is using one for the other's job.

Transport tools and capture tools solve different problems

Transport moves words between people. Email, group chat, SMS, video, a shared inbox — all transport. They are optimised for speed and for the last message, which is exactly what you want during a build week.

Capture converts input into structure. A briefing form with required fields, an upload bound to the item it belongs to, an approval with a version number and a timestamp, an export you can hand to a developer. Capture is optimised for the thing you will need in November about a decision made in March.

Here is the test that separates them. Ask the tool: *what did the client approve, when, and against which version?* If answering requires a human being to scroll, you are holding a transport tool. That is not a criticism — it is a job description. It only becomes a problem when the approval that triggers an invoice lives in message 214 of a channel with a retention limit nobody checked.

Seven categories, and what each one loses

Every category is good at something and quietly destroys something else. The right-hand column is the one worth reading.

Nobody runs one of these. Two or three is normal and healthy. The failure is not the count; it is letting the same fact exist in two places, because then neither is authoritative and you end up asking the client a third time.

Disclosure while we are here: cluein.me is our product, and it sits in the last row. It collects briefings, files and approvals through one portal link, then exports the lot as a ZIP with a structured JSON and Markdown brief. That is a category choice, not a claim that it beats a help desk — it does a different job than a help desk.

The five-artefact test: 60 seconds, one year later

Before you evaluate anything new, measure what you have. Pick a project you delivered roughly twelve months ago. Set a timer for sixty seconds and find five things:

1. The approved scope statement and the date it was approved. 2. The final logo source file — the actual vector, not a screenshot pasted into a thread. 3. The exact homepage hero copy the client signed off, distinguishable from the four drafts around it. 4. Who holds the domain registrar login, or where that is written down. 5. The written approval for the one thing the client later complained about.

Score it honestly. Four or five found means your capture layer works and any tool discussion is about convenience. Three or fewer means the gap is structural, and swapping chat apps will not touch it.

Number three is the one that fails most often. Copy gets approved verbally on a call, edited in a doc, re-approved by email with "yes perfect", then quietly changed once more in a comment — and none of those four events knows about the others.

A 40-point fit score for any client communication tool

Score each criterion 0 to 5. Do it for the tool you already use before you score a candidate; the comparison is more useful than either number alone.

Read the total against three bands:

• 32–40 — this can be your system of record. Everything else becomes optional transport.
• 20–31 — usable as transport, but you need a separate capture layer or the five-artefact test will keep failing.
• Below 20 — fine for conversation. Keep project decisions out of it while the project has a fixed scope and money tied to sign-off.

One weighting note. If you work with clients in the EU or handle their customer data, treat criterion 8 as a gate rather than a score, and answer it with your own legal advice and the provider's data processing terms — not with a feature list.

The message-count model: where the tracking cost hides

This is a model, not a measurement. The point is the shape, and you should replace every assumption with your own.

Take a website relaunch. Count the discrete inputs you need from the client: logo files, brand guidelines, copy per page, image rights, the integrations list, analytics access, hosting credentials, legal pages, launch date, decision-maker. A mid-size relaunch lands around 24 items.

Now assume how they arrive over email:

• 60% answered on the first ask — 14.4 items
• 40% need one reminder — 9.6 extra messages
• 15% of the total need a second reminder — 3.6 more

That is roughly 37 tracked exchanges for 24 items. You will not send 37 separate emails, of course — you batch them. Batching does not reduce the number of items you are tracking, it just hides the count inside a thread.

Put 90 seconds against each exchange for reading, judging whether the answer is usable, renaming and filing an attachment, and updating your own list. The model gives about 56 minutes of pure tracking per project, none of it design work, and none of it counting the client's time.

The structured path is three touches: send the link, nudge on day three, nudge on day seven. The 24 items arrive as fields you review in a batch — call it 45 seconds each, so roughly 18 minutes.

Scale it and the rule appears. At one new project a month, the difference is under 40 minutes and your tooling is not your problem. At five new projects a month, the same assumptions put tracking near 4.5 hours against roughly 1.5. If your own numbers land under about two hours a month, fix your checklist, not your stack.

One honest caveat, because the model invites an overclaim: structured intake does not make clients answer. It makes the unanswered items visible without you rebuilding the list from a thread every Monday.

Four failure modes and the sentence that gives each one away

The decision that only exists in a call. Early sign: you catch yourself starting a sentence with "I'm fairly sure we agreed…". By then it is already a negotiation. The fix is boring — a written recap the same day, filed in the capture tool rather than replied into the chat.

The client inside your internal workspace. Early sign: a team member rewrites a message before sending it because the client might be reading. You have traded candour for convenience. Give the client their own surface.

Assets arriving as messages. Early sign: your downloads folder is functioning as an asset library and you are looking at logo_final_final_v3(2).png. Uploads need to be bound to the question they answer, or the naming problem becomes permanent.

The eight-month-later request. A former client asks for "the file". If that takes more than a minute, you never actually closed the project — you just stopped working on it. Produce an exportable archive per project at close and this failure disappears.

There is a fifth, quieter one. The client answers your brief in nine minutes flat and you feel good about it. Then you notice which questions they skipped: budget range, who signs off, who owns writing the content, and which dependency blocks launch. Those four are skipped more than any others because they are the only ones that cost the client something to answer. A free-text brief lets them slide; a required field does not.

Choosing by team shape rather than feature list

• Solo, up to three concurrent projects. Email plus one structured intake form. Adding a chat tool here adds a channel to monitor without removing one — a net loss.
• Two to five people, four to ten concurrent projects. One chat workspace or shared inbox, plus a portal per project. The dividing rule: the portal owns anything you would need in a dispute, the chat owns anything you will have forgotten in a week.
• Six or more, with retainer clients. Add ticketing, because now you have a request queue and not just projects. Keep it separate from project intake; a support ticket and a project brief have almost nothing in common structurally.
• Any size, if you subcontract. Export format becomes the binding constraint. Whatever you choose has to produce a package a freelancer can open without an account on your platform.

If you are working through this properly, the longer version of the selection logic sits in our guide on how to choose client portal software for your agency, and the feature-level comparison lives in web designer client management tools. For website builds specifically, the lane-by-lane version of this decision is in choose by traffic type, not features.

What clients will actually do

Rank every candidate tool by the number of steps it imposes on a client before they can give you what you need:

• 0 steps — they reply to your email.
• 1 step — they click a link and fill something in.
• 2 steps — link, plus downloading an app.
• 3 steps — creating an account with a password.
• 4 steps — an account, an invitation from your team, and a new interface to learn.

Each added step is a step you have to be prepared to chase. If your client is a twelve-person business with no operations person, assume anything above one step gets done late, gets done by their assistant with half the information, or gets done by you on a screenshare. That is the whole reason no-account access matters for briefing work: not elegance, but the number of people who will complete it without a phone call.

The exception is a client you work with continuously. If they are in your world every week for two years, a login is a one-time cost and the account gives you better boundaries. Friction only dominates when the relationship is short or the contact is junior.

Three things worth keeping apart

Conversation and approval. An approval living inside a conversation is an opinion with good timing. Where a project has a fixed scope and a payment tied to sign-off, move the approval to a surface that records what was approved and against which version.

Internal comms and client comms. The moment your team edits itself, you have lost the thing that made the internal channel useful. Separate surfaces cost you a little duplication and buy back honest disagreement.

Files and messages. Messages are ordered by time; files need to be ordered by purpose. A logo attached to a Tuesday message is findable on Tuesday and lost by the following month, unless something moved it into a structure on arrival.

A two-week trial that tells you something

Demos are designed to succeed. Run one real project instead, and build in five deliberate points of stress:

1. Send the portal or form link to an actual client, not a colleague. Watch whether they ask you what to do. That question is your usability score. 2. Submit deliberately incomplete input yourself. Does the tool flag the gap, or do you discover it three days later? 3. Upload a 40 MB PSD and a 12 MB video. Note the limit and, more importantly, read the error message a client would see. 4. Export everything on day ten. Open the export on a machine that is not logged in to anything. 5. Ask the client something you already asked on a call. Notice which record you instinctively reach for — that is your real system of record, whatever your process document says.

The full-length version of this protocol, staged across a project, is in our web design client portal free trial checklist.

Questions people ask

What is the difference between CCM and CRM? A CRM stores relationship and pipeline data: contacts, deals, activity history. Customer communications management (CCM) produces and delivers outbound documents — statements, notices, policy letters — across print, email and portals at volume. For a design studio, usually neither is the missing piece. What is missing sits between them: structured intake and a record of approvals.

What are the five communication tools? There is no canonical five, and any list that presents one is describing its own product mix. Categories are more useful than counts: email, real-time chat, voice and video, structured intake, and file exchange. Map your workflow onto those five functions and see which one has no owner.

What counts as client communication in a design project? Six artefacts, roughly: the initial enquiry and scoping conversation, the brief, asset and content delivery, feedback rounds, approvals, and the handoff package. Only three of those are conversations. The other three are records, and records are where tool choices actually matter.

Can a project management tool replace a client communication tool? Sometimes, and it depends almost entirely on criteria 1 and 7 of the score above. A PM tool that requires a client seat pushes work back onto you every time an infrequent contact needs to give you something. It also puts a client inside a workspace built for your team. Where the client is genuinely embedded and technical, it can work well.

When none of this is worth doing

One long-term retainer client. One responsive contact who answers within a day. A shared folder with a naming convention everyone actually follows. In that setup, adding a portal adds ceremony to a relationship that is already working, and the five-artefact test will pass anyway because there is only one project's worth of history to search.

The moment that changes is the second concurrent project with a second contact — because the thing that fails is never the messaging, it is the tracking of what has not arrived yet.