The social media approval template.
This is the approval system we install on accounts we manage, written down so you can install it yourself: the roles, the stages, the risk lanes, the turnaround rules, and the exact sheet we run approvals through with clients. Slow, messy approvals are where good social goes to die. The fix is not more meetings; it is a process where every hat has a name and every yes has a clock.
The four roles
On a small team one person wears several hats. The point is that every hat has a name.
Every managed account we run has one named lead. Not a team, a person. The same rule applies to every role here: the moment two people share the final yes, nobody owns it, and the post waits while each assumes the other is on it.
Agree the autonomy level in advance. Decide, in writing, what can be published without asking: which formats, which topics, which surfaces. Approval processes collapse when every post is treated as a special case.
Our channel management scopes name a single dedicated lead for the account, and include a line we consider load-bearing: where we are expected to act independently, the level of autonomy and any required guardrails are agreed in advance. One sentence, settled before the first post, and the who-approved-this conversation never needs to happen.
- Creator: writes and makes the post (copy, design, video)
- Reviewer: checks brand, accuracy and, where needed, legal or compliance
- Approver: gives the final yes. One named person, not a committee
- Publisher: schedules, posts, and does the post-publish check
The stages
Keep it linear. Every extra loop is a day lost.
Treat the pre-publish review as a real job, not a favour. On accounts we manage, reviewing finished content before posting is a named service line: formatting checked per platform, platform-specific requirements confirmed, brand and tone consistent, links and tags in place. Errors die in that step or they go live.
Close the loop after publishing. The publish-and-check stage exists because the post that goes out is not always the post that was approved: crops shift, links break, tags drop. Two minutes of checking protects the whole chain of work before it.
For one professional sports account we support, review-before-publish is written into the contract as its own scope item, separate from copywriting and planning. Making it a named responsibility rather than an assumed courtesy is why high-volume weeks ship without the error rate rising with them.
- Draft: creator builds the post against the brief and content pillar
- Internal review: reviewer checks it within the agreed window
- Edits: one consolidated round of changes, not endless ping-pong
- Final sign-off: the approver gives a clear yes or no
- Schedule: publisher queues it for the planned slot
- Publish & check: confirm it went live correctly (links, tags, formatting)
What "approved" should mean
Agree this once so a yes always means the same thing.
Make approval a per-post fact recorded in one place, not a feeling spread across chat threads. A binary status column beats a comment thread: the post is approved or it is not, and anyone can read the state of the whole pipeline at a glance.
Give the approver everything in one row: the draft or live link and the source file. Every extra click between the approver and the content adds a day to the turnaround.
For one Show network we manage, re-use approvals live in a single shared sheet: one row per story, a link to the post, a link to the source file, and a true/false approval column the client flips. No screenshots in group chats, no digging through DMs. The approval state of the entire pipeline is readable in five seconds.
- On-brand: voice, look and tone are unmistakably yours
- Accurate: claims, stats, names and prices are correct
- Compliant: anything regulated has the right sign-off
- Complete: links work, accounts are tagged, captions and alt text are in
- Right time: it fits the calendar and nothing clashes
Set turnaround times
Most approval pain is not the steps, it is that nobody agreed the clock.
Set the review window when you set the process, put it in writing, and treat silence past the deadline as a nudge to the named backup, not a stall for the post. The steps are rarely the problem; the missing clock is.
Then protect the fast lane. Reactive content is a different product with a different shelf life, and it cannot queue behind a sponsor post that has been in review since Tuesday.
The blunt version we give audit clients: if you are more than 24 hours late to a news moment, every competitor has already covered it and your entire audience has already seen it somewhere else. An approval process that cannot clear a reactive post inside a working day is not slow, it is deleting a content lane.
- Agree a standard review window (e.g. 24 working hours) and hold to it
- Cap edit rounds at one or two so posts do not loop forever
- Silence past the deadline is a nudge, not a stall
- Give time-sensitive or reactive posts a documented fast lane
- Name a backup approver for when the main one is away
Risk-tier the approvals
One queue for everything means risky posts move too fast and safe posts move too slow.
Not every post deserves the same scrutiny. Planned evergreen content, reactive content and sensitive content are three different risk profiles, and they need three different lanes with different sign-offs and different clocks.
Write the escalation route down before you need it: who gets pulled in when a post touches something sensitive, who signs off, and who has the authority to pull a live post. If the answer lives in someone's head, it is not a process, it is a dependency.
Scoping community management for a football club, our recommendation was explicit: separate approval workflows for lower-risk and higher-risk activity, with written response guidelines, tone of voice rules, and escalation routes for sensitive or abusive matters. A match-day reply and a statement-adjacent post do not belong in the same queue; pretending they do slows one and endangers the other.
- Planned, reactive and sensitive content each have their own lane and clock
- Pre-approved formats exist, so routine posts skip the queue entirely
- The escalation route for sensitive topics is written down and named
- Someone has explicit authority to pull a live post, and everyone knows who
- Response guidelines and tone rules exist for comments, not just posts
Put the process in a tool, not a thread
Approvals die in DMs. Boards keep them honest.
Run the whole pipeline in one tool the team already opens daily, with one card per post carrying its owner, stage and date. The board or sheet is the single source of truth; chat is for conversation, not state.
Make chasing a named job. Boards do not keep themselves honest: on managed accounts, checking that cards exist, sit in the right columns and are not quietly overdue is part of someone's actual role. And tag what you publish, so reporting and the next planning cycle read straight off the same system.
On one account we manage, the unglamorous parts are contracted by name: creating the cards, checking tasks sit in the right sections, chasing incomplete content through the board, and tagging published posts so reporting stays clean. It sounds administrative. It is the difference between a calendar the team genuinely uses and a document nobody opens.
- One board or sheet is the single source of truth for every post's status
- Every post is a card with an owner, a stage and a date
- Chasing overdue items is a named responsibility, not a hope
- Published content is tagged, so reporting reads straight off the system
- The calendar, the approvals and the assets live in the same place
Different risk, different clock.
Steal these as defaults and adjust to your team. The point is not the exact hours; it is that every lane has a clock and a named sign-off, agreed before anything enters the queue.
The approval sheet we actually use.
This is the real structure of a sheet we run with a client, generalised. One row per post. The binary status column is the whole trick: approval becomes a visible fact, not a vibe in a chat thread.
Installing it without stopping the feed.
You do not need an offsite. Map what actually happens today, name the hats, then tighten. The feed keeps running while the process forms around it.
Map and name
Write down the path a post actually takes today, including the informal detours. Name the four roles against real people, including the backup approver. Pick the tool the pipeline will live in: the one the team already opens daily.
Set the clocks
Agree the review windows and the edit-round cap with the people who have to honour them. Build the board or sheet, one card per upcoming post, and move this week's content through it end to end.
Add the lanes
Define the reactive fast lane and pre-approve its formats. Write the escalation route for sensitive content. Then review the month: every post that missed its slot gets a one-line reason, and the process, not the people, gets the fix.
The process is the easy part.
This is genuinely the system we install on accounts we manage. Copy it, rename the roles to match your team, and it will work: most approval pain disappears the week the clocks and the hats get names.
What the template cannot do is hold the line in week six, when a launch is landing, the approver is travelling and someone senior wants one more small change after sign-off. Keeping the board honest under pressure is a job, not a document. We know, because on several accounts it is literally our job.
So install the process. And if you would rather someone else kept it honest, match days included: that is the service.