How to build a social media approval workflow clients actually use
Most approval problems are process problems wearing a client’s face. The client isn’t slow because they don’t care; they’re slow because the post arrived as an attachment in a thread with nine other messages, with no clear question and no deadline.
A good approval workflow fixes the channel, not the client. What follows is a process that works whether you manage two brands or forty: who approves, what you agree before the first post, how to send work for review, what a decision looks like, how to run revision rounds, and what to do when the process breaks. The emails are written out so you can copy them.
What an approval workflow is
A social media approval workflow is the agreed path a post takes from draft to published: who writes it, who reviews it, what answers the reviewer can give, how long they have, and what happens at each answer. It exists so that every post that goes live has been seen and accepted by someone with the authority to accept it, and so that you can prove it afterwards.
The workflow is not the tool. A tool can enforce one, but if nobody has agreed the rules, software just moves the confusion somewhere tidier. Settle the rules first, then pick the channel that makes them easy to follow.
1. Decide who approves — and who doesn’t
Write down, per client, the one or two people whose yes actually counts. More approvers means more opinions and slower decisions; if legal or a founder must see everything, make them the approver rather than a silent CC who surfaces with objections after the post is live.
Separate the people who make the content from the people who approve it. A creator signing off their own work is not a review, and it is the first thing that goes wrong when a deadline is tight.
| Role | What they do | Can approve? |
|---|---|---|
| Creator / editor | Writes captions, prepares media, schedules posts | No — never their own work |
| Account manager | Checks quality before sending, chases decisions, acts on feedback | Only on the client’s behalf, when the client confirms |
| Client approver | Reviews each post and decides | Yes — this is their job |
| Client stakeholder | Legal, product or leadership with a view | Only if named as an approver; otherwise feeds the approver |
The last row is where most workflows quietly fail. If three people at the client each think they are the approver, you will get three answers. Name one, and ask the client to collect their colleagues’ views before deciding.
2. Agree the rules before the first post
The best time to set expectations is when you sign the client, not the first time a post is late. Put the approval terms in the proposal or statement of work, in plain words, so that nobody is negotiating turnaround in the middle of a launch week.
Four things need agreeing: how quickly the client will answer, how many revision rounds are included, what counts as an approval, and what happens to a post nobody answers.
Content approval • We will send each month’s posts for review together, at least 10 working days before the month starts. • Please review within 3 working days. Each post can be approved, sent back with requested changes, or rejected. • Two rounds of changes per post are included. Further rounds, or new posts requested after sign-off, are scheduled into the following month. • Only a decision recorded in the review link counts as approval. We can record approvals you give us by phone or in a meeting, and we will note that we did so. • Posts not approved 24 hours before their scheduled time will not publish. We will reschedule them with you.
Edit the numbers to fit your retainer; what matters is that each rule is specific enough to point to later.
3. Send batches, not drips
Sending posts one by one trains clients to answer one by one — which means a week of interruptions for them and a week of chasing for you. Plan a month (or a fortnight), then send it for review as one batch with one message and one due date.
- One review request per batch, not per post
- A clear due date in the request itself
- Posts shown as they will appear on each network, not as a caption in a cell and an image in a folder
- The month’s goal at the top, so the client judges each post against it
Subject: [Brand] — May posts ready for your review Hi [Name], May’s posts are ready: 14 posts across Instagram and LinkedIn, built around this month’s goal of filling the June workshop. Please review them here by Thursday 24 April: [review link] For each post you can approve it, request changes (tell us what to change) or reject it. Anything still waiting 24 hours before its slot won’t publish, so Thursday keeps the whole month on track. Thanks, [Your name]
Notice what the email doesn’t do: it doesn’t attach anything, doesn’t paste captions, and doesn’t ask “any thoughts?”. It names the batch, the goal, the deadline and the three possible answers.
4. Give exactly three answers
Every post needs an unambiguous state. Three answers cover everything a reviewer means:
- Approve — it can publish as it stands
- Request changes — close, but fix this (with a note saying what)
- Reject — this post shouldn’t run at all
“Looks good but maybe the image?” is not an answer. If your tool lets a reviewer say something that isn’t one of those three, you will spend the next day interpreting it — and if you guess wrong, the post that goes live is one nobody actually approved.
The difference between the last two matters. Requested changes send a post back to the team with instructions and it returns for another look; a rejection removes it from the month. Clients who only have “approve” and “comment” tend to reject by commenting, which leaves the post sitting in limbo.
5. Put a deadline on every decision
Approvals without a deadline expand to fill the time before publishing — and then some posts go out unreviewed, or don’t go out at all. Two deadlines do the work: one for the batch, and a hard cut-off per post.
| When | What happens |
|---|---|
| 10 working days before the month | The month is sent for review as one batch |
| 7 days before | Review due — first-round decisions are in |
| 5 days before | Changes made and sent back for a second look |
| 3 days before | Second-round decisions due; the month is locked |
| 24 hours before each post | The approval window closes: an undecided post will not publish |
Decide in advance what happens when the window closes. The safe default is that an unreviewed post does not publish; it is marked expired and can be rescheduled. Publishing it anyway teaches the client that review is optional — and makes you responsible for a post nobody signed off.
Hi [Name], A quick reminder that May’s posts are due for review tomorrow. 9 of 14 are decided — the 5 still waiting are the first ones to go out, starting 2 May. [review link] Thanks!
Send one reminder, not a series. Name how many posts are waiting and when the first of them goes live — a specific consequence gets an answer faster than a polite nudge.
6. Keep feedback on the post
Revision rounds get long when feedback is detached from the thing it is about. Keep comments attached to the specific post — and, for a carousel, the specific slide — so the fix is obvious and the history is in one place.
Help the client give useful feedback by showing them what useful looks like. A change request should say what to change and, ideally, why. The client feedback guide covers decoding the vague ones.
| Unhelpful | Useful |
|---|---|
| “Not sure about this one” | “The offer ends on the 14th, not the 15th — please fix the date” |
| “Can we make it pop more?” | “Use the orange product shot from the April shoot as the first slide” |
| “Change the caption” | “Drop the second paragraph — legal don’t want us naming the competitor” |
Keep a separate, private place for the team’s own notes. Client-facing feedback and internal shorthand should never share a box — “they always change the second slide, don’t bother polishing it” is the kind of note that ends up in front of the client when everything lives in one thread.
7. Limit revision rounds
Unlimited rounds sound generous and turn into unpaid work. Two rounds per post covers almost every genuine fix; beyond that, a post usually needs a different brief rather than another edit.
- Round one: the client’s first reaction, with change requests
- Round two: the fixed version, checked against those requests
- Anything after that: a new post, moved to a later slot or the next month
Resubmitting a changed post should put it straight back in front of the approver without another round of emails — they already know the month is under review.
8. Plan for the exceptions
Every workflow meets the same few awkward cases. Decide how you handle them now, not in the moment.
The client approves on a call
Record the decision against the post and note that you did it on their behalf, with the date. The post is approved, and the record says honestly who clicked. Don’t let “they said yes on the call” live only in someone’s memory.
Something changes after approval
A price changes, an event moves, a product is delayed. An approved post that is no longer true has to go back for review — unlock it, fix it, and send it again. Never edit an approved post and publish it quietly; the client approved the old version.
A reactive or urgent post
News that can’t wait for next month’s batch still needs a yes. Agree a fast lane: one named person who can approve same-day, and a shorter window for those posts only.
The client goes silent
The window closes and the posts expire, as agreed. Then send a short note listing what didn’t go out and offering new dates. The first time this happens, it is usually the last.
9. Record who decided
When a post causes a problem, the first question is who approved it. Keep a log of every decision with the person and the time — approvals, change requests, rejections and anything that expired. If your team records a decision on a client’s behalf, the log should say so.
The record protects both sides. The client can see exactly what they signed off; you can show that a post went live because it was approved, not because it slipped through.
The workflow on one page
- 01Name one or two approvers per client, and keep creators out of the approver role
- 02Put turnaround, revision rounds and the no-answer rule in the proposal
- 03Plan the month, then send it for review as one batch with a due date
- 04Show each post as it will look on its network
- 05Let reviewers answer each post with approve, request changes or reject
- 06Keep feedback on the post and team notes in a separate, private place
- 07Allow two rounds, then move further changes to a new slot
- 08Close each post’s window before its slot: undecided posts don’t publish
- 09Keep a record of every decision, including ones made on the client’s behalf
None of these steps needs special software, but each is much easier when the channel enforces it. That is what client approvals are built to do: one review link, three answers per post, an optional deadline and a full history.