> ## 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.

# Planning the content calendar

> The recurring workflow that fills and maintains the content calendar: the planning session, how a campaign's supporting content gets sequenced, what happens when a date moves, and the weekly pass that keeps rows honest.

Run this on a cadence to keep the [content calendar](/content-calendar) accurate enough to produce against. It covers the planning session that fills the calendar and the weekly pass that keeps it true.

<Info>
  This process uses the [**content calendar**](/content-calendar) standard, the [**organic social post brief**](/organic-social-post-brief), the [**article brief**](/article-brief), [**messaging**](/messaging), and the [**approval process**](/approval-process).
</Info>

## What you'll end up with

* A calendar filled to your planning horizon, every row with an owner, a status, and a message pillar.
* Every row that exists because of something else carrying what it is **anchored to**.
* A brief for every row that has reached production.

## Before you start

| You need                                      | Where it lives                                                              |
| :-------------------------------------------- | :-------------------------------------------------------------------------- |
| A calendar with agreed columns and statuses   | [Content calendar](/content-calendar)                                       |
| Message pillars                               | [Messaging](/messaging)                                                     |
| What is already committed elsewhere           | Campaign briefs, [article briefs](/article-brief), the product release plan |
| Last period's published rows and how they did | The calendar, plus your channel reporting                                   |

## The planning session

<Steps>
  <Step title="1. Close out the last period first">
    Before adding anything, walk the rows that have passed. Fill in published URLs, move anything that did not ship to Dropped with a reason or forward with a new date, and note which posts did unusually well or badly.

    Planning on top of an inaccurate calendar produces a plan nobody trusts by week two.
  </Step>

  <Step title="2. Lay in the fixed points">
    Start with what is already committed and cannot move: campaign flights, product releases, events, reports, and anything seasonal.

    These are the anchors. Everything added in the next step is timed relative to one of them or is deliberately standalone.
  </Step>

  <Step title="3. Add supporting content around each anchor">
    For each fixed point, decide what content it needs and in what order. Fill in the **anchored to** and **sequence** columns as you go, not afterwards.

    A campaign flight usually wants a set rather than a single post. See the sequencing table below.
  </Step>

  <Step title="4. Fill the remaining slots, or leave them empty">
    Work to the target volume in your calendar standard, and stop when the ideas stop. A row that cannot say what it is for is a slot being filled, not a post being planned.
  </Step>

  <Step title="5. Assign an owner and a status to every row">
    One name per row. A row with no owner is a row that gets discussed again next month in exactly the same state.
  </Step>

  <Step title="6. Check the mix">
    Read the period as a whole: are the message pillars balanced, or has one taken over? Is one format doing all the work because it is the fastest to make? Both drift without anyone deciding.
  </Step>
</Steps>

## Sequencing content around a campaign

Organic content supporting a paid flight is a set with an order. Decide what each piece is doing before deciding what each piece is.

| Position      | Timed against                          | What it is doing                                                             |
| :------------ | :------------------------------------- | :--------------------------------------------------------------------------- |
| Before launch | *E.g. 4 days before the flight starts* | Warms the audience, so the ads land on a topic the feed has already seen     |
| Mid-flight    | *E.g. Week 2 of the flight*            | Runs alongside the ads, carrying the same message pillar in a non-paid voice |
| At close      | *E.g. Final week*                      | Closes the argument, often with proof or a result the ads could not carry    |

Record each row's position in the **sequence** column and the flight in **anchored to**. That pair is what lets the whole set move together when the flight moves, and what tells whoever picks up production which post has to be ready first.

<Warning>
  Publishing a sequenced set out of order is worse than publishing one post. The pieces are written to build on each other, so a closing post that lands before the warming post reads as a non sequitur, and the set costs more than it returns.
</Warning>

## The weekly pass

Short, and the thing that keeps the calendar worth reading.

* Every row publishing in the next two weeks has a brief and an owner.
* Every row in production has cleared, or is queued for, whatever [approval](/approval-process) it needs.
* Every row that published last week has its URL filled in.
* Anything slipping has been moved, with its sequence moved with it.
* Anything urgent that published without a row has one now.

## When an anchor moves

<Steps>
  <Step title="Filter by the anchor, not by the date">
    Every row anchored to the thing that moved is a candidate. Rows on the same dates that are anchored to something else stay where they are.
  </Step>

  <Step title="Move the set, keeping the intervals">
    A sequence timed four days before, mid-flight, and at close keeps those relationships. Shifting only the first post breaks the set.
  </Step>

  <Step title="Check what the move collided with">
    Rows moved into a week that was already full is the common second-order problem, and it is the reason to re-read the week rather than just the moved rows.
  </Step>

  <Step title="Tell the owners">
    A moved date with no message to the person producing against it is how a post arrives finished on the wrong day.
  </Step>
</Steps>

## Exceptions

* **A reactive or urgent post.** It publishes first and gets its row the same day. The row is not optional; it is what keeps the channel report and the retrospective complete.
* **A recurring series with a fixed slot.** One row per instance still, because each one needs its own URL and status, but they can share a brief per the [post brief](/organic-social-post-brief).
* **A channel someone else owns.** If another team publishes on a channel you report on, the calendar still needs the rows, even if it does not own the production. Agree who adds them.

## Related resources

* [**Content calendar**](/content-calendar) The standard this process fills in.
* [**Content calendar concepts**](/content-calendar-concepts) Why anchors and sequence are recorded.
* [**Publishing an organic social post**](/organic-social-post-process) What happens to a row once it is in production.
* [**Creating an article**](/article-process) The other producer of rows.
* [**Campaign brief process**](/campaign-brief-process) Where the flights that anchor content are decided.