You finish the build at 6pm in Berlin and the client opens their laptop at 9am in Los Angeles, by which point you have been asleep for two hours. The review call you booked for Thursday gets pushed because their CMO needs them, and now the whole sprint waits a week for a 30 minute meeting that could have been a five minute message. This is the actual cost of timezones in client work: not the hours of overlap you lose, but the decisions that stall waiting for them.
Why the scheduled review call keeps failing
Synchronous review meetings carry assumptions that fall apart across timezones. They assume both sides can hold a 30 to 60 minute block on the same day. They assume the client will have looked at the work beforehand (they almost never have). They assume someone is taking notes that survive the call. And they assume the feedback that comes out is specific enough to act on, when in practice it is usually phrases like "the hero feels off" said while a cursor wiggles vaguely on a shared screen.
Add a six to nine hour gap and the math gets worse. Your only overlap is the client's early morning or your late evening, which is exactly when nobody is sharp. A rescheduled call costs you two days, not one, because the next available slot is always 48 hours out. Meanwhile the build is paused on a question that could be answered in two sentences if anyone could just look at the screen and respond.
What a recorded review actually has to do
The fix is to record the review once and let the client respond on their own time. But "record a Loom" is not the answer most teams think it is. A 14 minute video that the client has to scrub through to find the part about the pricing table is worse than no review at all, because now they feel guilty for not watching it and they avoid replying. A useful async review has to do four things:
- Show the exact thing being discussed, not the whole screen for two minutes before getting to it.
- Let the client reply per item, not at the end as a wall of text.
- Open in a browser tab with no login, because the client will not install anything.
- Produce something the receiver can actually act on later, whether that is your developer, a contractor, or a coding agent.
That last point matters more than it looks. If your async review only lives as a video, the developer who picks it up on Monday has to watch it too. Every link in the chain pays the time cost again.
The flow that works across a nine hour gap
Here is the shape of an asynchronous client feedback workflow that survives timezones. You walk the build screen by screen, capturing a still of each thing you want to discuss. On each capture you add a pin to the specific element and dictate or type a short comment: "Pricing table, middle tier. The Pro plan badge is sitting on top of the price. Want me to push the badge above the heading or shrink it?" One screen, one item, one question.
You publish. The client gets a link like /r/your-slug. They open it in their browser at 9am their time, scroll through 12 items in maybe six minutes, and reply on the ones that need a decision: "Push it above" on item 4, "Looks fine" on item 7, a longer note on item 9. You wake up to 12 resolved threads instead of a 45 minute call you have to schedule.
The client never installed anything. They never made an account. They never learned a tool. That last point is the one that determines whether this actually works in practice, which is why we wrote about client feedback without making the client learn a tool separately.
Why stills beat video for this
A captured frame with a pin and a typed comment is faster to produce than a video and dramatically faster to consume. The client can jump straight to item 9 instead of scrubbing. Each item is independently resolvable, so progress is visible. And the output is text, which means it can become a PDF for the client's records, a Word doc for their internal handoff, or clean markdown that a developer or coding agent can read straight into the codebase. We wrote about the tradeoffs in more depth in screen capture vs screen recording; for client work specifically, stills almost always win.
There is a narrow case where a short recording helps: showing an interaction that does not make sense as a still, like a hover state breaking. Even then, capture the broken state as an image and describe the interaction in text. The client will read it in 10 seconds.
What to do tonight before you log off
If you have a build sitting in staging waiting on client decisions, do not book another call. Open a new review, walk the screens, pin and comment on every open question, and publish. Send the link in one short email: "12 questions, mostly small, reply on whichever ones you have an opinion about, no login needed." By the time you wake up, most of them will be answered.
For teams running this every week, the same pattern covers staging site reviews and design reviews on the built product. The shared idea is that the review exists as a durable artifact at a URL, not as an event on a calendar. Once it is at a URL, the timezone gap stops mattering.