The five states
- Brief: source, reader, job, proof, platform, product boundary, owner.
- Drafted: each destination has its own editable version and validation state.
- In review: factual and editorial questions are visible; no silent assumptions.
- Approved and scheduled: exact version, account, date, time, and approver are recorded.
- Published or failed: delivery result remains attached to the draft and schedule.
Review in the right order
This order prevents a common waste: polishing a hook for a claim that should never have been approved. A failed truth or usefulness check sends the draft back with a reason, not a vague request to make it better.
1. Truth
Are the product facts, numbers, customer details, dates, and links correct?
2. Usefulness
Does the reader gain something before the product asks for attention?
3. Voice
Would the named author or brand actually say this in this rhythm?
4. Platform
Do format, community rules, media, length, and interaction goal fit?
5. Delivery
Are the account, schedule, link, media, and fallback owner correct?
Define decision rights
- Requester: supplies the source and the communication goal.
- Writer or AI system: creates variants without changing unverified facts.
- Fact owner: confirms product, legal, customer, or performance claims when needed.
- Editor: owns usefulness, voice, and platform fit.
- Approver: accepts the exact version and publishing context.
- Publisher: schedules, monitors delivery, and resolves failures.
Choose the right approval process for the risk
There is no responsible reason to route a routine educational post and a regulated customer claim through the same approval path. One process will be too slow for the first or too weak for the second. Classify the post before drafting, then apply the lightest workflow that still has the right decision owner.
The classification belongs in the brief. Changing the risk level after a draft is scheduled makes approval theater: the system records a green state without proving that the necessary person reviewed the necessary claim.
| Model | Use it for | Required decision | Common failure |
|---|---|---|---|
| Self-review | Routine founder education and low-risk build notes | A second-moment truth and usefulness check | Drafting and approval happen in the same sitting |
| Single approver | Product updates and ordinary brand content | One named owner accepts the exact version | A team is named instead of a person |
| Parallel review | Claims needing product and legal or security input | Every specialist reviews the same frozen version | Feedback lands on different copies |
| Sequential review | Regulated, contractual, crisis, or executive communications | Each stage has a distinct job and exit criterion | Extra stages are added without deadlines or authority |
Set deadlines, escalation, and version rules
A status without a time expectation is only a label. Give each approval stage a service level: when review begins, when the decision is due, what happens when the approver is unavailable, and whether silence blocks publication. Time-sensitive content should expire rather than drift into a later slot with stale facts or context.
Approval must attach to an immutable version. If a caption, image, link, destination, or scheduled time changes after sign-off, the changed fields must be visible and the affected checks must run again. A thumbs-up in chat is not useful evidence when nobody can prove which revision it referred to.
- Name one accountable approver per stage, plus a backup for absence.
- Set a review deadline and an explicit escalation path.
- Record approve, request changes, or reject—never infer approval from silence unless a documented standing rule permits it.
- Freeze the approved copy, media, link, account, and schedule as one version.
- Reopen only the checks affected by a later change, and preserve the prior decision history.
Use reasons, not red ink
Store rejection reasons as patterns. If the same issue appears repeatedly, improve the source, voice rule, or generation brief instead of paying the editing cost forever.
Weak feedback
Too salesy. Try again.
Actionable rejection
Rejected: the opening claims this is the fastest workflow without evidence, and the reader receives no usable idea before the product link. Keep the onboarding example, remove the superlative, and lead with the three-question test.
What automation may and may not do
- Safe to automate: collecting approved sources, generating variants, validation, reminders, scheduling an already approved version, and status monitoring.
- Requires judgment: company beliefs, sensitive claims, customer disclosure, crisis response, community relevance, and exceptions to a platform rule.
- Optional autonomy: recurring low-risk formats only after the workflow has a reliable history and a clear off switch.
Design the failed-post path before launch
A scheduled post is not finished when it enters a queue. Tokens expire, media fails validation, providers become unavailable, and community rules change. Failure handling is part of the publishing product.
- Keep the exact draft and media intact.
- Show the provider error in plain language.
- Identify whether to reconnect, edit, reschedule, or retry.
- Assign an owner and record the last attempt.
- Do not silently move a time-sensitive post to a later slot.
Measure whether approval is helping
The goal is not a larger count of approvals. It is fewer preventable errors without turning useful content into a queue. Review the process monthly and separate quality outcomes from speed outcomes so a fast workflow cannot hide mistakes and a safe workflow cannot hide avoidable waiting.
| Metric | How to calculate it | What it reveals |
|---|---|---|
| Median approval time | Time from review-ready to decision | Whether the normal path is predictable |
| Deadline breach rate | Late decisions divided by decisions due | Where ownership or capacity is unclear |
| Revision rounds | Change requests before final approval | Whether briefs and rejection reasons are improving |
| Post-approval change rate | Approved items edited before publishing | Whether approval happens too early |
| Preventable incident rate | Posts corrected or removed for issues the checklist covers | Whether the workflow protects the public account |
| False-friction rate | Low-risk posts escalated without a policy reason | Whether the process is heavier than the risk |
The approval checklist
- Source attached and current
- Reader outcome named
- Claims verified and qualified
- Customer details permitted
- Platform and community fit checked
- Voice and formatting reviewed
- Exact account, date, time, link, and media confirmed
- Failure owner known