Getting a document reviewed by six people is a coordination problem disguised as a writing problem. The failure modes are consistent everywhere: comments arrive in five separate copies, two reviewers contradict each other and neither knows, someone rewrites the whole thing in track changes, and the author spends longer merging feedback than writing the draft. Almost all of it is preventable with decisions made before the document is sent.
Decide what kind of review you need
The most common mistake is asking for "feedback" without saying what kind, and receiving line edits on a draft whose structure is still moving.
Name the review type when you send it:
- Structural review — is the argument right, is anything missing, is the order sensible? Send an outline or an early draft. Do not accept or invite line edits; they are wasted work on text that may not survive.
- Content review — are the facts, numbers and claims correct? Send a complete draft to people who know the subject.
- Line edit — clarity, tone, concision. Late, and only once the content is settled.
- Approval — a specific person signing off on a specific version. Not feedback; a decision.
- FYI — no response needed. Say so, or people will feel obliged to comment.
Sending a near-final document and asking "any thoughts?" invites structural comments you cannot act on, which is how documents get rewritten three days before a deadline.
Say what you need, from whom, by when
Every review request should contain four things:
- What kind of review (above).
- What specifically to look at. "Please check section 4's figures against the model" gets a better answer than "please review". Reviewers give you what you ask for; if you ask for nothing specific, you get opinions.
- A deadline, with a real date and time.
- What happens if they do not respond. "If I have not heard by Thursday I will assume you are content" is enormously effective and entirely fair, provided you actually said it.
Also useful: say what is not up for review. "The structure is agreed with the steering group; I am looking for factual corrections in sections 3–5" saves everyone a round.
One document, one copy
The rule that solves most of the mechanical pain: all reviewers comment on the same copy.
Separate copies mean the author merges by hand, reviewers duplicate each other's comments, and contradictions surface only after the fact. A shared document — Google Docs, Word online, a wiki page, a pull request — lets reviewers see each other's comments, which prevents duplication and lets disagreements surface where they can be resolved.
Where a shared copy is impossible — external reviewers, security constraints, PDF deliverables — Acrobat can merge comments from multiple returned PDFs into one file, which is the next best thing. See how to add comments to a PDF and annotating a PDF guide.
What to avoid entirely: reviewers emailing edited copies back. That is not review, it is forking, and reconciling three forks is a worse job than writing the document.
Sequential or parallel
Parallel — everyone reviews at once. Faster, and the default for most documents. Risk: contradictory feedback with no resolution mechanism.
Sequential — reviewers in order, each seeing the previous round's changes. Slower, and correct when a later reviewer's input depends on an earlier one's, or when a senior reviewer's time should not be spent on things a first pass will catch.
A hybrid works well for anything substantial: parallel content review, then revision, then a single approval pass. The mistake is sending a first draft to the person whose approval you need — their time is spent on typos, and their attention is used up before the version that matters.
Handling the feedback
Read everything before changing anything. Acting on comment 4 and then discovering comment 27 contradicts it wastes a revision.
Group by theme rather than working top to bottom. Six comments about the same unclear section are one problem.
Decide, do not obey. A comment is information about how one reader responded, not an instruction. Where two reviewers disagree, the author decides and says why — that is the job. A document edited to satisfy every comment becomes incoherent, because it now serves six mental models.
Reply to comments you do not action. A short "not changing this because X" closes the loop. Silence reads as ignoring, and the same comment comes back next round.
Distinguish the disagreements that matter. A reviewer who dislikes a word is offering a preference. A reviewer who thinks the recommendation is wrong is raising a substantive issue and needs a conversation, not a comment reply.
The tone side of this is covered in writing constructive feedback at work — worth reading from the reviewer's side too.
Version control through the cycle
- One master copy, owned by one person. Everyone else comments; the owner edits.
- Version numbers that increment on each circulated draft, in the filename and in the document.
- A change note with each new round: "v4 — incorporates finance's figures, restructures section 3 following the steering group's comments". It tells returning reviewers what to look at and stops them re-reading the whole thing.
- Keep the version each reviewer commented on until their comments are resolved, so you can trace a comment back to its context.
- Archive the approved version distinctly from the working drafts.
Mechanics: naming and versioning shared files and document versioning best practices.
Approval
Approval is a different act from review and should look different:
- Name the approver explicitly — a person, not a group.
- Approve a specific version, identified by number and date. "Approved the report" is not a record; "approved v4.2, 6 August" is.
- Record the approval somewhere durable — a signature, a workflow system entry, or at minimum a dated email filed with the document. For anything with legal or regulatory weight, a digital signature binds the approval to the exact bytes approved: digital signatures vs electronic signatures.
- Re-approve after material change. An approved document edited afterwards is not an approved document, and this is exactly where governance failures happen.
Fuller treatment: document approval workflows and purchase orders and approval documents.
Before it goes out
Once approved, the release step has its own checklist, and it is where the embarrassing failures live:
- Flatten comments and accept tracked changes. Internal review comments reaching an external recipient is the classic incident: how to flatten a PDF.
- Strip metadata, which carries author names and the original filename: how to strip metadata from a PDF.
- Export to PDF so layout and fonts are fixed: embedded fonts in PDF explained.
- Check the exported file, not the source. Select all, copy, paste into a text editor — anything that appears there is in the document.
- File the sent version where you can produce it later.
Summary
Say what kind of review you want, what to look at, by when, and what happens if there is no reply. Keep everyone on one copy so reviewers see each other's comments and contradictions surface early. Read all feedback before acting, decide rather than comply, and reply to what you are not changing. Approve a numbered version explicitly, then flatten, strip metadata and check the exported file before it leaves — because the review process's most visible failure is a comment nobody meant to send.
