On this page
Async feedback has a reputation problem. Clients worry it'll feel cold – a list of comments instead of a conversation. Agencies worry they'll lose the nuance they get on a call.
Both worries are fair. But most of the coldness comes from how async feedback is set up, not from being async. Done well, it's warmer than a rushed call, because everyone has time to think.
When a call really is faster#
Let's start with the honest part: some conversations shouldn't be async.
A call is better when the direction is unclear – the first concept presentation, a pivot after research, a disagreement between stakeholders on the client side. In those moments, the back-and-forth matters more than the record, and a 30-minute call saves a week of comments.
A call is also better when someone is upset. Written feedback on a sensitive topic is easy to misread, and a short conversation can clear up in five minutes what a thread would make worse.
Everything else – reviewing a version, approving a deliverable, answering a question – works better async. It's the bulk of the work, and it's where calls waste the most time.
The rule we use: talk about direction, write about details.
It helps to say this rule out loud to the client at the start of the project. When they know a call is always available for the big questions, they're much more comfortable answering the small ones in writing. Async stops feeling like a way to avoid them and starts feeling like a way to respect their time.
Writing feedback requests clients can answer#
Most cold async feedback starts with a cold request: a file attached to an email that says "please review". The client doesn't know what you need, so they reply with whatever comes to mind.
A good feedback request does three things:
- It explains what changed since the last version, in one or two sentences
- It asks a specific question – "does the new navigation work for your sales team?" rather than "thoughts?"
- It says what happens next – "once you've approved this, we'll start building the inner pages"
That's it. Three short paragraphs. It takes five minutes to write, and it turns a vague review into a focused one.
It also makes the exchange feel personal. A request written for this client, about this decision, reads like a conversation – even though nobody is talking.
Video walkthroughs (under 3 minutes)#
When something needs explaining, record a short video instead of booking a call. Walk through the design, point at the parts you want feedback on, and explain the thinking behind them.
Keep it under three minutes. Longer videos don't get watched to the end, and the important part is usually at the end.
Video brings back much of what clients miss about calls: your voice, your enthusiasm, the reasons behind decisions. And unlike a call, the client can watch it when they're ready, pause it and watch it again before replying.
Closing the loop visibly#
The coldest part of async feedback is silence after it's sent. The client writes careful comments and then hears nothing until the next version appears, a week later, with no indication of what happened to their notes.
Close the loop. When you act on a comment, reply to it: "Done in v3" or "We tried this – here's why we went another way." When you can't do something, say so and explain why.
This is the single biggest difference between async feedback that feels cold and async feedback that feels collaborative. Clients don't need every comment accepted. They need to know every comment was read.
It also saves time in the next round, because the client can see at a glance which of their notes were addressed, instead of comparing versions to find out.
Set expectations for reply times#
Async doesn't mean "whenever". Agree reply times with the client at the start: how long they have to review a version, and how quickly you'll respond to their comments. Two working days each way is a common, comfortable rhythm.
Without an agreement, both sides fill the silence with worry. The client wonders whether you've seen their notes; you wonder whether they've seen the version. A shared expectation removes most of that, and it makes the occasional reminder feel like part of the process rather than a complaint.
What we changed in Ferrybox because of this#
We built Ferrybox on the idea that most review should be async. Watching agencies use it taught us where async needed help.
We added replies on resolved comments, so marking something as done can include a note about what changed. Clients see "Resolved – shortened the headline in v3" instead of a comment that quietly disappears.
We added video comments, so agencies can attach a short walkthrough to a version without leaving the portal.
And we added a "what changed" note to every new version. It's optional, but agencies that use it get approvals faster, because clients know exactly what to look at.
We also changed the defaults for notifications. Clients now get one daily digest instead of an email per comment, because a dozen emails in an afternoon feels like being shouted at, even when every message is friendly.
None of these features is complicated. They all do the same thing: they put a little of the warmth of a conversation back into the written record. That turned out to be most of what async feedback was missing.
