A document sent to five people for review comes back with five sets of contradictory notes and no decision. The fix is not better reviewers — it is saying what kind of review you want before sending.
Document review is the step between a document being written and being used: somebody other than the author reads it, comments, and it is either changed or approved. It is where a great deal of time disappears in small organisations, usually because the request was please review, which invites everything and decides nothing.
The single most useful change is to say what you are asking for. Is this factually correct, is the approach right, is this ready to send, or do I need a legal opinion — four different questions, four different reviewers, four different amounts of time. Sent without that framing, a document collects wording preferences from people who were meant to check the numbers.
The author decides, not the reviewers. A review gathers information; it does not create a committee. When every comment must be satisfied, documents converge on the least objectionable version, which is reliably the least useful one. Say plainly, at the start, that the author holds the pen and will explain what was not taken.
Reviews stall for one of two reasons: nobody knows when it is due, or the reviewer is not sure what to do. Both are fixed at the point of sending. A specific date, a stated consequence for silence, and a one-line ask remove most of the chasing. The remaining case — a genuinely busy reviewer whose input you actually need — is a conversation rather than a reminder, and usually resolves faster than three follow-up messages.
Ettex Docs carries the comments against the document with a resolution state per comment, so the round is visible rather than scattered across replies; the versions that come out of it are covered in document version control, and formal sign-off in approval workflow.
What we do not do: no routing engine that sends a document to reviewers in sequence automatically, no deadline enforcement, no reminders. The rules above are conventions your team agrees, and honestly, at small scale conventions outperform workflow software — the constraint is attention, not routing.
Say which kind: factual check, substantive review, approval, or copy edit. Add a deadline and state what happens if somebody does not reply.
Two who will actually read it. More reviewers produce contradictory comments that somebody then has to reconcile, which costs more than it adds.
The author decides and explains what was not taken. A review gathers information; it is not a committee that must be satisfied.
Last, after substance is settled. Editing sentences that later get deleted is the most common waste in a review round.
Version control is not about keeping every draft. It is about there being exactly one current document, and everyone knowing which it is — which is why final_v3_REVISED is a symptom rather than a naming problem.
Everyone agrees backups matter and almost nobody checks that theirs work. The gap between having a backup and being able to restore is where most data loss actually happens.
Root cause analysis works out why something went wrong deeply enough that fixing it prevents a recurrence. Its main difficulty is stopping too early, at an answer that sounds satisfying.