The problem
Editorial workflow is fragmented across documents, email and a CMS, causing missed reviews and inconsistent quality checks. There is no single source of truth for brief status, reviewer assignment or source verification.
Assumptions
A small team publishes 4–8 pieces per month; briefs exist but are not standardised; reviewers are available but scheduling is manual; the CMS supports custom fields but they are not used for workflow status.
Guardrails
No auto-publishing; every piece requires a human quality check; source links must be preserved in the CMS; personal data in drafts is never exposed to third-party tools.
Evaluation criteria
Reduction in missed review steps; time from draft to publish; percentage of pieces with a completed brief; number of pieces with verified sources.
What would change in production
Integration with the actual CMS; role-based permissions for reviewers; notification preferences for editors; retention policy for drafts and source notes.
How the workflow would operate
Input: an editor submits a brief with the audience, purpose, target query or question, required sources, format, owner and due date. The brief is stored against the article record rather than being left only in email. A missing required field sends the item back for clarification instead of allowing it to move forward unnoticed.
Logic: the system checks whether the brief is complete, identifies the required reviewer and applies the editorial checklist for that content type. The rules should remain visible and editable. Any AI-generated outline or classification is a suggestion; it does not replace an editor’s decision about intent, evidence or suitability.
Action: the record moves to the named writer or reviewer and sends a restrained notification. The CMS remains the source of truth for status, draft, comments and source links. A reminder can be sent after an agreed interval, but reminders should not auto-approve overdue work or publish a draft.
Control: each transition records who made the change and when. A quality gate confirms that source links, required sections, accessibility checks and human approval are complete before publishing is allowed. An owner can pause the workflow if the CMS integration or notification channel is unreliable.
Failure handling and ownership
A robust version accounts for unavailable reviewers, incomplete briefs, broken source links, duplicate notifications and failed CMS updates. Notifications should identify the affected record and the action needed without exposing confidential draft content. If an integration fails after a status update but before a notification is sent, the record remains inspectable and a retry must not create a second article or erase the history.
The editorial lead owns the checklist and approval policy; the workflow owner maintains field definitions and notification rules; writers and reviewers are responsible for the quality of their assigned work. A short runbook should explain how to pause the automation, locate failed items, retry a safe step and manually complete a task when the automation is unavailable.
Rollout and review
Start with a small set of representative articles and compare the workflow against the current process. Test incomplete briefs, urgent edits, unavailable reviewers and a simulated integration failure before involving the entire team. Review missed steps and the time spent waiting, but interpret these indicators with context: faster publication is not useful if source verification or editorial judgment declines. Expand only after the team can explain the workflow and recover from expected failures.