> ## Documentation Index
> Fetch the complete documentation index at: https://docs.snowdoughnut.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Content calendar
> The standard for your content calendar: where it lives, the columns every row carries, what each status means, and who owns it. The calendar itself is a live tool linked from here, not a table in this knowledge base.
*This page is a workbook. Fill in each section to define your own calendar standard, and expand a concept review for the reasoning. Grayed* `E.g.` *text is a placeholder to replace. Examples use **Doughnut Labs**, a SaaS company that sells disruptive Doughnut Technology.*
**The calendar does not live on this page.** It is a live artifact with a row per item, edited daily, read as filtered views. Keep it in a scheduling tool, a database, or a spreadsheet, and link it below. This page defines what a row looks like and what the statuses mean, the same way the [creative drive](/creative-drive) defines the folder rather than holding the files.
## A. Where it is
| Field | Fill in |
| :------------------------------------------ | :----------------------------------------------------------- |
| Location | *E.g. \[link], the Content database in Notion* |
| Owner | *E.g. Marco Silva* |
| Who can add a row | *E.g. Anyone in marketing* |
| Who can change a date after it is committed | *E.g. The owner only* |
| Scheduling tool, if separate | *E.g. Buffer. The calendar is the plan; Buffer is the queue* |
| Where published URLs come back to | *E.g. The same row, filled in after publishing* |
Two tools are common here and they do different jobs. A calendar holds the plan, including things that have no asset yet and things that were considered and dropped. A scheduler holds the queue: finished posts with a send time. Teams that use only the scheduler lose everything upstream of a finished asset, which is where planning actually happens.
The row about who can move a committed date is the one that decides whether the calendar means anything. A date anybody can change is a suggestion, and a channel planned on suggestions drifts back to whoever posts most often.
## B. The columns
**Confirm the columns every row carries. Keep the ones that fit, cut the ones you would not fill in.**
| Column | What it holds | Example |
| :--------------------------- | :-------------------------------------------------------------------------------------- | :------------------------------------ |
| Title | A short working name for the item | *E.g. Setup-in-an-afternoon carousel* |
| Channel | Where it publishes | *E.g. Instagram* |
| Format | The production job it implies | *E.g. Carousel* |
| Publish date and time | When it goes out | *E.g. 2026-04-22, 09:00* |
| Anchored to | What the date was chosen relative to | *E.g. Google flight launch, 22 Apr* |
| Sequence | Its position, if part of a set | *E.g. 1 of 3* |
| [Message pillar](/messaging) | The pillar it carries | *E.g. Pillar 2, one source of truth* |
| Campaign | The marketing campaign, if any | *E.g. Fresh Batch spring trial* |
| Owner | One name | *E.g. Marco Silva* |
| Status | See section C | *E.g. Scheduled* |
| Brief | Link to the [post brief](/organic-social-post-brief) or [article brief](/article-brief) | *E.g. \[link]* |
| Published URL | Filled in after it goes live | *E.g. \[link]* |
| \[add column] | | |
Don't copy the caption, the creative direction, or the UTM string into the calendar. Those live in the brief, and a second copy is a second thing to update. The calendar links to the brief; it does not restate it.
Most of these are self-explanatory bookkeeping. Two are not.
**Anchored to** is what separates a calendar from a list of dates. A date records when something publishes; an anchor records what that date was chosen relative to. When a paid flight moves a week, a calendar of bare dates gives no way to tell which rows should move with it, and someone re-derives the whole plan from memory. With anchors it is a filter.
**Sequence** exists because a set of posts is a single argument delivered in parts. Three posts supporting a flight have an order, and the order carries meaning: warm the audience, run alongside the ads, close out. A calendar that shows three unrelated rows on three dates has lost the thing that made them a set, and whoever picks the work up will publish them in whatever order the assets are ready.
Message pillar is worth the column for the reason [organic social](/organic-social-home) already gives: posts planned as standalone ideas drift from what the brand is trying to say, one reasonable-looking post at a time.
## C. Statuses
**Define what each status means and who moves a row into it.**
| Status | Means | Who sets it |
| :------------------- | :------------------------------------------------------------------------------ | :---------------- |
| *E.g. Idea* | *E.g. Proposed, no date committed, may never run* | *E.g. Anyone* |
| *E.g. Planned* | *E.g. Date committed, brief not written* | *E.g. Owner* |
| *E.g. In production* | *E.g. Brief written, creative or copy in progress* | *E.g. Item owner* |
| *E.g. Approved* | *E.g. Cleared per the [approval process](/approval-process), ready to schedule* | *E.g. Approver* |
| *E.g. Scheduled* | *E.g. Loaded into the scheduler with a send time* | *E.g. Item owner* |
| *E.g. Published* | *E.g. Live, URL filled in* | *E.g. Item owner* |
| *E.g. Dropped* | *E.g. Decided against. Row kept, with a one-line reason* | *E.g. Owner* |
| \[add status] | | |
The two statuses teams tend to leave out are the two that do the most work.
**Idea** gives a place for something that is not committed. Without it, an idea either gets a date it does not deserve, which fills the calendar with work nobody decided to do, or it lives in someone's notes and is lost. A calendar that only holds committed work quietly becomes a calendar that commits to everything.
**Dropped** keeps the record of what was considered and rejected. Deleting the row instead means the same idea comes back next quarter with the same enthusiasm and no memory of why it was dropped the first time. One line of reason is enough.
## D. Cadence and capacity
| Field | Fill in |
| :-------------------------------- | :----------------------------------------------------------------- |
| Planning cadence | *E.g. Monthly, one session, four weeks ahead* |
| How far ahead dates are committed | *E.g. Two weeks firm, four weeks planned* |
| Target volume per channel | *E.g. Instagram 3 a week, LinkedIn 2 a week* |
| What we will not fill | *E.g. A slot with no objective. An empty week beats a filler post* |
| Who reviews the plan | *E.g. Marco Silva and the brand lead, at the monthly session* |
A target volume is useful as a planning constraint and dangerous as a quota. The difference shows up in what happens when a week is short: a constraint lets the week be short, a quota gets it filled.
This is worth deciding explicitly because the pressure only runs one way. Nobody is ever asked why the calendar had a gap that turned out fine. Writing down that an empty slot is an acceptable outcome is what gives whoever runs the session something to point at.
Committing dates in two horizons, firm and planned, tends to work better than one. It lets the near term be reliable enough to produce against while the further term stays cheap to change.
## E. When something moves
| Situation | What happens |
| :------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------- |
| The thing a row is anchored to moves | *E.g. Filter by anchor, move every row with it, keep the gaps between them* |
| A single item slips | *E.g. Owner moves it, notes the new date. If it is part of a sequence, the rest move too* |
| An item is dropped after production started | *E.g. Status to Dropped with a reason, and the finished asset goes to the [creative drive](/creative-drive) so the work is not lost* |
| Something urgent has to go out | *E.g. It gets a row before it publishes, even if the row is written the same morning* |
A post published without a calendar row is invisible to everything downstream: the retrospective, the channel report, and the next planning session. If the process has to be broken for something urgent, the row is what gets written afterwards, not skipped.
## Related resources
* [**Content calendar concepts**](/content-calendar-concepts) Why the calendar records anchors and sequence.
* [**Planning the content calendar**](/content-calendar-process) The recurring workflow that fills it.
* [**Organic social post brief**](/organic-social-post-brief) The per-post record a row links to.
* [**Article brief**](/article-brief) The other producer of rows.
* [**Messaging**](/messaging) Where message pillars are defined.
* [**Asset directory**](/asset-directory) Every location in one index.