Most of the people in the workflow are not writing
A content program is designed around the people who create the content and decided by the people who sign it off. The second group is the larger one: managers, safety officers, legal counsel, engineering peers. They touch the system a few times a month, and they set the pace for everything else.
Training twenty authors is a plan. Training a hundred reviewers is not
A core team of authors can be taught a specialist tool. It is a budget line and a week of somebody's time, and it works. The same approach applied to everyone who has to read, comment on and sign off that content does not work, and it does not fail gradually. It fails at the first person who has other priorities that week.
That is the group most content programs count last and depend on most. A manager approving a procedure, a safety officer reading one warning, a legal reviewer checking one clause: each of them touches the system a few times a month. None of them will learn an XML editor to do it.
So the question is not whether the review tooling is powerful. It is whether taking part requires anything new at all.
Review and approval are different jobs with different evidence
A comment and a sign-off are not the same act. One is an opinion attached to a component, the other is a decision recorded against a version of it. Treating them as one step is what turns an audit response into archaeology.
Reviewers
Comment on the component rather than on one rendering of a finished document. The tool is Microsoft Word or the SharePoint library, signed in with the account they already have.
Approvers
Sign off once, against a component and a version, with the record captured as it happens rather than reconstructed from an email thread when somebody asks.
Where the tasks arrive
Teams notifications and Outlook tasks in the tenant the organization already runs. No separate workflow inbox, because a second inbox is a second thing to forget.
Frequently asked questions
Where does the twenty-to-a-hundred ratio come from?
From us, not from a published study. It is the shape we see in the programs we work on, and our founder is the source. Treat it as an order of magnitude rather than a benchmark: the point is that the group nobody counts is the larger one. The number that decides your evaluation is the one you get from counting your own list.
Can review and approval run on one document set while the rest stays as it is?
That is the usual shape. From the day the repository exists, newly written content goes in as components, and one existing document set goes first, normally the one reviewed most often or the one that costs most to translate. Legacy content follows as it is touched, because a document scheduled for revision is a document worth converting once rather than twice.
How do we see where a cycle is stuck?
Two places. The job history and monitoring dashboard logs every background operation the platform runs, and Power BI reports on the SharePoint records themselves, so approval throughput and review backlog read from the same items an auditor would look at. What none of that tells you is why a particular person has not responded. That part is still a conversation.
Is there content where component-level review is not worth the effort?
Yes. Content that is retained but not maintained does not have to become components to stay compliant, and converting a cold archive spends effort on documents nobody will edit again. The test is whether the content will be revised, reused, or asked about by somebody outside. If none of the three applies, leave it where it is.
What happens to the record when a reviewer or approver leaves?
The record does not depend on them staying. Approvals and comments are held against components and versions in your own SharePoint, so the history survives the account. Deprovisioning happens once, in Microsoft Entra ID, and there is no second user list to remember to clean up. What leaves with the person is their judgment on the next cycle, not the evidence for the last one.
Count the reviewers before choosing the tool
List everyone who has to comment on or approve a document set, not just the people who write it. If the tool you are evaluating needs any of them to learn something new, that is the number that decides the timeline.
