Async consulting: how most of the work happens between calls

Most consulting relationships are measured in call hours, but the real work happens in the silences between them. At MindVault Lab Flow, we have spent years refining how we use asynchronous formats — shared documents, structured updates, timed feedback windows — to make the time our clients spend with us count far more than any video call alone could. This is not a philosophy of avoidance; it is a structural argument about where thinking actually occurs, and how to design around that honestly. If you have ever finished a call feeling energised and then watched that energy quietly dissolve before the next session, the approach described here is built for that exact problem.

Why the call is rarely where decisions are made ¶

Calls are useful for alignment and for re-establishing trust after a period of independent work. They are less useful — often actively counterproductive — for the kind of sustained, uninterrupted reasoning that a complex problem requires. When two or three people are on a video call together, each one is managing the social layer of the conversation at the same time as trying to think: tracking expressions, waiting for gaps, moderating tone. That is a meaningful cognitive cost. The decision that feels reached on a call is frequently a social consensus rather than a considered one, and the best consultants learn to distinguish between the two.

At MindVault Lab Flow, our engagements are structured so that calls function as transition points rather than workplaces. We enter each one having already deposited our thinking in writing, having already read the client's written response, and having already identified the one or two questions that genuinely require a live exchange to resolve. The call becomes short, specific, and almost relief-like in its clarity — because most of the ambiguity was dissolved in the days before it.

The shared document as a working environment ¶

Every active engagement at MindVault Lab Flow lives inside a single master document. We call it the Engagement Ledger: a long-form, continuously updated file that contains the project brief, a running log of decisions and their rationale, open questions sorted by owner, and a section we call the Scratch Layer — an informal space where half-formed thoughts can be deposited without the pressure of presentation. Clients often tell us that reading back through the Scratch Layer at the end of an engagement is the closest thing to watching a project think out loud.

The formatting discipline matters enormously here. We use plain prose rather than nested bullet hierarchies, because bullets encourage compression and compression encourages ambiguity. A sentence has to commit to a meaning in a way that a fragment does not. When a client writes, in the Open Questions section, 'Concerned about the rollout timeline,' that note creates more work, not less — someone has to interpret what specifically concerns them, which timeline, and what their threshold for concern is. When they write a full paragraph explaining the concern, the path to a resolution becomes visible immediately. We prompt for that level of specificity through the document's own structure.

The Engagement Ledger is not a project management tool in the conventional sense. It does not track tasks or assign deadlines in a dashboard format. It is closer to a correspondence archive — the kind of file a good solicitor or architect maintains, where the full reasoning behind every significant choice can be reconstructed by anyone who picks it up later. That quality of legibility is what allows our engagements to survive team changes, interruptions, and the long gaps that sometimes appear in a project's calendar.

The document is not a record of the project — it is the place where the project actually lives.

Check-in rhythms and the logic behind them ¶

We operate on a rhythm of structured written check-ins rather than standing weekly calls. Every five to seven working days, each side of the engagement submits a short written update to the Ledger following a fixed format: what moved forward, what is currently blocked and why, and what one thing the other party needs to read or decide before the next update. This format is deliberately asymmetric — it asks for fewer than two hundred words, because brevity at that frequency is more valuable than comprehensiveness at a lower one.

The check-in rhythm serves a function beyond information transfer. It creates a gentle accountability structure that does not require anyone to schedule a conversation in order to feel that the project is alive. For clients who are running a business alongside the engagement — which is almost all of them — the knowledge that a written update is due on Thursday morning changes how Tuesday and Wednesday feel. Work gets done. Observations get captured. The engagement stays warm without demanding calendar space.

What good async habits look like in practice ¶

The structural elements above only function if both sides have developed the underlying habits that make asynchronous communication legible and trustworthy. These are learnable, and we introduce them explicitly at the start of every engagement through what we call the Working Agreement — a brief document that establishes the norms before the work begins.

• Response windows: we commit to reading and acknowledging any substantive update within one working day, and to full responses within two.
• Ownership markers: every open question in the Ledger carries an explicit owner and a nominated date by which a response is expected — no item floats without an owner.
• Assumption logging: when either party makes a decision in the absence of full information, they record the assumption made and flag it for review at the next check-in.
• Version discipline: the Ledger uses dated section headers rather than tracked changes, so the history of a decision is readable in plain prose, not a sea of red strikethrough.
• Escalation signals: if a written exchange is beginning to generate more heat than light, either party can call a short live conversation without it being treated as a failure of the async system.
• End-of-phase summaries: at the close of each project phase, we write a one-page synthesis of what was decided and why, which is appended to the Ledger and shared with any stakeholders who were not part of the daily exchange.

The honest limits, and what we do about them ¶

Asynchronous consulting does not suit every temperament or every kind of problem. Some clients arrive with a genuine need for the relational warmth of frequent live contact, particularly early in an engagement when trust has not yet been established through the work itself. We account for this by front-loading calls: the first two weeks of any engagement typically involve more live conversation than any subsequent period, specifically to build the shared vocabulary and interpersonal context that make the written exchange meaningful later.

There are also problem types that resist the written format — live negotiations, sessions involving multiple stakeholders with conflicting interests, workshops that depend on real-time divergence and synthesis. We do not force these into an async mould. The aim of the structure described here is to protect the conditions under which the best thinking happens, not to minimise human contact for its own sake. Where live interaction is genuinely the right tool, we use it without apology.

What the async framework ultimately provides is not a replacement for good consulting judgment — it is a container that keeps judgment from degrading under the ordinary pressures of calendar overload, communication lag, and the slow drift that affects any project that lives primarily inside people's heads rather than on a shared page.

If any part of this describes a pattern you recognise in your own remote engagements, we would be glad to talk through how a differently structured approach might work for your context.