A content approval workflow breaks down when “ready for review” gets treated as permission to publish. Your internal reviewer may have checked the draft against the brief, but someone still needs to decide whether it can go live. Without that separate decision, feedback can become mistaken sign-off, publication can stall and later edits can slip through unchecked.
The stages in a content approval workflow
Give each stage a question it must answer before the task moves forward. The labels should tell your team what has happened and whose decision is needed next.
- Draft: Is the content still being written or revised? The writer owns the working copy. It can contain unresolved questions, missing evidence or sections that need another pass.
- Ready for review: Is the draft complete enough for the reviewer to assess? The writer hands over the draft with its brief, research and any outstanding questions. This stage asks for a quality check.
- Reviewed (changes made): Is the content good enough, and does it follow the brief? The reviewer confirms that requested changes have been made and checked. Unresolved review comments keep it from moving to approval.
- Approved to publish: Can this version go live? The named approver gives explicit permission to publish the specified version. That decision belongs on record before publication starts.
- Published: Has the approved version gone live? The person publishing checks the live page against that version and records the URL and publication date.
For a general example, say your reviewer asks for a clearer explanation of a service. The writer makes the change and the reviewer accepts it. The content has passed the internal quality check. If your client owns publication approval, you still need their decision before uploading it.
Name the reviewer and approver separately
Assign both roles when you assign the writing. The reviewer checks accuracy, coverage, tone and compliance with the brief. The approver decides whether the content can represent the client publicly, including whether the offer and timing are right.
An account lead might review a draft while a client contact approves publication. In another agency, the delivery lead might hold both roles under authority agreed with the client. Even then, record the two decisions separately. One person can finish reviewing a page while still waiting for confirmation about a service claim.
A review asks whether the draft is good. An approval asks whether it can go live.
Avoid assigning approval to “the client” or “the account team”. Name the person who gives the final yes and the agency person responsible for getting that answer. If the approver is away, agree who can act in their place before the task reaches the approval stage.
Your writer also needs somewhere to send disputed feedback. Give the reviewer responsibility for resolving internal comments, so the writer doesn’t have to guess which colleague’s preference takes priority.
Tie approval to the version that will go live
Approval applies to the version the approver saw.
A document link alone can leave that unclear. If the document keeps changing, opening the same link later may show different wording from the copy that received approval. Keep a named version, a dated snapshot or another retrievable record of the approved content.
Record these details with the publication decision:
- Who approved: The person’s name and role, including whether they were acting for the usual approver.
- When they approved: The date and time of the decision.
- Which version they approved: A version identifier or retained copy that lets someone recover the exact wording.
- What they authorised: Permission to publish, plus any stated conditions about timing or placement.
Keep the approval message with those details. A status changed by an account lead should have supporting evidence from the approver, so another team member can see how the decision was reached.
Changes after approval
Say a client approves a service page, then someone adds a paragraph about an extra service before upload. The client’s decision covered the earlier copy. Return the changed draft for approval and explain what changed, even if your team thinks the addition is helpful.
Use the same rule for a smaller edit. Don’t leave the writer or publisher to decide whether a wording change is too minor to matter. Keep the previous approval in the task history, identify the replacement version and get a fresh decision.
If a client approves subject to an edit, make that edit and return the resulting version for confirmation. The condition needs to be closed before the task becomes approved to publish.
Make client sign-off an explicit decision
Choose one named approver per client and confirm that they have authority to approve publication. Other people can contribute comments, but the content review process needs someone responsible for resolving those comments and giving the final answer.
Send the approval request with the version, its intended destination and a response date. Keep the ask direct: Please approve this version for publication or request changes by the agreed date. Explain any unresolved issue beside the draft, where the approver will see it before deciding.
“Thanks”, an acknowledged email or a positive comment about one section can leave permission unclear. Ask for explicit client sign-off. If the response requests changes, return the task to draft, make the edits and complete the relevant review before asking again.
Silence is not approval. When the response date passes, keep the task awaiting approval and give the account lead responsibility for following up. Record the missing decision and tell the client if it affects the intended publication date. Don’t move the task to approved simply because the calendar has reached its planned slot.
Some clients need technical, brand or senior colleagues to contribute before their named approver can decide. That can leave a dependency outside your agency’s control. Agree who gathers those responses, and make the outstanding dependency visible rather than promising a publication date your team can’t yet support.
Set up the workflow on your next content task
Use one upcoming article to check whether your current process can carry these decisions. Work through the following setup checklist before sending it for review.
- Define the stages. Use draft, ready for review, reviewed, approved to publish and published. State what evidence is needed to leave each stage.
- Name the people. Assign the writer, reviewer, approver and publisher. Identify who follows up when a decision is overdue.
- Set the review check. Attach the brief and research, and agree what the reviewer must check. Require confirmation that requested changes have been addressed.
- Prepare the approval request. Point the approver to a specific version and ask them to approve publication or request changes by an agreed date.
- Record the decision. Retain the approver’s response, name, date, time and version. Return any changed copy for approval before it goes live.
- Check publication. Compare the live page with the approved version, then record its URL and publication date on the task.
If your task system has one status called “done”, decide whether it means the writer has finished, the client has approved, or the page is live. Give those moments separate labels before relying on that status in a client update.
Keep the decision with the task
When the brief is in one place and approval is buried in a message thread, the person publishing has to reconstruct what happened. Keep the research, brief, draft and decisions attached to the content task so the handover includes the reason it can proceed.
This is how Doxa, an agency management platform built around SEO delivery, treats content work. Research, brief and draft stay attached to the task, with “ready for review” and “approved to publish” as separate, recorded stages.
Get in touch at hello@doxaseo.com to talk about the platform or how your agency works.