How to build a reliable content approval process for agencies

--- slug: reliable-content-approval-process-agencies title: "How to build a reliable content approval process for agencies" seoTitle: "How to Build a Reliable Content Approval Process for Agencies" metaDescription: "A repeatable content approval process for agencies: define roles, states, and SLAs, keep feedback in context, hold a single source of truth, then schedule and publish." focusKeyword: "content approval process" cat: "Agency Workflows" type: "Playbook" read: "9 min read" excerpt: "A practical approval playbook for agencies — roles, states, SLAs, comment-in-context, and a single source of truth — and how Acrosite supports each step from draft to publish." author: "Acrosite Team" date: "2026-06-06" updated: "2026-06-06" image: "/blog/reliable-content-approval-process-agencies.webp" imageAlt: "Abstract Acrosite illustration of a content approval process moving a draft through review states to a scheduled publish" ---

A reliable content approval process is what separates an agency that ships predictably from one that constantly chases sign-off. The work of writing and editing is rarely the bottleneck. The bottleneck is the approval itself: who reviews what, where their feedback lives, how long they have to respond, and what "approved" actually means before anything reaches a client's live website. When that part is vague, every piece of content becomes a negotiation, and your publishing calendar slips one quiet delay at a time.

This article lays out a repeatable approval playbook you can run across every client. We will define roles, set explicit states, decide who approves what, attach realistic SLAs, keep comments in context, hold a single source of truth, and then connect approval to scheduling and publishing. Along the way we will show how Acrosite supports each step, so the playbook is not just theory but something you can operate inside a real tool.

Why most agency approvals break down

Most agencies start by reusing the tools they already have. A draft gets pasted into a shared document, attached to an email, or dropped in a chat thread, and the client is asked to "take a look." This works for one piece. It falls apart at volume.

The usual failure points are predictable:

• No single source of truth. The version in the document, the version in the email, and the version the writer is editing all drift apart. Nobody is sure which copy is current.
• Feedback detaches from context. A client writes "the second section feels off" in a reply. By the time the writer reads it, the sections have moved, and the comment no longer points to anything.
• State is invisible. Is a piece waiting on the client, waiting on a revision, or already approved? Without an explicit status, the only way to know is to ask.
• Approval is informal. "Looks good!" in a thread is not a record. Weeks later, when someone asks who signed off, there is nothing to point to.
• Reviewers see too much. Sharing a whole folder often exposes drafts, internal notes, or other clients' work that the reviewer was never meant to see.

Each issue adds a delay. Stacked across dozens of pieces a month, they become the reason deadlines move. A real content approval process removes the guesswork by making roles, states, and timing explicit.

Step 1: Separate the two kinds of people in a review

The first decision is who is internal and who is the client, because they need very different access.

Team Members are your internal collaborators — writers, editors, account managers, and developers — working inside a Workspace. They hold roles such as Owner/Admin and can move content through its lifecycle, manage settings, and ultimately publish. They are the people who own delivery.

Client Reviewers are invited per Project and see only the content assigned to them. They can read drafts, leave comments, and either Approve or Request Changes. Crucially, they have no GitHub access, no billing visibility, and no workspace settings access. That isolation is the point: a client should be able to sign off on their own content without ever touching your repository, your other clients, or your operational tooling.

Getting this separation right early prevents the most common trust problems. Clients get a focused place to review; your team keeps full control of publishing and configuration. You can read more about how this works on the client review page.

Step 2: Define the states every Content Item moves through

Ambiguity about status is what generates "where are we on this?" messages. Replace it with a small, explicit set of states that everyone reads the same way. Every entry — whether it is one of your Posts, Pages, or Custom Content Types — exists as a Content Item that carries a clear status.

A practical state model for an agency looks like this:

1. Draft — being written or edited internally. Private in the app, not committed anywhere.
2. In review — assigned to a Client Reviewer or an internal editor and visible in the Review Queue.
3. Changes requested — a reviewer asked for edits; ownership returns to the writer.
4. Approved — sign-off is recorded and the piece is cleared to publish.
5. Scheduled — approved and queued for a specific publish time.
6. Published — committed to the connected repository and live (or queued for the next deployment).

The value of named states is that anyone can open the Review Queue and see exactly what is waiting on them and what is waiting on the client, without asking. Drafts stay private in the app until they are published, so an in-progress piece never accidentally appears in the repo.

Step 3: Decide who approves what

A content approval process needs to answer one question for every piece: whose "yes" is required before it ships?

Keep it simple and write it down per Project:

• Internal editorial pass — a Team Member with editing responsibility reviews for accuracy, structure, and brand voice before the client ever sees it.
• Client sign-off — the assigned Client Reviewer Approves or Requests Changes. This is the contractual "yes."
• Publish authority — a Team Member with the right role performs the actual publish. Approval and publishing are deliberately separate steps, so a client approval does not commit code on its own.

Decide whether a single Client Reviewer can approve or whether a piece needs more than one sign-off, and document it. The goal is that no one is ever guessing whether they are allowed to give the final yes.

Step 4: Set SLAs so reviews do not stall

States and roles tell you where a piece is; SLAs tell you how long it is allowed to sit there. Without a time expectation, "in review" quietly becomes "forgotten."

Set realistic, written turnaround targets and share them with clients up front. A common pattern:

• Internal editorial review: within one business day of a draft being marked ready.
• Client review: within two business days of assignment.
• Revision turnaround after Changes Requested: within one business day.

Use the Review Queue as your operational dashboard. Anything sitting past its SLA is a follow-up, not a surprise. Pair this with a Content Calendar so every piece has both a target publish date and the review window that must close before it. When the calendar and the queue agree, slippage becomes visible early rather than on launch day.

Step 5: Keep feedback in context and hold one source of truth

Two principles eliminate most rework.

Comment in context. Feedback should live on the Content Item itself, not in a separate email or chat. When a Client Reviewer comments directly on the piece they are reviewing, the writer sees the note against the current version, not a paragraph that has since moved. The conversation and the content stay together for the life of the piece.

One source of truth. The Content Item in Acrosite is the canonical version. There is no parallel copy circulating in a document or an inbox to drift out of sync. Everyone — writer, editor, and Client Reviewer — is looking at and acting on the same record. When a reviewer Requests Changes, the piece returns to the writer with the comments attached; when they Approve, that decision is recorded against the item.

This is also where access scoping pays off. Because Client Reviewers only see assigned content, the single source of truth they review never leaks your other clients' drafts or your internal notes.

Step 6: Schedule and publish — deliberately, with a record

Approval is the green light; publishing is the action. Keeping them separate is what makes the process safe.

Once a piece is Approved, a Team Member either publishes it or uses Scheduled publishing. Scheduling holds the approved draft inside the app and commits it at the chosen time — there is no early commit to the branch and no half-finished file sitting in the repo waiting for a date. The repository only ever receives content that has been signed off.

When a publish runs, Acrosite uses GitHub publishing to commit the Markdown or MDX file, with its YAML frontmatter, to the connected repository on the configured branch and content path. A typical frontmatter block and path look like this:

# committed to content/posts/ on the configured branch
---
title: "Spring product update"
slug: spring-product-update
date: "2026-06-06"
status: published
---

After the commit, a configured deployment trigger profile tells your hosting provider to rebuild, which gives you deployment visibility into whether the live site picked up the change. Every attempt is recorded in Publish Logs — validated content, committed to GitHub, commit SHA saved, deployment triggered — without ever exposing tokens, hook URLs, or raw provider payloads. Deployment Logs record the trigger results. If a publish fails, you can retry where it is safe, and you have a clear record of what happened rather than a mystery.

A repeatable approval checklist

Run this for every piece, on every Project, and the process becomes muscle memory:

• Confirm the piece is a tracked Content Item, not a stray document.
• Complete the internal editorial pass before involving the client.
• Assign the right Client Reviewer; confirm they see only their content.
• Apply the review SLA and watch the Review Queue for anything overdue.
• Keep all feedback as in-context comments on the item.
• Record an explicit Approve before scheduling.
• Use Scheduled publishing to commit at the planned time.
• Verify the commit and rebuild in Publish Logs and Deployment Logs.

If you manage several client sites, this same playbook holds whether you run three Projects or thirty. You can compare how this approach maps to other tools on the compare page, and see the full feature set on features.