Somewhere right now a social media manager has posted a link in a group chat with the message "can you approve this?" and then waited. An hour passes. Two. Someone replies "looks good but can we change the headline?" A third person replies "which version is this?" A fourth sends a completely different edit in a separate thread because they never saw the second version. On Thursday the post goes out with the original headline, because nobody confirmed which edit won.

This is the default state of approval for most small teams and agencies, and it fails for a boring reason: the request has no home. The post lives in a design tool, the feedback lives in a chat app, the final version lives in someone's downloads folder, and the decision lives in nobody's memory. Every hour spent waiting is an hour spent reconstructing context. Multiply that by every post, every week, and you find the real cost — not the delay itself, but the number of times a campaign quietly ships a version nobody agreed to.

An approval workflow fixes the mechanics. It gives every post a state, every state an owner, every owner a deadline, and every reviewer a checklist. It also fixes something less obvious: it makes reviewers faster. A person who opens a post and immediately knows the four things they are checking will respond in six minutes. A person who opens a post and thinks "what am I supposed to be looking at again?" will respond tomorrow, if at all.

This post is a complete build for that system. Roles and permissions, the lifecycle states, a concrete review rubric, how to write feedback that shortens the next round instead of extending it, response deadlines and escalation, how to split the workflow by risk level so routine posts never wait behind sensitive ones, how to bring external clients in without reopening the chat-app problem, and how to measure whether any of it is working. There is a roll-out sequence at the end sized for teams of three to ten.

Approval is not a gate you put in front of publishing. It is a queue with owners, deadlines and a definition of done.

Why approval threads happen at all

It helps to name the underlying causes, because each one needs a different fix. In every team we have worked through this with, the same four appear.

• Nobody is the decider. "The team" is asked to approve, which means an individual is expected to volunteer. Volunteers arrive late, if they arrive.
• The request carries no context. The approver sees a caption with no idea what changed, what it is attached to, or when it must go out. So they ask questions instead of deciding.
• Feedback has no categories. "This feels a bit off" is not actionable. Reviewers who cannot point at a rule write opinions, and opinions generate rounds.
• There is no consequence for silence. If ignoring a request produces the same result as approving it, ignoring wins every time. A deadline with no escalation is a suggestion.

Notice that none of these are attitude problems. They are missing-structure problems, and structure is cheap to add.

The cost nobody counts

The visible cost is delay. The invisible costs are worse:

• Decisions get re-made. Someone approves a caption on Monday, changes their mind on Wednesday, and the post ships the fourth version with no record of which version won.
• Junior staff stop proposing. If every idea requires surviving three rounds of ambiguous critique, people stop bringing ideas. Your content gets safer and duller in direct proportion to your approval friction.
• Accountability evaporates. When a post goes out wrong, the chat scroll proves everybody saw it and nobody owned it.
• Clients get impatient. Agencies lose renewals over slow approvals more often than over bad creative, because the client feels the waiting every week.

Fixing approval does not just speed publishing up. It makes the team willing to attempt riskier, more interesting work, because the cost of a wrong turn is now a ten-minute revision instead of a lost afternoon.

The four failure modes of ad-hoc approval

Once you are watching for them, ad-hoc approval fails in recognisable patterns. Each has a specific remedy.

1. The approval vacuum

The post is requested, nobody responds, and someone publishes anyway to avoid missing the slot. The fix is a named approver per post plus a rule that silence never counts as consent.

2. The committee edit

Five reviewers each add their own preference, and the piece is rewritten five times without anyone being able to reconstruct the original intent. The fix is feedback categories: a reviewer can raise a blocker or a preference, but preferences do not force a rewrite.

3. The version fork

Two edits run in parallel in two places and the wrong one ships. The fix is a single source of truth: one post record, one current version, every comment attached to that version.

4. The late-stage ambush

Everything is approved, the post is scheduled, and a stakeholder spots it an hour before it goes out with a completely new objection. The fix is including the right people in the first round, and freezing sensitive posts 24 hours before publication.

Failure-mode checklist

• Every post has exactly one named approver before it enters review
• Silence is defined as escalation, never as approval
• Reviewers choose between blocker and preference on every comment
• Only one version of a post exists at any moment
• Stakeholders are added in round one, not round five
• Sensitive posts freeze 24 hours before their scheduled time

Design: roles, permissions and who actually signs off

Start by naming four roles. Resist adding more; each additional role adds a handoff, and handoffs are where days disappear.

The four roles

• Owner. The person responsible for the post existing. Writes it, answers questions about it, chases it, and is accountable if it ships wrong or ships late. One per post, never two.
• Editor. Reviews for quality: structure, clarity, hook, platform fit. May revise directly. Usually a peer or a senior writer.
• Approver. Signs off on correctness and risk: claims, pricing, brand, legal, timing. Has a yes/no and a comment box. Usually a lead, a client contact, or the brand owner.
• Observer. Sees the post and its comments but cannot change status. Useful for stakeholders who want visibility without becoming a bottleneck.

The single most valuable rule in this section: one approver per post. Committees are where approvals go to die. If two people genuinely must sign — say a legal reviewer and a brand lead — make it a sequence with a written order, not a simultaneous request where each waits for the other.

Permission design

Give people the narrowest access that lets them do their job.

• Writers can edit and submit, but cannot mark approved
• Editors can request changes and comment, but cannot approve their own submission
• Approvers can approve, reject and comment, but do not need editing rights
• Observers get a read-and-comment link, not a login, if they are external

The "cannot approve your own work" rule feels pedantic until the first time someone self-approves a claim they should have checked. For solo operators, the workaround is a deliberate second pass: save as draft, wait an hour, then review it as if someone else wrote it.

Map the roles for your actual team

For a three-person team the mapping is usually: the social media manager is owner and editor, the marketing lead is approver, and the founder is an observer who gets added only for launch, pricing or crisis posts. For an agency, the account manager is owner, the strategist is editor, the client's marketing lead is approver, and the client's brand team observes.

Write the mapping down once. The first time somebody asks "who signs off on this?" and gets a different answer from two people, you will know why it matters.

The lifecycle: six states, no vague waiting bucket

A post should never be "in progress" or "waiting". It should be in exactly one of six states, and everyone should be able to say what the next state is without asking.

1. 1Draft. Being written. Owner only. No notifications.
2. 2In review. Submitted to a named editor or approver with a deadline. This is where the clock starts.
3. 3Changes requested. Returned to the owner with categorised comments. The state must record what specifically must change, otherwise it becomes a loop.
4. 4Approved. Signed off, ready to schedule. Nothing about the post may change without dropping it back to draft, which invalidates the approval — this is the rule that stops version forks.
5. 5Scheduled. Locked into a publishing slot. Edits now require a deliberate unlock, which is a small friction that prevents careless late changes.
6. 6Published. Archived with the approval history attached, so anyone can reconstruct who signed off on what and when.

Two supporting states are worth adding but should be rare: Expired for posts that missed their window and must be re-reviewed, and Blocked for posts waiting on something external — a product screenshot, a legal answer, a client asset. A post sitting in "In review" when it is actually waiting on a screenshot is lying to your queue.

The transition rules

States only move forward with an explicit action by the right role, and every transition is logged.

• Owner: draft to in review, changes requested back to draft, approved to scheduled
• Editor or approver: in review to approved or changes requested
• Nobody: back to a previous state without a comment explaining why

That last rule is the important one. Approvals that can be silently reversed are approvals that people stop trusting.

Lifecycle checklist

• Six states in use, with no vague "waiting" bucket
• Exactly one owner and one approver recorded per post
• Approved posts lock, and edits force a return to draft
• Expired and Blocked used as exceptions, not as parking spots
• Every transition logged with a timestamp and a person
• The queue view shows state, owner, approver and deadline at a glance

The review rubric: what reviewers actually check

The reason reviewers take two days is not that they are slow. It is that they open a post and have to work out from scratch what they are meant to examine. Give them a rubric of six checks, in a fixed order, and the same review drops to minutes.

The six checks

1. 1Accuracy. Are every number, name, price, date and claim correct? If a claim cannot be sourced in thirty seconds, it becomes a blocker.
2. 2Brand and voice. Does it sound like us? Use the voice brief rather than personal taste — "this does not match our brief" is a review; "I would not have written it this way" is a preference.
3. 3Risk and compliance. Regulated claims, competitor comparisons, music or image licensing, employee or customer quotes with permission, anything touching a sensitive moment.
4. 4Craft. Hook, structure, length for the platform, call to action, spelling. Note that craft comes third, not first — checking commas before checking facts wastes everyone's round.
5. 5Mechanics. Hashtags, links and UTM tags, alt text on images, captions on video, correct accounts selected, correct time zone, correct campaign label.
6. 6Timing. Does this still make sense on the scheduled day? Is it near a launch, a holiday, a sale, a news cycle or a period where silence is expected?

Blocker or preference — the rule that halves review rounds

Every comment must declare which one it is.

• Blocker. Wrong fact, brand risk, broken link, wrong account, wrong date. Must be fixed before approval.
• Preference. Wording taste, emoji choice, alternative hook. Noted, not required.

This single distinction is the biggest practical gain available to a team that already reviews carefully. Preferences do not reopen a post; they get recorded for the next revision. If a reviewer submits five comments and none are labelled, the owner has to guess which ones matter — and guessing is what generates round three.

Version note on submission

The owner submits with one line describing what changed: "Headline rewritten, price corrected to 4,900, added UTM." Reviewers reading a diff make decisions in seconds; reviewers reading a full post from scratch take minutes. This costs the owner fifteen seconds and saves the reviewer several minutes per round.

Rubric checklist

• Six checks used in the same order every time
• Blocker or preference labelled on every comment
• Submission note states what changed since the last round
• Accuracy checked before craft, never after
• Voice brief referenced instead of personal taste
• Timing checked against the actual calendar date

Writing feedback that shortens the next round

Feedback quality determines whether you have two rounds or five. Four rules cover almost everything.

Point at the fix, not the problem

"Weak hook" tells the writer nothing they can act on in the next ten seconds. "The first line repeats the on-screen text — open with the number from the third paragraph instead" is a fix. Reviewers who are not sure of the fix should say so explicitly: "I think this is weak but I do not have a better idea, so treat this as a preference." Honesty about uncertainty stops a preference from being mistaken for a blocker.

Bundle and prioritise

Send one batch of comments, not seven messages across an afternoon. If a reviewer is still adding comments an hour after opening the post, they should hold them for a single submission. Interleaved feedback means the writer starts revising before they know the full scope, which guarantees a second pass.

Use categories so the writer can triage

Label comments by type — fact, voice, structure, mechanics, timing. A writer can fix five mechanics comments in two minutes but needs twenty minutes for a structure comment. Knowing the mix lets them schedule the work instead of reacting to a stream.

Say what success looks like

The most efficient feedback ends with a definition of done: "If the price is corrected and the first line changes, this is approved." The writer knows exactly when to resubmit, the approver knows exactly what they are re-checking, and neither has to re-read the entire post.

The purpose of feedback is not to express an opinion. It is to make the next version the last one.

What to do when review stalls

Sometimes the post sits in review past its deadline. Escalate in a fixed sequence rather than sending polite nudges into a chat:

1. 1At the deadline, the system reassigns the request to a named backup approver automatically.
2. 2If the backup misses too, the owner notifies the approver directly with one line: "Post X is 6 hours past review deadline and blocks Friday's slot. Need a yes or a no by 3pm."
3. 3If there is still no answer and the slot is at risk, the owner reschedules the post to the next slot and records the miss. Do not publish unapproved content to protect a calendar slot — a late post is an inconvenience, an unapproved post is a risk.

Record every miss. Three misses from the same approver is a structural signal that the approver is the wrong person or is over-subscribed, not that they are careless.

SLAs, deadlines and the escalation path

Deadlines turn approval from a favour into a process. Three numbers are enough.

• Editor review: within 4 business hours. Quality feedback should arrive while the post is still fresh in everyone's head.
• Approver sign-off: within 1 business day. One day is short enough to keep a weekly calendar moving and long enough for a busy lead.
• Client sign-off: within 2 business days, with an expiry after which the post is rescheduled rather than assumed approved.

Attach each deadline to a working-hours window that is actually staffed, and state that window in the request. "Review needed within 24 hours" is ambiguous; "review needed by 5pm PKT Thursday" is not.

Escalation triggers

Escalation should be automatic rather than a social negotiation:

• Deadline missed by one hour: notification to the approver with the specific post and the blocked slot
• Deadline missed by four hours: reassignment to the backup approver
• Deadline missed by one business day: the owner reschedules and logs the delay
• Two consecutive misses by the same person: the workflow owner reviews whether that person should be an approver at all

Design the freeze rule

Sensitive posts — pricing changes, product recalls, campaign launches, anything legal has looked at — should freeze 24 hours before publication. After the freeze, edits require an explicit unlock by the approver with a comment. Late-stage surprises are almost always caused by stakeholders seeing a post for the first time in its final hour; freezing makes seeing it earlier a requirement rather than a courtesy.

Different tracks for different risk

The most common design error is putting every post through the same process. A routine educational carousel does not need the same scrutiny as a pricing announcement, and treating them alike means either routine posts are over-reviewed and slow, or sensitive posts are under-reviewed and dangerous.

Three tracks

• Track A — standard. Educational, behind-the-scenes, community and repurposed content. Owner submits, editor approves, done. Target: approved within 4 business hours. This is 60 to 80 percent of your output.
• Track B — sensitive. Anything with a price, a discount, a performance claim, a partner, a customer story or an executive quote. Owner submits, editor reviews, approver signs. Target: 1 business day. Usually 15 to 30 percent of output.
• Track C — critical. Launches, crisis responses, legal or regulatory topics, anything touching a sensitive cultural moment. Owner writes, editor reviews, approver signs, second approver confirms. Freeze 24 hours before publication. Usually under 5 percent of output.

Assigning a track without debate

Let the owner assign the track at creation, using a plain-English test: "If this post is wrong, does it cost us money, customers or credibility?" If yes to any of the three, it is at least Track B. If it could make the news, it is Track C. Reviewers can raise the track — a post submitted as A that turns out to contain a price gets bumped to B — but only approvers can lower it.

Why this makes teams faster, not slower

Paradoxically, adding tracks speeds up most publishing. Once the team sees that a routine carousel gets approved in four hours because it is Track A, the objections that used to attach themselves to every post migrate to the tracks where they belong. You get fewer reviews on low-risk work and better reviews on high-risk work.

Track assignment checklist

• Track chosen at creation by the owner, not by whoever opens the queue
• Default is Track A unless money, credibility or news is at stake
• Track C requires a second approver and a 24-hour freeze
• Reviewers may raise a track; only approvers may lower one
• Track distribution reviewed monthly — if everything is Track C, the rubric is wrong
• Track A target of four hours is published where writers can see it

Client approvals: external stakeholders without chaos

Agencies and in-house teams that answer to clients have an extra failure mode: the approver is outside your tooling, so the process leaks back into email threads and screenshots. The fix is to bring them in as a first-class participant rather than a correspondent.

One link, comment-only

Give the client a single link to the post with its assets, caption and scheduled time. They comment in place; you resolve comments in the same view. No attachments, no "final_v3_reallyfinal.pdf", no screenshots of captions pasted into email. The version history is the record.

Define the contract at the start of the engagement

Write four lines in the onboarding document and repeat them in the first approval request:

• Approvals are due within two business days of the request
• Silence after two days means the post is rescheduled, never published
• Comments are blockers or preferences; only blockers stop the post
• After approval, changes require a new approval round and may miss the slot

Clients agree to all four happily when they read them at onboarding. They break all four when they have never been told.

Make it easy to say yes

Reduce the work of approving to something a busy client can do on a phone in two minutes. Include in the request: the post itself, the reason it exists, the exact deadline, the one-line change summary from the last round, and the two checks you specifically want their eyes on. "Please confirm the price and the launch date" gets a faster answer than "any thoughts?".

Handle the client who wants to be in every round

Some clients want to review everything. Give them the Observer role on Track A posts so they see everything without blocking anything, and reserve Approver status for Track B and C. Visibility satisfies the need for control; approval rights create the bottleneck. In practice, most clients accept this within a week once they realise they are seeing every post before it publishes.

Client approval checklist

• Single link to post, assets and schedule — no attachments anywhere
• Four-line approval contract included in onboarding and repeated per request
• Deadline written as a date and time in the client's own time zone
• Specific checks named in the request instead of an open invitation to comment
• Observer role for visibility, Approver role reserved for risk
• Expired approvals rescheduled automatically with a note to the client

Measuring whether approval is actually working

Five numbers, reviewed monthly, tell you whether the workflow is helping or merely documented.

• Median time from submission to decision. The headline number. Track it per track — Track A should be measured in hours, Track C in days.
• Revision rounds per post. Anything above an average of two means the rubric is unclear or the wrong people are reviewing. Teams that introduce categorised feedback typically see rounds fall from around three or four to between one and two within a month.
• Approvals that expired rather than completed. Every expiry is a missed opportunity; a rising count means your deadlines are unrealistic or your approver is over-subscribed.
• Posts published without recorded approval. This number should be zero. Any non-zero value is a hole in the process, not a one-off exception.
• Percentage of posts in each track. If more than a quarter of your output lands in Track C, your assignment test is too broad and you are slowing everything down.

The questions to ask in the monthly review

Numbers explain what happened; these three questions explain why.

• Which post waited longest, and what exactly was it waiting for?
• Which reviewer generated the most rounds, and were their comments blockers or preferences?
• Which approval was most valuable — the one that caught a real error before publishing?

That last question matters more than it looks. If nobody can name a save in the last month, your approval step is ceremony rather than protection, and it is worth asking whether Track A could be reduced to a self-check.

Tie it back to speed of publishing

Compare publishing volume against approval time over a quarter. The pattern you are looking for is flat or rising volume with falling approval time. If volume fell alongside approval time, you have not become more efficient — you have become less ambitious, and the approval process may be quietly discouraging the riskier ideas that made your feed worth following.

Rolling the workflow out in PostHub

A practical sequence for a team of three to ten, sized to complete in about two weeks.

1. 1Day one. Name your four roles in writing, including the backup approver for each track. Everyone should be able to state their role from memory by the end of the day.
2. 2Days two and three. Create the six states and the three tracks in the workspace, with the SLA hours attached to each track. Keep the configuration boring — no custom fields beyond owner, approver, track and deadline.
3. 3Days four and five. Write the review rubric as a six-line checklist your reviewers can keep open beside the queue, and define what a blocker means in your own words with two real examples.
4. 4Week two, day one. Run a rehearsal: take five live posts through the whole lifecycle, including one deliberately bad one that must come back with a categorised rejection.
5. 5Week two, day two. Invite your client or executive stakeholders with Observer access first, and send the four-line approval contract with their first real request.
6. 6Week two, day three onward. Turn on deadline notifications and automatic reassignment to the backup approver. From here the process runs itself; your job becomes watching the five metrics.

PostHub puts the draft, the review queue, the comments and the publishing slot in the same place, so nobody has to reconstruct which version is current — you can see how the pieces fit on the PostHub overview, and the pricing page shows how many approvers and reviewers each plan supports before you commit.

The first month: what to expect

• Week one: approval time gets slightly worse. Everyone is learning states, and old habits in chat still run in parallel.
• Week two: chat requests drop sharply once people see the queue is faster than asking. This is the moment to stop answering approval requests in chat — redirect each one to the queue, politely, every time.
• Week three: revision rounds fall as reviewers internalise blocker versus preference. Writers start submitting with change notes without being asked.
• Week four: review the five metrics. Expect median approval time to have halved and expiry rates to be approaching zero.

The redirect discipline in week two is the whole ballgame. The workflow only wins if approval requests stop having anywhere else to live.

Key takeaways

• Approval threads fail because the request has no home, no owner, no deadline and no definition of done — all four are structural, not personal.
• Use four roles only: owner, editor, approver, observer, with exactly one approver per post and no self-approval.
• Give every post six states with logged transitions; approved posts lock, and edits force a return to draft so versions cannot fork.
• Reviewers work a fixed six-check rubric in order — accuracy, brand, risk, craft, mechanics, timing — and label every comment blocker or preference.
• Feedback must point at the fix, arrive in one batch, carry a category, and end with a definition of done.
• Set three SLAs with stated working hours and automatic escalation to a backup approver; silence must never mean approval.
• Split output into three risk tracks so routine posts clear in hours while sensitive posts get a second approver and a 24-hour freeze.
• Measure median approval time, revision rounds, expiries, unapproved publishes and track distribution — and review them monthly against publishing ambition.

FAQ

How many people should be able to approve a post?

Exactly one. Two simultaneous approvers is the single most common cause of stalled approvals, because each waits for the other and neither owns the decision. If a post genuinely needs two signatures — legal plus brand, or client plus internal lead — run them in a written sequence with named order and a deadline on each step. Committees produce consensus slowly and accountability not at all.

What should I do when the approver simply does not respond?

Escalate on a timer rather than by asking nicely in a chat. Reassign to a named backup after the deadline passes, notify the original approver with the specific blocked slot, and if there is still no answer by the end of the next working day, reschedule the post and log the miss. Never publish unapproved content to protect a calendar slot, and never treat silence as consent — those two rules are what make the deadline credible.

Is approval overkill for a solo creator with no team?

For publishing, yes — you are both writer and approver. What is not overkill is a self-review rubric and a delay. Save the post, step away for at least thirty minutes, then read it once against six checks: facts, voice, risk, craft, mechanics, timing. Solo creators get the same benefit from the structure as teams do; they simply apply both roles to themselves with a gap in between.

How do I stop clients from sending feedback over WhatsApp and email?

Make the link the only place feedback counts. Every time a client sends a comment elsewhere, reply with a one-line nudge: "Noted — can you drop that on the post link so it stays attached to version two?" After three or four nudges, most clients shift. Back this up at onboarding with the four-line contract stating that only comments on the post are considered, and make it genuinely easier to comment in place by naming the two specific checks you want from them.

What if reviewers disagree with each other?

The approver decides; reviewers advise. Record both opinions as preferences on the post so the disagreement is visible rather than argued in private, and let the single approver choose. If the same two reviewers disagree more than twice a month, the disagreement is really about the rubric or the voice brief — fix the document they are both reviewing from, and the disputes stop recurring.

When should we freeze a post before it publishes?

Twenty-four hours before publication for anything in the critical track: launches, pricing, crisis responses, legal or regulatory content, and anything touching a sensitive cultural moment. During the freeze, edits require an explicit unlock with a comment from the approver. Freeze routine posts too if your stakeholder pattern is late-stage objections — the small friction of a lock is far cheaper than an eleventh-hour scramble through three versions.