A writer sends a draft as an attachment, the editor replies with tracked changes, a manager comments on an older version, and whoever has the login pastes the final text into the website. Somewhere along the way, a correction disappears.
Content teams often work like this until a mistake reaches a live page. Moving the review into the CMS fixes the version problem and gives every published page a clear record of who wrote, checked and approved it.
Why email reviews break down as a team grows
Email review works for two people and one document. Add a second editor, a legal check or a busy week, and nobody knows which attachment is current, whether the approver saw the final wording, or who pasted the text into the site. The workflow lives in private inboxes, where nobody else can follow it.
The cost shows up as rework and as risk. A fixed typo that returns in the next version is annoying; a price, date or legal line that returns after correction can turn into a complaint.
Map the roles before you touch any software
Write down who does what before configuring anything. Most teams need four roles: authors who write, editors who check language and structure, approvers who confirm facts or legal wording, and publishers who decide when a piece goes live. One person can hold several roles, but each step needs a named owner.
- Author: creates and edits drafts, cannot publish
- Editor: edits any draft, checks grammar, structure and style
- Approver: signs off facts, figures and legal wording
- Publisher: sets the release time and publishes
Keep the list short. Every extra step slows publishing, so add an approver only where an error would cost more than the delay.
What the CMS should enforce for you
A good CMS turns the role list into permissions. In Sanity, edits live in a draft that stays separate from the published version until someone publishes it, and the Contributor role (on Growth plans and above) can edit drafts but cannot publish. Validation rules in the content schema then block incomplete or malformed entries.
Teams that need finer control, such as an approver limited to certain document types, can use custom roles on some Enterprise plans. The software then blocks an unreviewed page from going live, something a reminder email cannot do.
Taking developers out of routine publishing is the other half of the gain. Pagepro, a Next.js and Sanity migration specialist (https://pagepro.co/services/sanity-development), moved GP Notebook to a setup where the editorial team publishes independently of developers, which dramatically reduced time-to-market and lowered content-management costs.
Turn your style guide into rules
Many style guide rules can be checked automatically. A title field can enforce a maximum length, an image field can require alt text, a summary can be mandatory, and a custom rule can flag double spaces or a phrase your guide bans. Editors then spend their time on meaning and tone instead of catching the same slips.
Rules that need judgment, such as voice or argument, stay with people. A live preview helps there, because editors judge a piece better when they see it the way a reader will. For Darktools, Pagepro set up Sanity with self-serve editing, a page builder and live preview, so no developer is needed to publish.
A starting checklist for your first week
Start small and run one content type through the new workflow before moving everything. A blog post or a news item works well, because it is frequent enough to test the process within days and simple enough that any problem points at the workflow itself.
- Name the owner of each role for that content type
- Set permissions so authors cannot publish directly
- Add validation for the style rules broken most often
- Agree a turnaround time for each review step
- Review the first ten published pieces and adjust
After two weeks, compare how long a piece took from first draft to publication with the old email process, and use that number to decide which content type moves next.
