← Back to blog

Content Marketing · November 6, 2026 · 8 min read

The Content Approval Workflow for Client Blog Posts

Client approval breaks on gate count, not tooling. Two gates is the ceiling: one internal edit, one client sign-off, with a named approver and a stated review window.

By FluxWriter

A client content approval workflow breaks at the gate count, not at the tool. Two gates is the ceiling: one internal edit, then one client sign-off. Every gate added after that buys very little quality and costs days per post, whether it is the account manager read, the founder's glance or a second opinion from the client's marketing hire. This walks through where the extra gates come from, what each one costs in calendar days, and the four rules that keep a client blog shipping.

Gates Multiply Because Nobody Is Assigned To Remove Them

Approval chains grow by accretion. A client is unhappy with one post, so you add a reviewer. Someone on the client side asks to be kept in the loop, so you add them to the thread. Each addition answers a real event, and none of them is ever taken back out. Two years later a 900-word post passes through five people and takes a fortnight.

The tool is almost never the problem. Trello, Asana, Notion, a shared document, a numbered email thread: all of them move a draft at the speed of the slowest human in the chain. Switching from email to a project board makes the waiting visible, which is genuinely useful, but it does not shorten it. If you have migrated approval tooling twice and your cycle time has not moved, that is the diagnosis.

What does change cycle time is deleting a gate. It is the only lever with a reliable effect, and nobody pulls it, because removing a reviewer feels like telling a colleague their opinion does not count.

Two Gates Is The Working Ceiling

Gate one is the internal edit. That is where the draft is checked against the brief, facts are verified, links are resolved, the house voice is applied, and the on-page details (title, meta description, heading levels, internal links) are set. It is a craft pass and it belongs entirely to you.

Gate two is the client sign-off. It answers three questions and no others. Does this sound like us. Is anything here wrong about our product, our pricing or our market. Is there a claim here we are not willing to make. The client is the authority on their own business, and on nothing else in the document.

The common failure is letting gate two do gate one's job. Send a draft to a client with typos in it and you have converted your client into a copy editor. Clients who have been made copy editors stay copy editors. The next draft comes back with comma changes attached, and every post from then on carries a round of line-level argument. The fix sits upstream: nothing reaches the client that you would not be happy to publish exactly as it stands.

Every Extra Gate Costs Days, Not Minutes

A reviewer spends perhaps fifteen minutes on a post. The fifteen minutes is not the cost. The cost is the handoff, because the draft sits in someone's inbox until they next look at approvals, and for most people that is not today. Assume two working days of waiting per handoff as a planning figure. Some turn a draft round in an hour, some take a week.

The table below is illustrative. It applies that two-day assumption and adds one day of actual work per post.

Two gates puts a post live in about a working week. Four gates takes nearly two. The second number hurts more than the arithmetic suggests, because of what it does to the amount of work you hold at once. Take an agency running ten clients at four posts a month. That is forty posts across twenty working days, so two new drafts start every day. At a five-day cycle you are carrying ten open drafts at any moment. At nine days you are carrying eighteen. The chasing, the status questions and the "where are we on the March posts" emails all scale with that number, not with how fast anyone writes.

That is the real cap on how many clients one person can carry. Not writing speed. Open items.

One Named Approver Beats A Distribution List

Send a draft to three people at a client and you get one of two outcomes. Silence, because each assumed another would handle it. Or three sets of conflicting edits that somebody has to reconcile, and that somebody is you, the one person without the standing to overrule any of them.

Name one approver per client, by name, at the start of the engagement, and name a deputy for holidays and illness. Put both names in the scope of work. If other people at the client want to see drafts, that is fine. The approver circulates internally and comes back with one consolidated response. Their internal politics are not your workflow.

The quiet failure here is staff turnover. The approver changes role, nobody tells you, drafts go to a mailbox no one reads, and the programme stalls for six weeks before anyone notices. Add a line to your quarterly check-in confirming the approver is still the approver. It catches the most expensive silence in client work.

A Stated Review Window, Agreed Up Front

The rule that does the most work is a review window. A draft sent for sign-off carries a stated deadline, three working days is a reasonable default, and if nothing comes back within it the post publishes on the schedule as written.

Agree this at the start of the engagement rather than the first time a client goes quiet. Set it out in the scope of work and raise it in the kickoff call, so nobody meets it for the first time in an argument. Whether that wording carries any weight beyond the working convention is a question for whoever drafts your agreements, not one to settle from a blog post. The operational value holds either way, because it turns an open-ended wait into a date.

Make the window humane. Send every draft with its publish date already on it, and send one reminder the day before the window closes. If a client works in a sector with its own review requirements, ask what their internal process needs before you set the window instead of assuming your default fits. That question belongs in the kickoff, not in the first missed deadline.

Feedback After Publish Becomes A Revision Ticket

Some feedback arrives after the post is live, because the client read it properly for the first time on their own website. The instinct is to pull the post down, fix it and put it back. Resist that.

A URL that stays in place and gets edited keeps whatever it has built: the links pointing at it, its crawl history, any position it has earned. Reissue it at a new address and you are spending redirect work to get back roughly where you already were, while anyone who shared the original hits a dead link. Editing in place is nearly always cheaper.

So route post-publish feedback into a revision queue with its own turnaround, two working days works well, and treat it as an ordinary ticket rather than an emergency. The exception is a factual error or a claim the client is not willing to stand behind. That is corrected immediately, in place, and it does not sit in a queue.

Tickets also leave a record. When the same client raises the same note four months running, that is not a writer problem, it is a brief problem, and the log is the evidence that gets the brief rewritten.

Approval Is Not Finished Until The Post Is Live

Plenty of agencies run a clean two-gate process and still ship late, because approval ends in a document. The post is approved on Tuesday, then sits in a folder until somebody has a spare hour to paste it into WordPress, set the featured image, repair the heading levels the paste broke and schedule it. That is another handoff, and it hides from every status board because the post is marked approved.

Count the last mile as part of the workflow. Either sign-off happens inside the publishing system, where the draft already sits in the client's CMS and approving it means scheduling it, or the person who owns publishing has a standing slot in their week for it.

FAQ

Should the client approve topics as well as drafts?

Yes, but in batches rather than per post. Approve a quarter of topics in one sitting and the per-post gate count stays at two. Approving each topic before it is written doubles your handoffs and puts the same programme on the client's response time twice over.

What if a client simply never responds?

Treat that as a relationship problem rather than a workflow problem. A stated review window keeps posts moving, but a client who never reads anything is a client who will be surprised one day, so raise it directly and early. Start by asking whether the named approver is still the right person.

Does a two-gate workflow hold for a client with a compliance function?

The shape holds: one internal pass, then one client pass. The client pass may take longer and may involve people you never meet, and that is their side to run. Ask at kickoff what their internal review requires, then set the window around that answer rather than around your default.

The Practical Takeaway

Count your gates before you change anything else. Open the last five published posts for your largest client and write down every person who touched each one and the date they touched it. The audit often turns up one reviewer who has never changed a word, and one handoff that costs three days on its own. Those are the two things to remove. Then name the approver and the deputy, agree a review window in writing at the next renewal, and move post-publish notes into a ticket queue. Do the audit this week: five posts, one sheet, names and dates.

On FluxWriter's Pro and Agency plans each teammate works from their own seat and the activity log records who generated and who published each post, so the internal half of that gate audit is a read of a log rather than a trawl through five email threads.

← All posts