Short answer
The format is a twice-weekly written update, sent every Tuesday and Friday by the project lead, in a fixed four-part structure: done since last update, in progress, blocked or at risk, and what we need from you. The last section matters most, because async breaks down when one side is waiting on the other and neither knows it, so the ask is specific and dated rather than "let us know if you have questions." Synchronous calls stayed for two situations only, kickoffs and pivots. Async is for status; calls are for decisions with more moving parts than a text update can handle cleanly.
Eight months into full remote delivery and we had made one significant shift in how we run client communication. We replaced most synchronous check-ins with a structured async update format. Not because we wanted less contact with clients, but because the synchronous meetings we were having were not producing the outcomes that written updates could.
This is the format we landed on and why it works.
The Problem With the Weekly Status Call
The weekly status call is standard practice. We had one with every client. Thirty to sixty minutes, cover what happened, what is next, raise any blockers. Harmless enough.
In a co-located environment, it works reasonably well. In a fully remote environment running across different schedules and with clients managing their own businesses during a difficult year, it broke down in three ways.
First, it required coordination. Getting six people onto a call at the same time, across different time zones for international clients, was friction that ate real hours.
Second, the information was ephemeral. If a decision was made on the call, someone had to write it down afterward or it was gone. We had a client dispute a direction three weeks after a call because they had not remembered agreeing to it. We had not documented the call. That was our fault.
Third, it compressed communication into one window. If a client had a question on a Tuesday and the call was Thursday, they waited. Or they messaged us and we managed two channels. Neither was efficient.
What We Replaced It With
We moved to a twice-weekly written update. Every Tuesday and Friday, the project lead writes a short status note and sends it to the client. It follows a fixed structure.
The update has four parts.
Done since last update. A bulleted list of what was completed. Written in plain language, not engineering jargon. "The order export function is complete and tested" rather than "refactored the export service and added unit test coverage."
In progress. What is actively being worked on right now and who owns it.
Blocked or at risk. If anything is stuck or behind, it goes here with context on why and what we are doing about it. This section is never empty just to look clean. If there is a blocker, it is named.
What we need from you. A specific, actionable ask if there is one. Not "let us know if you have questions" - something like "please review the attached workflow and confirm the order statuses match your process by Thursday."
The last section is the most important. Async communication breaks down when one side is waiting on the other and neither knows it. Making the ask explicit keeps things moving.
The Rules We Added Around the Format
A few operating rules that made the format work.
We do not send updates that contain no new information. If nothing material happened since the last update - which is rare but happens - we say that explicitly: "Light week due to dependency on the third-party integration, back to full pace next week."
We respond to client questions within twenty-four hours on business days. The async format only works if clients trust that messages will not disappear. Fast response to questions is the trust signal that makes async viable.
We document decisions in the update. If a client approves something or makes a direction call in response to an update, we reference it explicitly in the next update: "Following your confirmation on Tuesday, we are proceeding with approach B."
When We Still Use Synchronous Calls
We kept synchronous calls for two situations: kickoffs and pivots.
Kickoff calls are in person or video. The beginning of an engagement needs the energy of a synchronous conversation.
Pivots - when something significant needs to change in direction, scope, or approach - also get a call. Nuanced decisions need real-time back-and-forth. Async is for status. Calls are for decisions that have more moving parts than a text update can handle cleanly.
Everything else is async. Our clients adapted quickly. Most have said they prefer it.
If your project communication feels like it is running on too many channels with too much noise, simplifying the format usually helps more than adding tools.
Questions · 04
Frequently asked questions
What was actually wrong with the weekly status call?
In a fully remote setup it broke down three ways. Getting six people onto a call at the same time, across time zones for international clients, was friction that ate real hours. The information was ephemeral, and we had a client dispute a direction three weeks later because nobody had documented the call, which was our fault. And it compressed communication into one window, so a Tuesday question either waited until Thursday or spilled into a second channel.
What goes in the update when nothing much happened?
We do not send updates that contain no new information. When a stretch is genuinely light, which is rare but happens, we say so explicitly: "Light week due to dependency on the third-party integration, back to full pace next week." Naming it is better than padding the update to look busy.
How do decisions get recorded without a call?
In the update itself. When a client approves something or makes a direction call in response to an update, the next update references it explicitly, for example "Following your confirmation on Tuesday, we are proceeding with approach B." That written trail is what the status call never produced unless someone remembered to write it down afterward.
Do clients actually prefer fewer calls?
Ours adapted quickly, and most have said they prefer it. The rule that makes it work is responding to client questions within twenty-four hours on business days. Async is only viable if clients trust that their messages will not disappear.
