---
name: social-scheduling-stack
description: Choose and run a social media scheduling stack: compares native schedulers vs Buffer vs spreadsheet-driven queues, designs the queue architecture (slots, lanes, approvals), and sets up monitoring so scheduled posts that fail to publish get caught. Use when planning a posting pipeline, picking a scheduling tool, or debugging posts that never went out.
---

# Social Scheduling Stack

## Purpose
Help an agent (or a human it advises) pick the right scheduling stack for a social media operation and keep it reliable. Covers three archetypes: native schedulers (Meta Business Suite and the in-app Instagram scheduler), Buffer-style third-party queues, and spreadsheet-as-source-of-truth queues. The output is a concrete recommendation plus a queue design and a monitoring routine, not a generic comparison article.

## Workflow

### 1. Profile the operation
Ask or infer five things before recommending anything:
- Channels: how many accounts, which platforms.
- Volume: posts per week per channel.
- Team: solo creator, small team, or agency with client review.
- Content mix: one-shot announcements vs evergreen content worth recycling.
- Budget tolerance: free-only, or a few dollars per channel per month.

If any of these are unknown, say so and state the assumption you are making.

### 2. Pick the stack (decision tree)
Work top to bottom, first match wins:

1. **Solo, 1-2 channels, low volume (under ~10 posts/week), no bulk needs:** native is enough. Meta Business Suite is free, schedules Facebook Page posts 20 minutes to 29 days ahead, and the Instagram in-app scheduler goes up to 75 days ahead at up to 25 posts per day. Schedule, and cross-post Facebook plus Instagram from one place. No cost, no new logins.
2. **3+ channels, queue-style rhythm, or bulk import from a spreadsheet:** Buffer. Free tier covers 3 channels at 10 scheduled posts each; paid is $5 per channel per month. Its queue model lets you set daily posting slots once and feed posts into the queue instead of hand-picking times. CSV bulk import takes 10 posts per channel on Free, 100 per channel on paid plans. Cap of 2,000 scheduled posts per channel.
3. **Multi-author pipeline or campaign batches:** spreadsheet as the source of truth. One tab for the content pipeline (draft, approved, scheduled, published), one tab per batch for Buffer CSV import. Feeds either Buffer (import the approved tab) or native schedulers (copy rows into the Planner by hand). Never let the spreadsheet drift from the actual queue; it is either the source or it is deleted.
4. **Agency with approvals, many clients, or heavy analytics needs:** you have outgrown this skill's scope. Buffer's approval depth is thin at low tiers; say so and recommend evaluating enterprise schedulers against the current needs instead of forcing a fit.

Details and hard limits live in `references/stack-comparison.md`. Read it before quoting numbers to anyone.

### 3. Design the queue
- **Slots:** set recurring posting slots per channel (e.g. weekday 09:00 and 17:00 local). Buffer's queue fills slots in order; for native scheduling, record the slots in the queue plan and use them every time.
- **Mix:** assign each slot a content lane (announcement, evergreen, engagement). This stops one loud campaign from eating the whole week.
- **Evergreen recycling:** only a third-party queue recycles content on a loop. Native schedulers have no evergreen queue; if recycling matters, that decides for Buffer (or equivalent).
- **Draft vs scheduled:** drafts have no time attached. Nothing counts as queued until it has a slot or a timestamp. Track statuses exactly: `draft`, `approved`, `scheduled`, `published`, `failed`.
- Use `assets/queue-plan-template.md` to record the slots, lanes, and statuses.

### 4. Set up monitoring (posts that fail to go out)
Silent failures are the norm, not the exception. The top cause is an expired OAuth token: nothing tells you until a post does not appear. Tokens for Meta integrations expire roughly every 60 days; a password change or revoked permission kills them sooner.

Run this check on a fixed cadence (weekly for active accounts, daily during a campaign):
1. **Connection health:** open each tool's account page. Any profile showing Expired or Error gets reconnected now, not later.
2. **Token age:** note the last reconnect date per account. Anything past 45 days gets a reconnect this week.
3. **Expected vs published:** for every item marked `scheduled` with a time in the past, verify the post actually exists on the platform. Treat "could not verify" and "not posted" as different states: if the platform API/page loads fine and the post is absent, it is `failed`. If you cannot reach the platform, mark it `unverified` and check again; never report an unverified post as failed.
4. **Failure log:** record each failure with date, channel, and root cause (expired token, format rejected, rate limit, platform error). Patterns here drive stack changes.
5. **Platform gotchas worth knowing:** scheduled Instagram Stories lose interactive stickers; carousels need 3 to 10 images; scheduling itself does not reduce reach (a common myth; native and official-API posts are treated the same as manual ones).

### 5. Reconcile and iterate
When a pattern emerges in the failure log (for example, tokens expiring faster than your check cadence), tighten the cadence or switch tools. When volume outgrows the free tier or the native window (Facebook's 29-day ceiling, Instagram's 25/day), re-run the decision tree. The stack is a decision you revisit, not a marriage.

## Output Contract
A completed engagement produces, at minimum:
1. **Stack recommendation:** named stack, one paragraph of reasoning tied to the five profile inputs, total monthly cost if any.
2. **Queue plan:** filled copy of `assets/queue-plan-template.md` with slots, lanes, and statuses.
3. **Monitoring routine:** check cadence, connection-health steps, token-age tracker location, and where the failure log lives.
4. **Failure log entry** (when debugging): dated, with the root cause and the fix applied.

Every number quoted (limits, windows, prices) must come from `references/stack-comparison.md` or a fresh primary-source check. Unverifiable = cut it.

## Operating Rules
1. Never invent limits, prices, windows, or platform capabilities. If a figure is not in the reference file and cannot be verified, omit it and say you omitted it.
2. Recommend the simplest stack that fits. Do not upsell a paid tool when native covers the need.
3. A queue is not a plan until every item has a slot or timestamp. Drafts do not count.
4. When verifying whether a post published, prefer a direct check on the platform over any dashboard status. Never infer a failure from an unreachable page; mark it unverified and retry.
5. Keep the skill's voice plain: no em dashes, no marketing language, no filler. Short sentences, concrete nouns.