Asynchronous revision works when a document carries enough context for the next person to act without asking a question first. Dropping a link into a channel does not carry context. The writer knows what the round is for and nobody else does, and the delay before they find out is the cost of working apart.

THE SHORT VERSION
  • Answer the reviewer's obvious questions inside the document before sending it.
  • State what is out of scope for the round, not only what is in it.
  • Scope each round to one editorial question and give it a closing time.
  • Keep replies and revision plans on the comment threads rather than in chat.
  • Move to a call once a thread reaches its third exchange.

Async review has a fixed cost per question

When collaborators overlap for six hours a day, an unclear request costs a few minutes. When they never overlap, the same request costs a day in each direction. That arithmetic should change how much you are willing to write before sending a draft out.

Everything a reviewer might otherwise ask should already be in the document: which stage this is, what changed, what you want judged, what you do not want judged yet, and when you need it. Write it once and you buy back the round trips.

Write the handoff note

Put a short block at the top of the draft. Purpose of the piece, current stage, what changed since the previous round, the questions you want answered, the kind of response you want, who decides, and the deadline. Seven lines usually covers all of it.

The most valuable line is the one saying what is out of scope. Telling reviewers that sentences are not settled and should not be line edited saves each of them an hour, and saves you a round of comments you would have had to decline one at a time.

Every question a reviewer has to ask costs a day, so answer it before they open the document.

Scope each round to one editorial question

A round that asks for any thoughts returns thoughts at every level at once and leaves you to sort them. A round that asks whether Section 4 still earns its place returns an answer you can act on the day it arrives, because the reviewer knew what they were judging.

Long drafts usually need three or four scoped rounds rather than two open ones. Does the argument hold. Does the order work. Is it accurate. Does it read well. Each round runs faster, and the comments inside a round barely conflict with each other.

Set a window and then close it

Give the round a start and an end. One to three business days suits most routine work, while a full manuscript pass needs considerably longer. Perpetual open review produces the comment that lands two days after you finished rewriting the section it refers to.

When the window closes, close it properly. Publish what you accepted, what you declined, and what has moved to the next round. Comments arriving late go into the queue for that next round rather than into the draft you are actively rewriting.

Agree comment conventions in advance

Async comments are read hours later by somebody who cannot ask what you meant. Adopt three or four conventions and use them every time: a severity label, a question mark for genuine questions, and a marker for notes the writer can resolve without replying.

Anchor every comment to the smallest span it applies to. A note attached to a whole section is ambiguous about which sentence provoked it, and ambiguity in a comment turns into a message, and a message turns into another day of waiting.

Reply in the draft, not in chat

When the writer answers a comment, the answer belongs on the thread that raised it. Replies posted in chat leave the reasoning somewhere the next reader will never look, and the same objection comes back from somebody else two rounds later, word for word.

Post the revision plan into the document as well, before the rewriting begins. Reviewers in another time zone can confirm you understood them while you sleep, which is as close as asynchronous work gets to a conversation about the draft.

Log the decisions, and know when to stop typing

Record settled questions on the project home: what was decided, why, and when. Six entries is plenty for most pieces. The log exists so a reviewer joining at round three can see which arguments have finished, rather than reopening one in good faith.

Async has a clear failure mode. Once a thread reaches its third exchange, the disagreement is almost always about the goal rather than the wording, and no amount of careful writing will resolve it. Schedule the call, keep it short, and write the outcome down.

Worked example

Handing off a draft across time zones

Before

Message posted in the project channel at 18:40: "Hey both, draft of the strategy piece is in the folder, would love your thoughts whenever you get a chance. Still rough in places. Let me know!" The next morning a reviewer eight hours away opens the folder, finds two files with similar names, cannot tell which sections are new, and leaves eleven comments. Nine of them sit on sentences inside a section the writer had already decided to cut. The writer reads them ten hours later.

After

Block at the top of the draft: Round 2, structure only. Please do not line edit; the sentences are not settled. Changed since round 1: sections 3 and 4 are now merged. New section 6 on cost. The old section 2 has moved to the cut file. Questions: (1) Does the argument still hold without the old section 2? (2) Is section 6 in the right place, or should it come before the objections? Decides: Priya on structure, Tom on the cost figures. Window: closes Thursday 17:00 CET. Anything later goes to round 3.

The first version is friendly and costs the reviewer a full day. Nothing in it says which file, which pass, what changed, or when it is needed. The second is not more formal, only finished. A reviewer told not to line edit will not spend an evening on sentences that are about to disappear.

What goes wrong

Common mistakes

Put it into practice

Your checklist

  1. Write a handoff block at the top of the draft before sharing it.
  2. List what changed since the previous round.
  3. State the one or two questions this round has to answer.
  4. Declare what reviewers should not comment on yet.
  5. Set a closing time and publish a summary once it passes.
  6. Copy every settled decision into the project decision log.
Vocabulary

Key terms

Handoff note
A short block at the top of a shared draft stating the round's purpose, what changed, the feedback wanted, who decides, and when the review window closes.
Review window
A defined period during which a round's comments are accepted. Once it closes, the writer publishes a summary and later comments move into the following round.
Scoped round
A review round limited to one editorial question, such as whether the order works, rather than an open request for whatever reactions a reader happens to have.
Put it to work

Getting a draft read by someone else?

Questions, answered

Frequently asked questions

How long should a review window be?

+

One to three business days for a routine section, and a week or more for a full manuscript pass. Size it as reading time plus one working day in each reviewer's time zone, then state the closing time in a named zone.

What if a reviewer never responds?

+

Close the round anyway and note that they did not comment. Chasing quietly for another week teaches everyone that your deadlines are soft. If their sign-off is genuinely required, escalate once, in writing, before the window closes rather than after it.

Who resolves the comment threads?

+

The writer resolves threads they acted on and replies to the ones they declined. Reviewers resolve their own questions once those have been answered. Agree this at the start, because unresolved threads are the main reason a round drags past its window.

How do we handle urgent changes mid-round?

+

Make them, then post a note in the draft saying what changed and when, so reviewers reading later know the ground moved beneath them. Silent edits during an open window are the fastest way to waste somebody's careful afternoon and lose their goodwill.

Can an AI assistant summarise a review round?

+

Strut AI can group comments by section and by theme, which shortens the triage considerably. Read the originals before acting on the grouping, because a comment's real severity often lives in a phrase that a summary will drop as incidental.

Does async work for developmental editing?

+

Yes, provided the rounds are scoped. Structural questions suit writing well, because they reward a considered answer rather than a quick one. What asynchronous work handles badly is open-ended exploration, which stays cheaper in a short scheduled call with everyone present.