social_agency_operations v1.0.0

name: "social_agency_operations" description: "Run social media for multiple clients as an agency: per-client intake and brand files, tiered approval workflows that keep posting on schedule, delegated access and credential hygiene, one-page monthly reports clients actually read, and contract-end handover. Triggers on 'onboard a social client', 'agency approval workflow', 'client social report', 'hand over a client account', or running social for more than one brand."

Social Agency Operations

Purpose

Run social media as a multi-client operation, not as a pile of separate accounts in one person's head. One isolated workspace, brand file, access register, approval chain, and report per client. Assets, audiences, approvals, and data never bleed across clients.

This skill covers the agency operating system. For a single brand's internal team SOPs use the social media SOPs skill. For content craft (hooks, calendars, formats) use the content skills for that platform. This skill owns everything around the content: intake, access, approval, reporting, and exit.

Workflow

1. Intake: close these before the first post is drafted

Get every item in writing, in the client file. A missing item is a blocker, not a detail to sort out later.

• Scope: platforms, posts per month per platform, formats included, community management included or not, paid social included or not (paid and organic are separate scopes with separate approvals)
• Business goal per platform in the client's words, plus the one metric that proves it (calls, bookings, link clicks, reach in a service area, hires)
• Decision maker: one named approver and one named backup. Not a committee, not "the team will look"
• Approval terms: revision rounds included, approval lead time, the late approval rule (step 3), which categories need legal or leadership review
• Escalation contact for urgent items, with the channel that actually gets answered (phone, not a shared inbox)
• Banned ground: topics, claims, competitors, and words the brand never uses. Claims that need substantiation on file before they can be posted
• Reporting terms: recipients, cadence, and whether off-platform results (calls, bookings, sales) are tracked somewhere you can cite
• Contract end terms: notice period, who owns raw files and exports, what happens to scheduled posts. Write the handover terms at intake, while everyone is friendly. See references/handover.md

Run a conflict check before signing: does the agency already serve a direct competitor, and does either contract restrict that? Record the answer in both client files.

2. Build the client file

Create one workspace per client. Nothing client-specific lives outside it.

• Run bin/agency_ops.py new-client <slug> to generate the folder: brand-file.md, access-register.csv, approval-log.csv, assets-log.md
• Fill brand-file.md from templates/brand-file.md: voice with do and do-not examples in the client's own past posts, visual rules, approved claims with their substantiation, banned ground, audience, pillars, key dates
• Audit the live profiles and record the baseline in the brand file: followers, reach, engagements and engagement rate by reach for the last full period available, with the period and the formula stated. Every later report compares against this baseline and the prior period, not against a generic benchmark
• Test the approval workflow on the first batch before calling onboarding done. A workflow that has never moved a real post is a guess

3. Run approvals on tiers, with a late rule

Classify every post into one tier at draft time. Log tier, approver, sent time, decision, and decision time in approval-log.csv.

• Green: pre-approved categories the client signed off in the brand file (evergreen education, holiday greetings, resharing the client's own news). Agency approves internally. Client sees them in the monthly report
• Amber: standard posts. Client approver or backup approves. Default lead time is the one agreed at intake
• Red: pricing, offers, health, financial or legal claims, newsjacking, anything naming a competitor, anything about a complaint or a crisis. Named approver only, no backup substitution unless the backup is also authorised for red, plus legal review where intake requires it

The late approval rule, agreed at intake, picks exactly one behaviour per client:

• Hold: the post waits and the slot stays empty
• Swap: an approved green post fills the slot and the late post moves to the next open slot
• Skip: the post dies and the calendar moves on

Silence is never approval for amber or red, whatever the client says on a call. If a client wants silence to count as approval, they sign that rule into the brand file with the lead time attached, and it still never applies to red.

Community management runs on its own lane, not the post approval chain: pre-approved reply templates for routine questions (hours, location, booking links), a same-day escalation path for complaints, and a hard rule that no one argues in public comments. Complaints move to a private channel with one named owner.

4. Hold access the delegated way

Full detail in references/platform-access.md. The short version:

• Client owns the assets. Pages, ad accounts, channels, datasets, and catalogues are created in, or claimed by, the client's own business account. An agency that owns a client's ad account owns the client's exit problem too
• Get access through the platform's partner or delegated system (Meta partner access by business ID, YouTube Studio channel permissions, equivalent role systems elsewhere), asset by asset, least privilege first
• Never accept a client's password by email, chat, or document. Never share one team login across staff. Every person acts under their own named account with multi-factor authentication on
• Where a platform offers no delegated access for a needed task, use a per-client vault entry in a password manager, shared only with the named staff on that client, and record that exception in the access register
• Keep access-register.csv current: person, platform, asset, role, granted by, date granted, MFA on or off, last reviewed. Run bin/agency_ops.py audit-access <file> monthly and at every staff change. It flags shared logins, admins without MFA, and entries not reviewed in over 90 days
• Staff member leaves or moves off a client: remove their access the same day, and log the removal in the register. Quarterly, reconcile the register against the live platform user lists for every client. Registers drift. Live lists do not lie

5. Report so the client reads it

Full metric definitions in references/reporting-metrics.md. One report per client per period, built to be read in under five minutes:

• Page one only: goal, the headline result against that goal, three numbers that matter with their definitions and denominators, what worked and why, what missed, and the specific changes for next month
• Per-platform breakdown and the full post table go in the appendix. Nobody reads an appendix first, which is the point
• Generate the numbers with bin/agency_ops.py report <posts.csv>: it totals reach, impressions, engagements, and clicks, and computes engagement rate by reach, click-through rate, and follower growth from the raw post data, so the arithmetic is checkable
• State the formula every time. Engagement rate by reach and engagement rate by followers give different numbers for the same post. A report that does not name its denominator is not a report, it is a claim
• Compare against the client's own baseline and prior period. Never present a third-party benchmark average as the client's target
• Tie at least one section to the business metric from intake. If calls or bookings are tracked in another system, cite that system and its number, or write plainly that the link is not tracked yet and how it will be
• End with decisions, not observations: keep, stop, test, with one owner and one date each

6. Run the client month

Follow the worked month in references/worked-client-month.md: intake close in week one of the relationship, then a steady rhythm of batch drafting, one approval round per batch, scheduled publishing, a mid-month check on the numbers that matter, and the report in the first days of the next month. Batch approvals. A client asked to approve single posts daily will stop approving anything within a month.

7. Hand over when the contract ends

Follow references/handover.md and generate the checklist with bin/agency_ops.py handover <slug>.

• Export and deliver: final exports and raw working files as the contract specifies, caption and alt text files, the content calendar, analytics exports for the full term, and the list of scheduled posts with a decision on each (publish, hand over, or delete)
• Confirm the client (or incoming agency) has working owner-level access to every asset before the agency's access is removed. Test it with them, do not assume it
• Remove agency partner access, every individual staff access, scheduler and tool connections, and password manager shares. Rotate any credential the agency ever touched where the platform forces shared logins
• Hand over open threads: unresolved comments, complaints, and DMs, each with its status and last action
• Close with a final report for the last period and a signed handover record from both sides listing what was delivered and what access was removed
• Keep the agency's own copy only as long as the contract or the agency's records policy requires, in the client workspace, access-restricted. Do not reuse one client's assets, audiences, or learnings presented as another client's work

Output Contract

Per client, kept current:

• brand-file.md: voice, visual rules, approved claims, banned ground, pillars, approver and backup, tier definitions, late approval rule, escalation contact, baseline metrics
• access-register.csv: every person, role, and asset, with MFA status and review dates, clean under audit-access
• approval-log.csv: every amber and red post with tier, approver, and decision times
• Monthly report: one-page summary plus appendix, generated numbers from report, formulas and denominators stated, decisions at the end
• On exit: completed handover checklist and a handover record signed by both sides

Operating Rules

• Never invent a client fact, metric, approval, or result. Numbers come from platform exports or the report tool. Approvals come from the log.
• Never use em dashes in client-facing copy or reports written under this skill.
• Disclose material connections clearly and conspicuously in endorsement and influencer posts, in the post itself where it cannot be missed, not buried at the end of a caption or among hashtags. The brand and the agency share responsibility for this, so check it at approval time, not after publishing.
• Separate clients absolutely: no shared folders with mixed assets, no reusing a draft written for one client for another, no showing one client another client's numbers.
• A post with an unsubstantiated claim is a red post that does not ship, whatever tier it was first filed under.
• If the approver, backup, and escalation contact are all unreachable and a red item is live or a crisis is moving, pull the content first and explain after. Everything else waits.
• This skill is operations, not legal advice. Contract, ownership, and disclosure disputes go to the client's or the agency's lawyer, with the client file as the evidence pack.