“We do not really have a process” is almost never true. What is true is that the process is unnamed, which means nobody agreed on it, which means each stage is performed by whoever happens to notice, or by nobody.
Every article that gets published passes through the same seven stages. The only variables are whether each one has a name, whether it has an owner, and whether it is merged into another. A small team merges most of them, and that is correct. An unnamed stage is a different thing: it happens inconsistently and nobody is accountable for it.
Here they are, with what each is actually for and how it fails.
1. Decide
Somebody decides this article should exist, and what it is.
What it produces: an entry on a list, with enough detail that a writer would produce the intended thing.
How it fails: it does not happen. Someone writes whatever occurred to them, and the question of whether the site needed it is answered afterward, by which point the work is done.
Merge it with: nothing. This is the stage most worth keeping separate, because everything downstream inherits its errors and none of them can correct it.
2. Brief
Turn the decision into instructions a writer can work from.
What it produces: what the article covers, who it is for, what it must contain, what it must not, how long, and what “done” means.
How it fails: it is skipped, and the wrong article is produced. The wrong article is not the writer’s error and it does not get fixed at review, because review can only catch it after it exists.
Merge it with: stage 1, on a small team, provided the decision is written down in enough detail. A one-line decision is not a brief.
3. Draft
Write it.
What it produces: a complete article.
How it fails: two ways. It is not complete, so review has to guess whether something is missing or unfinished. Or it stops being one person’s, because somebody else started editing before it was handed over, and now nobody knows which version is current.
Merge it with: nothing. This is where the work is.
4. Review
Somebody who is not the writer reads it.
What it produces: either “this is fine” or a list of specific changes.
How it fails: three ways, and all three are common.
Nobody owns it, so several people comment and nobody decides. Comments are not a decision.
It is unbounded, so review turns into rewriting, and the writer receives an article that is no longer theirs.
It is confused with approval. Review says what should change. Approval says it can go. Merging them is what produces the stall where three people have opinions and nothing ships.
Merge it with: stage 5, on a small team, provided one person does both.
5. Approve
One person says it can be published.
What it produces: a decision, by a named person, that closes the question.
How it fails: the approver is diffuse or the approver is a bottleneck. The first is structural and is the single most consequential fix in a small team’s workflow.
Merge it with: stage 4, if the same person does both. Never merge with stage 3, which would mean the writer approves their own work.
The diffuse-approver problem is worth naming as its own rule rather than as a bullet: a single final approver, decided in advance and the same person each time for a given kind of content, is the change that unsticks most stuck workflows, and it works because it converts a discussion into a decision.
6. Prepare
Everything between an approved article and a publishable one.
What it produces: the article with its image, its metadata, its categories, its links, its slug, and anything else your site needs on every post.
How it fails: it is invisible. Nobody thinks of it as a stage, so it happens in whatever gap exists, which is why articles go out with the wrong image or without a summary.
This is the stage a checklist is actually for. Not a generic best-practice list, a list of the things your site has got wrong before.
Merge it with: stage 3, if your writers do their own preparation, or stage 7 if one person publishes everything. Either is fine. Unowned is not.
7. Publish
It goes live, on a date somebody chose.
What it produces: a published article and a calendar that is still accurate.
How it fails: the date is a surprise, or the publish itself requires a person who is not available. That second one is a platform property rather than a process one, and it shapes everything upstream of it: if publishing needs a technical person, every publish is a handoff regardless of how you design the rest. Can a non-developer actually publish on this? is the hour-long test that establishes it.
Merge it with: stage 6, usually.
After: the stage nobody has
There is an eighth thing that is not part of getting an article out and is worth naming anyway.
Somebody looks at what was published and decides whether to change it. Corrections, updates, retirement of things that are no longer true.
Almost no small team has this, and the absence compounds silently: an archive accumulates pages that were correct when written. It does not need to be a stage in the pipeline. It needs to be a recurring appointment with an owner.
How to find your own
Take the last five things you published and reconstruct what actually happened to each one.
For each stage above, write down: did it happen, who did it, and how long did it wait.
Three things fall out immediately.
The stages that did not happen are your gaps, and they will correlate exactly with what you have been getting wrong. If one of them is stage 1, the fix is upstream of everything else, and the platform question of whether your content model even lets you record a decision is worth checking too: content model migration covers why a model that lives in code and one that lives in a UI behave so differently when you want to change them.
The stages with no owner are where things stall. Not the slow stages, the unowned ones.
The waiting time is the real cost. Work takes hours; queues take days. If the total elapsed time is far larger than the total working time, and it usually is, the problem is queueing rather than effort, and adding stages will make it worse.
Merging, and the rule for it
Small teams should merge aggressively. Four states is enough for two to five people.
The rule for what may merge: two stages can merge if the same person performs both and the second does not check the first.
So review and approve can merge, because one person reading and then deciding is coherent. Draft and approve cannot, because the writer would be checking their own work, which is the one thing review exists to prevent.
Everything else is a judgment about your team.
The short version
- You already have all seven stages. The question is whether they are named and owned.
- Decide, brief, draft, review, approve, prepare, publish.
- Review says what should change; approve says it can go. Merging those two is the classic stall.
- Prepare is the invisible stage and the one a checklist is for.
- Reconstruct your last five articles against the list. The unowned stages are where things stall.
- Merge freely, as long as the same person does both and the second is not a check on the first.
- Add the eighth thing, updating what is already published, as an appointment rather than a stage.
