Social Media Content Approval Process: Stages, RACI, and Evidence

A complete approval process answers five questions. What are the stages from request to confirmed publish? Who is responsible, accountable, consulted, and informed at each stage? What evidence must exist before an item may move forward? Which edits invalidate an earlier yes? How are holds, exceptions, and crisis overrides recorded so they do not become invisible shortcuts?

This document is distinct from nearby PostTempo guides. The approval workflow page is the product-oriented setup guide. The content review checklist is the quality pass inside a stage. The campaign brief is the request that starts the work. The scheduler API guide explains how programmatic drafts still enter these stages. The account handoff checklist transfers open approvals when people change. This process is the operating agreement those documents point at.

Editorial recommendation: separate editorial approval from platform permission. Being allowed to post on a Page is not the same as being the person accountable for the message. A process that confuses the two will either block the only person with a password or let anyone with access publish unreviewed work.

Product observation: implemented approval states are more reliable than approval by chat reaction. A state can block scheduling. A chat reaction cannot, unless someone copies it into the state by hand and even then the revision may have changed.

Worked calculation (fictional): a team publishes 30 posts in a week. If approval is a comment on version 1 and the caption is edited twice afterward, the team has 30 comments and an unknown number of approved revisions. The process instead stores one approval per revision. Edited items return to review. The count of true approvals may be lower. The count is honest.

Use the smallest stage list that still prevents the failures you have actually seen. A practical default is: requested, drafting, in review, changes requested, approved, scheduled, published, and held. Canceled is a closing state, not a review state. Failed publish is an operations state after approval, not a reason to pretend the approval never happened.

Requested means a brief exists: audience, destination accounts, due time, offer or claim if any, and owner. Drafting means a human or an approved intake path is producing a revision. In review means the accountable approver has something complete enough to judge. Changes requested means the item is back with the drafter and the previous approval, if any, is void. Approved means this revision may be scheduled. Scheduled means a time and destination are set. Published means a platform result exists, not merely that a job was queued.

Editorial recommendation: do not add a stage you will not staff. Legal review, accessibility review, and community review can be checks inside the in-review stage rather than separate queues, until volume forces a split. A stage without an owner becomes a parking lot.

Product observation: calendar placement and publishing status should reflect these stages instead of replacing them. An item can be on a calendar as a planned slot while still in drafting. Putting it on the calendar is not approval. Marking a job queued is not proof it published.

Worked calculation (fictional): Brightroom's default path has six active stages before publish. A simple caption with no offer, no partner, and no location price skips the specialist consult and still passes the same approval state. The skip is recorded as not required, not as silently missing. The record matters when someone later asks why legal did not see it.

RACI means responsible, accountable, consulted, and informed. Responsible is the person doing the task. Accountable is the single person who answers for the decision. Consulted people contribute before the decision. Informed people hear the outcome. If two people are accountable, nobody is.

A social RACI often fails by naming a department instead of a role. Brand, legal, and the client are not roles you can ping at 4:50 p.m. Name the role and the backup: drafter, editor, brand approver, offer approver, publisher, and on-call. A person may wear two roles on a small team. The chart should still show both hats so a vacation does not erase one of them.

Sourced fact: Meta Business Help explains business portfolio permissions and adding people to a portfolio with access to specific assets such as Pages. That is an access RACI of a different kind. Portfolio admin, content access, and editorial accountability can be three different people. Write both maps. The person who can press publish in the native tool is not automatically the accountable approver.

Editorial recommendation: the accountable approver for ordinary posts should be someone who can decide inside the coverage window. Escalating every caption to a founder who travels creates shadow approvals, where a producer posts because the deadline moved and the founder did not. Shadow approvals are the failure the RACI is meant to stop.

Worked calculation (fictional): Helio Optical names the central editor as responsible for drafting, the store manager as accountable for local price and hours, and the brand lead as accountable for voice and offers that run in more than one store. Consulted includes a teammate who checks alt text. Informed includes the store team after scheduling. One post therefore has two accountable decisions, but each decision has one owner. The post cannot schedule until both decisions are recorded.

Evidence is the packet you can open later without asking the approver to remember. At minimum store revision id, destination accounts, caption, media identifiers, alt text or a decorative decision, intended publish time with zone, disclosure status, approver identity, approval time, and the checklist result. If a field is not required, store not required rather than leaving it blank.

The content review checklist is the practical list of quality checks. This process says when that checklist is mandatory and what happens to the result. A checklist completed against an older revision is not evidence for the current one. Tie the checklist result to the revision id.

Editorial recommendation: keep evidence next to the post, not in a side folder of screenshots. Screenshots go stale, crop out the time zone, and rarely show who clicked. They can supplement a record. They should not be the record.

Product observation: approval history, media validation, and publishing status are useful evidence when they remain attached to the item after publish. A report that only says 30 posts went out cannot answer which revision a store manager approved.

Worked calculation (fictional): a customer asks why a 20 percent line appeared on a Tuesday post. The record shows revision 4, approved by the store manager at 16:10 local, with the offer text in the caption hash, and revision 3's different price marked changes requested. The team can explain the path. They still may need to correct the post. The record does not make the price correct. It makes the decision traceable.

Approval that only checks brand voice will miss the fields that create real harm: an offer the store cannot honor, a paid relationship the audience cannot see, and an image with no alternative. Put those checks on the same pass as voice, or name them as consulted checks with a recorded result.

Sourced fact: the FTC publishes the rule on use of endorsements and testimonials in advertising, a business-guidance FAQ titled FTC's Endorsement Guides: What People Are Asking, and Disclosures 101 for Social Media Influencers. Those are the primary public references when a checklist asks whether a material connection, such as a paid or gifted mention, is disclosed in a way people can notice. Read the current pages. An internal approval note is not a disclosure to the audience.

Sourced fact: WCAG 2.2 Success Criterion 1.1.1 requires text alternatives for non-text content presented to users, with listed exceptions. The W3C image alt decision tree is a practical aid for deciding what alternative an informative image needs and when an image is decorative. Social networks are not a web page you fully control, but the approval packet can still require an alternative before schedule.

Sourced fact: Meta's Transparency Center publishes Community Standards that govern what is allowed on its platforms. An approved brand caption can still conflict with those standards or with a network's branded-content tools. Approvers should know that platform rules are an external constraint, not a box the brand can waive.

Editorial recommendation: if a post includes a price, a deadline, a health-adjacent line, or a partner, require the accountable owner for that fact to approve the exact words. Paraphrases in a review comment are how the live caption drifts.

Worked calculation (fictional): Lena's partner post includes a gifted product. The approval packet has disclosure text in the first lines of the caption, a note that the partner required the gift to be mentioned, and alt text for the product photo. She does not bury the disclosure in a hashtag group. No legal conclusion is drawn beyond the operational rule: the audience-facing caption contains the disclosure, and the revision id matches.

A hold stops scheduling without deleting the work. Use it when facts are unfinished, a partner has not responded, or a claim needs a source. A hold has an owner, a reason, and a review time. An item on hold is not approved and not rejected. Leaving it in approved because the calendar looks empty is how unfinished offers publish.

An exception is a written, temporary change to the path. Example: a store may schedule weather-closure posts without the usual brand queue, using a pre-approved sentence, until the end of the day. Exceptions need an expiry. When the expiry passes, the old path returns. If you need the exception again, write it again.

A crisis override is rarer. The crisis response plan should name who may publish a holding statement, which accounts, and how the statement is reviewed after it is live. Approval process and crisis process must point at each other so producers do not invent a third path in the moment.

Editorial recommendation: do not encode forever exceptions. A client who is always allowed to skip review is not an exception. Change the RACI. Pretending the strict process still exists will fail the first audit of the evidence packet.

Product observation: states such as held, approved, and scheduled make overrides visible. A published crisis post should still receive an after-action record: who posted, which revision, and what was corrected later.

Worked calculation (fictional): Brightroom grants a 12-hour exception for a client event. The exception names two accounts, one approver who is on site, and an end time of 22:00 local. Three posts go out under that exception and are tagged exception in the log. At 22:01 the path reverts. A fourth post drafted at 22:20 waits for the normal approver. The story is boring, which is the goal.

An approval SLA is the response time the accountable person owes, measured in their coverage window. It is not a promise that the audience will see the post at a lucky hour. Example language: brand approver responds within four business hours on weekdays from 09:00 to 17:00 in the system-of-record zone. Outside that window, items wait unless an exception says otherwise.

Coverage and timezone planning belong together. A destination local morning may fall outside the approver's day. Either move the approval earlier, staff a backup, or tell the requester that the slot is not staffed. The multi-timezone SOP is the right companion when destinations do not share a clock.

Handoffs fail when they transfer the calendar and forget the open reviews. The handoff packet should include items in review, items on hold, items approved but not scheduled, the RACI, and the exception log. A new producer who cannot see why something is held will either stall or publish it.

Editorial recommendation: measure the process with counts you can collect without a new analytics project. Aging items in review, number of approvals invalidated by edits, holds older than the review time, and publishes with missing evidence are enough. Do not invent a cycle-time benchmark and call it industry data.

Product observation: approval queues and publishing status make aging visible. A weekly 15-minute review of anything older than the SLA beats a quarterly process workshop that restates the RACI.

Worked calculation (fictional): Brightroom's Friday QA finds 4 items in review older than the SLA, 1 hold without a review time, and 2 approved items whose captions changed after approval. They fix the hold, return the 2 edited items, and reassign the aging items to the backup approver. No claim is made that this raised engagement. The claim is that Monday's calendar matches approved revisions.

Fictional scenario: Lena Ortiz is a solo illustrator in Denver. A stationery brand asks for three posts over two weeks in exchange for products and a fee. Lena wants a record she can show the brand without turning her studio into an agency. Her destinations are one Instagram professional account and one Facebook Page, both hers.

Lena's stages are requested, drafting, in review, approved, scheduled, and published. She is responsible for drafting and accountable for her own voice. The brand partner is accountable for product facts and for confirming the disclosure sentence they require. Lena will not schedule until both yeses are on the same revision. She uses the content review checklist for spelling, alt text, and the disclosure placement.

Editorial recommendation: partnership work is where solo creators most need a process, because the other party remembers a different caption. Email approval of a PDF that does not match the scheduled text is a common miss. Lena pastes the final caption into the approval note and schedules only that revision.

Worked calculation (fictional): the brand approves revision 2, then asks to add a sale code. Lena creates revision 3, clears the earlier yes, and waits one business day. Two posts publish on revision 3. The third is held because the code expired. The hold reason is stored. She does not quietly swap the code after approval. She does not claim the process increased affiliate income. The posts are illustrative.

Product observation: even a one-person calendar benefits from revision-based approval when a partner is involved. The partner does not need a seat in every tool if the evidence packet can be exported or read back in a status note.

Lena keeps platform access to herself. The brand is consulted and accountable for product facts, not granted her passwords. That split is the whole RACI.

Fictional scenario: Brightroom Agency manages six retainers. Each client has a different appetite for review. Some want to approve every post. One wants a weekly batch. One wants only posts with offers or faces of employees. Brightroom refuses to keep those preferences in separate inboxes. Each workspace has a RACI and a stage list stored with the calendar.

Producers are responsible for drafts. A Brightroom editor is accountable for voice and for sending the batch. The client approver is accountable for claims about the client's business. A producer may not mark the client decision complete based on a meeting memory. If the client approves in a meeting, the editor records the revision ids in the scheduler before anything is scheduled.

Editorial recommendation: batch approval needs a freeze time. After the freeze, new ideas wait for the next batch unless an exception is open. Otherwise the batch is a fiction and producers chase comments across two tools.

Worked calculation (fictional): Client North's weekly batch contains 8 posts. The client approves 5, requests changes on 2, and holds 1 for a price. Brightroom schedules only the 5 whose revision ids match the approval. The 2 return to drafting. The hold has a Thursday review time. Status to the client lists those three outcomes in plain language. No vanity metric is attached.

Product observation: per-workspace approval and a visible queue let an agency run different RACIs without inventing a new process per producer. The common rule is evidence. The local rule is who must say yes.

Brightroom's monthly note includes counts of approved, changed, held, and published items per client, plus any exception still open. It is an operations note, not a performance case study.

Fictional scenario: Helio Optical has three stores, each with a Facebook Page and an Instagram professional account. A central marketer drafts hiring posts and frame-collection announcements. Store managers are accountable for local hours, prices, and whether a promotion is actually available in that store. The brand lead is accountable for anything that runs in all stores with the same words.

Helio splits shared creative from local facts. The same photo may be reused. The caption's price line may not. Each destination is its own approval. A manager who approves the downtown price has not approved the airport price. The central marketer is responsible for routing and for checking alt text. Managers are not asked to become designers.

Editorial recommendation: multi-location approval should show destination local time and the local fact on the same screen as the yes. Asking a manager to translate headquarters time and a shared caption under deadline produces the wrong store's hours.

Worked calculation (fictional): a weekend frame offer is drafted for all three stores. Two managers approve revision 2. The third requests a different end date. That destination stays in changes requested while the other two are scheduled for 10:00 local on Saturday. The central calendar shows three rows, not one national yes. No sales lift is claimed for the Saturday time. It was chosen because managers can still answer questions that morning.

Product observation: account-level approvals and handoff history matter when a manager is out. The backup must see the open revision, not a screenshot of last month's grid.

Helio records a limit in every packet: posts are retail announcements, not vision-care advice. If a caption drifts into a medical claim, the item is held until the words are removed. The process does not replace professional or regulatory advice.

Approval fails in isolation. The brief should state destinations, facts that need an accountable owner, and whether a partner or offer is involved. The review checklist should be the in-review tool. The API guide should force programmatic drafts into the same stages. The reporting template should count decisions and publish results without pretending approval caused a metric to move.

If those documents disagree, fix the process page they all point to rather than editing one template in private. A brief that says the client approves offers, and a scheduler workspace where producers self-approve, is a broken pair.

Editorial recommendation: add one approval appendix to the operating set: stage list, RACI, evidence fields, SLA, and exception rules. Link it from the brief, the checklist, the handoff, and the monthly report. Do not paste a different summary into each doc.

Product observation: when briefs, approvals, calendars, and publishing status live in connected states, the appendix has a place to be enforced. A spreadsheet RACI that never meets the queue will drift.

Worked calculation (fictional): a monthly report says 80 items requested, 64 approved, 10 changed, 6 held, 60 published, 4 failed and retried. The gap between approved and published is explained by holds and failures, not hidden. Hour-of-day charts are not used as proof that the process worked.

Use this sequence before you add more approvers. Extra approvers feel safe and often add delay without evidence.

Beginner path: write six stages, name one accountable person for ordinary posts, require a revision id, run the review checklist, block scheduling until approval matches the revision, and record holds with a review time. Add a second accountable owner only for a class of facts you have already gotten wrong, such as prices or partner disclosures.

Editorial recommendation: run the checklist on real posts for two weeks before you customize it. The first customization should remove a field nobody can fill, not add a field that sounds mature.

Product observation: a workspace with real approval states gives this checklist a home. Whether you use PostTempo or another stack, the requirement is the same: the yes, the revision, and the destination must be stored together.

Worked calculation (fictional): a beginner team of two spends one working session writing the RACI and then approves the next ten posts under it. Three are sent backward because captions changed after the yes. That friction is the process working. No cycle-time industry benchmark is claimed.

Methodology: the PostTempo Editorial Team drafted this process by comparing approval failure modes with implemented approval, calendar, media validation, and publishing-status workflows, then aligning the structure to existing operations posts. Public references from the FTC endorsement rule and guidance pages, Disclosures 101, WCAG 2.2 non-text content, the W3C image alt decision tree, Meta Community Standards, and Meta Business Help on portfolio permissions were used for orientation. Scenarios and counts are fictional.

What this article does not do: it does not say that any approval design is legally required. It does not interpret the FTC guides for a specific post. It does not rank agencies or tools. It does not promise faster teams, higher engagement, or fewer crises. It does not replace the crisis plan, the review checklist, or counsel.

Professional limits: confirm who may bind your organization before you name them accountable. Confirm platform permission models before you assume a scheduler role matches a Page role. Keep a human decision on claims, offers, disclosures, and accessibility alternatives. Re-read primary sources when a campaign is sensitive.

Editorial recommendation: revisit the RACI when a launch misses, when an edit publishes after approval, or when a person leaves. Those three events teach more than a blank template.

Product observation: PostTempo's approval workflow materials and implemented review states can hold the stages described here. They do not supply judgment, and they do not make a caption true.