Agency roles for social content: who drafts, who approves, who releases

The three-role split that lets juniors do real work without release risk, why approval and release are different permissions, and how to scale it across a book of clients.

Small agencies run on one person per account. That person writes, decides, sends to the client and publishes, and it works beautifully right up to the point where they are on holiday, or leave, or make one mistake at scale.

The fix is not more process. It is separating four things that are usually one thing: drafting, internal approval, client release, and publishing. Once they are separate permissions rather than stages in one person's head, juniors can do real work, seniors stop being a bottleneck on every post, and no single mistake reaches a client feed unaccompanied.

The four permissions

They are worth naming precisely because most tools and most agencies collapse them into two.

Draft. Create and edit content. The permission a junior or a freelancer should have on day one, on real accounts. There is no faster way to train someone and no reason to withhold it, because drafting is reversible.

Approve internally. Assert that this is good enough to show the client: on brand, factually sourced, within scope. This is a quality and risk judgment and it belongs to whoever is accountable for the account, not to whoever wrote it.

Release to client. Send it out of the agency. Separate from internal approval because it is the moment work becomes visible to someone who is paying, and because the person who should own client communication is often not the person who owns editorial quality.

Publish. Put it on the account. The narrowest permission, and the one most agencies hand out most casually.

The important claim: approve and publish must not be the same permission. A post can be approved on Tuesday and correct, and publishing it on Thursday can still be wrong because the client announced a layoff on Wednesday. Someone has to own the moment, not just the artefact.

The three roles this produces

Map the permissions onto people and you get a shape that works from three people to thirty.

Writer — drafts. Junior, freelancer, or a senior on a client they know well. Has access to that brand's voice definition, fact file and forbidden list, and nothing else. Cannot release, cannot publish.

Account lead — approves internally and releases to the client. Accountable for the account: the editorial standard, the factual sourcing, the client relationship. One named person per client, always, including holiday cover assigned in advance.

Publisher — publishes on schedule. Often the same person as the account lead in a small agency, and that is fine. What matters is that it is a distinct act with its own check, not a side effect of approval. On larger books this is genuinely a separate role with a daily pre-publish sweep.

Plus the client, who approves what the account lead released. That flow is a different problem with its own failure modes — see the approval workflow that doesn't lose the client.

What each stage actually checks

Roles without checks are just job titles. Each gate is looking for something specific, and the specificity is what makes it fast.

StageThe questionBlocks on
DraftDoes this say something, in this brand's voice?Generic content, wrong register
Internal approveIs every factual claim sourced and in scope?Unsourced numbers, over-generalised claims
ReleaseIs this the right thing to send this client this week?Bad timing, scope creep, tone against context
PublishHas anything changed since approval?News events, client announcements, live incidents

The internal approval gate is where wrong claims get caught, and it is the gate most often skipped when the account lead is busy. If one gate has to be defended, defend that one.

Give juniors real work, not fake work

The common failure is over-correcting: juniors get research and scheduling, seniors write everything, and the agency has a capacity ceiling equal to its senior headcount plus a training programme that produces nobody.

A permission model makes the safe version possible. A junior drafting on a live account with no release permission cannot cause an incident, so there is no reason to hold them back from the work that actually teaches — writing in someone else's voice against real constraints and getting edited.

Two things make this work in practice:

  • Edits go back with reasons. "Cut this, it's puffery" teaches; a silently rewritten draft teaches nothing and is the most common way agencies fail to develop people.
  • The voice definition and fact file are accessible to the writer. If the standard lives only in the account lead's head, the junior cannot hit it and the feedback loop is arbitrary. Writing it down is what makes delegation possible at all.

Where the model breaks

One person is every role on eight accounts. Common, and usually described as being busy. It is a single point of failure with no holiday cover and no second read on any claim. The first fix is not hiring — it is assigning a named second approver per client, even if that person only reads.

The gates exist but everyone has every permission. Then the model is documentation, not a control. Permissions that are not enforced are conventions, and conventions collapse exactly when the week is bad.

Approval lives in chat. The gates ran, the record did not. Six weeks later nobody can say who approved what, which is the state you are in during precisely the conversation where it matters. Approvals belong attached to the post.

Nobody owns publish. So it happens automatically at the scheduled time, including the morning of a client's outage. Automation is fine for the mechanics; someone still has to own the last look.

Scaling it across a book

At three clients the model is a shared understanding. At fifteen it needs to be enforced by something, because the number of people-times-brands combinations exceeds what anyone tracks reliably, and the failure is silent — nobody notices a missing gate until an incident.

What that requires is per-brand scoping rather than agency-wide roles: a writer added to two accounts sees two accounts, and permissions travel with the brand rather than with a job title. That is how SelfSM models it — draft, approve and client release are separate per-brand permissions, and every transition is recorded against the post itself, so the trail exists without anyone maintaining it. When an account changes hands, that record is most of what makes the handover survivable.

FAQ

What roles does an agency need for social media content? At minimum three: a writer who drafts, an account lead who approves internally and releases to the client, and someone who owns publishing. In small agencies the last two are the same person, but they should remain distinct acts with distinct checks.

Should approval and publishing be the same permission? No. A post can be approved and correct on Tuesday and wrong to publish on Thursday because circumstances changed. Someone has to own the moment of publishing, not just the approval of the artefact.

Can juniors draft on live client accounts? Yes, and they should. Drafting is reversible and it is the only thing that actually trains someone. What juniors should not have is release or publish permission — that separation is what makes real delegation safe.

How do you stop client approvals from living in Slack? Attach approvals to the post rather than to a conversation. The gate running is not enough; if the record is in chat, nobody can reconstruct who approved what six weeks later, which is exactly when it is asked.

How many approvers should a client have? One named approver with a defined tiebreak, plus assigned cover for absence. Two peers who can both comment and disagree with no stated precedence is the most common cause of stalled approvals.