---
name: "social_media_sops"
description: "Build a complete social media team SOP package: risk-tiered approval chains, RACI roles, escalation paths, a voice document, and a publish audit trail. Triggers when a brand needs its social team operations documented, approval workflows designed, escalation rules defined, or a new social hire onboarded with real procedures."
---

# Social Media SOPs

## Purpose

Turn tribal knowledge into a written operating package a social team can actually run: who approves what and how fast, who does what on the team, how issues escalate, how the brand sounds, and what gets recorded for every publish.

## Workflow

1. **Gather inputs.** Brand name, the accounts in scope, team roster with names and hats, tools used (scheduler, shared inbox), industry constraints (regulated, legal review required). Ask for what is missing; do not invent names or roles.
2. **Classify content risk.** Define 3-4 risk tiers (routine, standard, high-risk, crisis). Routine posts take the short path, high-risk takes the long one. Details in `references/approval-chains.md`.
3. **Draw the approval chains.** For each tier: the reviewer sequence, the SLA for each step, the backup approver, and what "silence" means (does no response approve, or does the post stall). Use the templates in `templates/`.
4. **Set escalation paths.** Define the tiers: what the social manager handles alone, what goes to PR/comms, what goes to legal or executives. Include the decision tree and response SLAs. See `references/escalation-paths.md`.
5. **Write the voice doc.** Personality traits, voice attribute chart with do/don't examples, tone-by-context table, banned words. Keep it one scannable page. See `references/voice-doc.md`.
6. **Generate the package.** Feed the collected facts into `bin/sop_pack.py` to emit the full SOP markdown, or fill in the `templates/` by hand.
7. **Lock the audit trail.** Every publish records: post, author, approver(s), approval timestamps, risk tier. That is how you survive an internal review or a regulator.

## Output Contract

- A generated `SOP.md` (or filled templates) covering: team roster and RACI, approval routes per risk tier with SLAs, pre-flight checklist, escalation tiers with owners and response times, voice quick reference, publish audit rules.
- Templates provided: `templates/approval-request.md`, `templates/raci-matrix.md`, `templates/escalation-playbook.md`, `templates/voice-doc-template.md`.
- Every role named is a real named person or an explicitly marked vacancy. No "someone should" language.

## Operating Rules

1. Never invent facts: team names, tools, account handles, and legal requirements come from the user or a primary source.
2. Silence is never approval unless the team explicitly adopted a default-advance rule in writing. When in doubt, the post waits.
3. Crisis response routes through the escalation tiers in `references/escalation-paths.md`. Do not publish crisis messaging through the routine approval path.
4. Voice guidance here is the operating doc, not the craft. For developing a voice from scratch, use the `brand_voice` skill; this SOP references the resulting charter.
5. The SOP names a backup approver for every gate. If a gate has no named backup, the SOP is incomplete.
6. Review the package quarterly. Outdated SOPs are worse than none: people trust the document and stop thinking.