Build it with AI
Create a content workflow around the way your team plans, approves, and publishes.
Build a focused CMS for briefs, drafts, approvals, owners, publishing status, and performance context.
Introduction
What a content management system has to hold.
Most teams end up with a content management system the same way: briefs in one place, drafts in another, approvals in email, and a publishing calendar in a spreadsheet. One writer and one approver need no system at all. The break comes at three or four contributors with an external reviewer, when the true state of a piece is distributed across a document’s comment thread, a chat message, and somebody’s memory of a meeting.
The calendar says what should have published; nothing says why the piece that missed it is stuck or with whom. There is no state on the piece itself that everyone reads the same way, no record of who is currently blocking it, and no link between a published piece and how it performed.
What follows covers building a content management system: the records it holds (briefs, drafts, owners, approval state, publish date, and performance after publication), the systems it reads (Google Drive and Slack), and what it does not fix.
The problem
The calendar, the drafts, and the approvals are three separate lies.
Document tools model the draft and have no opinion about workflow, so status lives in a filename. Project tools model the workflow and have no relationship to the draft, so the two drift apart within a fortnight of anyone using both.
The records are briefs, drafts, owners, approval state, publish date, and performance after publication, and the authoritative copy of most of them already lives in Google Drive or Slack. The calendar says published, the CMS says draft, and the piece went live two weeks ago under a different title.
The cost is not the inconvenience: a campaign launches without the asset it was built around.
You're likely here because
- The weekly status meeting exists mainly to find out what state things are in
- The calendar says what should have published; nothing says why the piece that missed it is stuck or with whom.
- When it is wrong, a campaign launches without the asset it was built around
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Editorial calendar
- • Approval workflow
- • Content records
Operated through Grow
- • Distribution workflows
- • Lead linkage
- • Campaign context
Systems it reads
- • Google Drive
- • Slack
- • GA4
The record model
What a content record has to carry.
- Brief and its commissioner
- Why this exists and who asked. Pieces without a traceable commissioner are the ones that stall in review because nobody can say what good looks like.
- State with an exit condition
- In review is not a state unless it names who reviews and against what. This is where editorial workflows fail, and the failure looks like a tooling problem.
- Current blocker and its owner
- The single most valuable field in the system. It replaces most of what the weekly status meeting exists to establish.
- Named reviewers with a window
- Because the recurring failure is a review nobody owns rather than one that is refused, and an unowned review has no natural end.
- Target date and its history
- Every previous target, so slippage is visible as a pattern rather than as a series of individually reasonable adjustments.
- Published URL and canonical
- Attached at publication, so the archive migration later has the redirect map it needs rather than reconstructing it from a crawl.
- Performance
- Joined back to the record. A CMS that cannot tell you how the last twenty pieces did will commission the next twenty on instinct.
How it runs
From a status spreadsheet to a workflow with states.
Step 01
Describe what a content management system has to do
Define the states a piece moves through and the exit condition of each. Editorial workflows fail because in review means four different things to four people.
Step 02
Connect the systems of record
The document store holds the drafts, chat is where the reviews happen, and analytics holds what happened after publication. Reading them attaches the workflow to the work rather than describing it.
Step 03
Build the operating surface
A content record carrying brief, owner, state, reviewers, target date, published URL, and performance — with the calendar as a view over that record rather than a separate artefact.
Step 04
Start narrow
State and current blocker on every in-flight piece, in one view. That alone replaces most of the weekly status meeting.
Step 05
Route the exceptions
A piece sitting in review past its window surfaces to the reviewer and then to the editor, because the default failure in editorial workflow is a review that nobody is chasing.
Step 06
Measure share of planned content that publishes on the planned date
Measure cycle time from brief to published and the share of pieces hitting their target date. Volume without cycle time tells you nothing about whether the process improved.
Implementation path
Building editorial operations a team will actually use.
- 01
Write the exit condition for each state. Approved by whom, against what, is the question that resolves most editorial workflow disputes before they recur.
- 02
Baseline cycle time from brief to publication and the share of pieces that slip. Both are easy to reconstruct from the last quarter and both will be worse than the team’s impression.
- 03
Attach performance to the content record from the start. A CMS that cannot tell you how the last twenty pieces did will produce the next twenty on instinct.
- 04
Run one month of the calendar through the new states before migrating the archive. The archive is a migration task; the workflow is the thing being tested.
- 05
Build the narrowest useful version first: a pipeline view showing every piece past its due date and the step it is waiting on.
- 06
Writing the exit condition for each state takes an afternoon and resolves most recurring disputes. The record and the blocker view are a week. Migrating an archive is a separate project with real link and canonical risk, and it should not be bundled with the workflow build — run one month of the calendar through the new states first.
- 07
Once state and blocker are in use, join performance back to the record so the quarterly review reads from data rather than recollection. Multi-channel destinations come after, modelled as the same record with a different target rather than as a second workflow.
Controls
Controls that matter.
Control 01
Named reviewers per state with an escalation path, since the recurring failure is a review that nobody owns rather than a review that is refused
Control 02
Publication permission held separately from editing permission, so the state model cannot be bypassed by anyone with write access
Control 03
The published URL and its performance attached to the record, so retrospectives read from data rather than from recollection
Examples
Three status questions that answer themselves.
Where is that piece?
State and current blocker as properties of the record rather than as a question asked in chat removes most of what the weekly status meeting exists to establish.
The review that sat for nine days
A review window with escalation converts silence into a visible exception, which is the difference between a schedule and a set of aspirations.
The quarterly content review
Performance attached to each record turns what did well into a query rather than a research project, and reliably changes what the next quarter commissions.
How it goes wrong
Three ways editorial workflow degrades.
Nine states are defined, several overlap, and pieces sit in whichever one the last person picked.
Collapse any state without a verifiable exit condition. The count is a proxy for how much of the process was never agreed, and precision in the model does not create precision in the practice.
Publishing gets faster, monthly volume rises, and six months later organic search performance is falling rather than rising.
Publishing speed compounds whatever the quality is. Thin pages produced for coverage suppress the pages that would have ranked, and the effect takes months to appear and months to undo.
The archive is migrated and a year of accumulated search equity disappears.
Treat redirects and URL preservation as part of the migration rather than as cleanup. Search equity is not recoverable by apology and the loss is discovered a quarter later.
Limitations and considerations
What a CMS will not do for the content itself.
- Workflow does not improve writing. It removes the coordination overhead around it, which frees time that may or may not go into the work.
- Publishing volume for its own sake is actively harmful when it produces thin pages. A CMS that makes publishing faster will make that failure mode faster too.
- Migrating an archive carries link and canonical risk. Treat redirects and URL preservation as part of the migration rather than as cleanup afterwards, because search equity is not recoverable by apology.
- With one writer and one approver, a shared document is genuinely better. If the complaint is about the quality of the writing, workflow removes coordination overhead and frees time that may or may not go into the work.
- Connector coverage varies: Google Drive, Slack, GA4 are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a content management system with AI: common questions.
Does this replace WordPress or a headless CMS?
Often it sits in front of one. The publishing system stays; what gets built is the editorial workflow — briefs, states, reviewers, target dates, and performance — which is the part that otherwise lives in a spreadsheet beside the CMS.
How many states should there be?
As few as have distinct exit conditions somebody can verify. Five states with sharp definitions run better than nine with overlapping ones, and the count is usually a proxy for how much of the process was never agreed.
Should AI draft the content?
It can produce briefs, outlines, and first passes usefully. Publishing unreviewed generated content at volume is the mechanism behind the thin-content problem this kind of system is often bought to manage, so the review state is not optional.
What about content that lives outside the site?
Model it as the same record with a different destination. Splitting the workflow by channel reproduces the fragmentation the system exists to remove, usually within a quarter.
What should the first version contain?
A pipeline view showing every piece past its due date and the step it is waiting on. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure share of planned content that publishes on the planned date against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build a content management system around the process you actually run.
Define the exit condition of each state, put current blocker on every in-flight piece, and attach performance to the record from day one.