How to build a content calendar that survives multiple clients

A calendar that works fine for one client tends to fall apart at three, and it rarely fails for the reason people expect. The tool is usually not the problem. The structure is.

The problem isn't the calendar, it's what a date means

With one client, a date on a calendar is unambiguous. Tuesday means the post goes out Tuesday, because there's only one deliverable and you are the only person moving it.

Add two more clients and a single row now has at least four dates competing for the same square. The day assets are due in, the day editing starts, the day the client sees a cut, and the day it publishes. Most calendars pick one of these implicitly and then drift, because different people put different dates in the same field.

Pick one date to sort by and be strict about it. The publish date is almost always the right choice. It's the only one with an external consequence, and it's the one the client remembers. Every other date is a working date. Give each one its own column, and let the calendar view show only the publish date so the month view means exactly one thing.

Stages beat dates for knowing what to do next

A date tells you when. A stage tells you whose turn it is. At one client you can hold that in your head. At five you cannot, and the calendar has to carry it.

A workable default stage list, from a standing start to a live post.

• Idea. Captured, not committed to.
• Scripted. The outline or script is approved enough to shoot or edit against.
• Assets in. Footage, b-roll, brand kit and any client-supplied material have actually arrived.
• Editing. Someone is working on it right now.
• In review. A cut is with the client and you are waiting.
• Approved. Signed off, not yet posted.
• Scheduled. Queued with a caption and a time.
• Published. Live, with a link.

Resist adding more. Every stage is a decision somebody has to make each time a card moves, and stages that are always crossed on the same day should be a single stage. The useful rule is that if you have never once left a card sitting in a stage overnight, that stage is an event, not a state, and it should be a checkbox or a date field instead.

The one distinction worth protecting is Assets in. Client-supplied material is the most common cause of a missed publish date, and separating we have everything from we are editing is what lets you see, on Monday, which Friday deliverables are already in trouble.

The columns that actually earn their place

Column count is a tax. Every field is something to fill in on every row forever, so the bar for adding one should be that you would change a decision based on it.

Columns that look useful and aren't

• Priority. With real deadlines, priority is derived. If a field is derivable from another field, it can only disagree with it.
• Percent complete. Nobody can estimate this honestly on creative work, and everyone rounds to 80%. Stage carries the same information without inviting a guess.
• A general notes column. It becomes the place where feedback, context, credentials and one-off requests all go to die together. Anything worth keeping deserves a field.

What actually breaks as clients are added

The failures are consistent, and knowing them in advance is most of the work.

1. Capacity becomes invisible. Per-client views hide the thing that hurts you, which is that next Thursday has one deliverable from each of six clients. You need at least one view that ignores client entirely.
2. The calendar stops being a plan and becomes a log. When rows are only created after work starts, the calendar can no longer tell you what is coming, only what happened.
3. Approvals arrive out of band. A voice note, a reply on a chat thread, a comment on a shared drive. If the approval isn't written back onto the row, the row is wrong and you will re-ask.
4. Naming collides. Three clients all have a piece called Launch teaser. Without the client name in the title or a hard client column, search stops working.
5. Recurring commitments get modelled as one-offs. Most retainers are a quota, four shorts a week, twelve a month. Modelled one piece at a time, you find out you are behind at the end of the month instead of the middle.

Plan the slot before you have the idea

The fix for the last one is worth stating on its own. If a client is on four posts a week, create the four rows for every week of the month up front, with a publish date and a client and nothing else. They are placeholders, and they are honest ones. The commitment exists whether or not the idea does.

This flips the failure mode. Instead of discovering on the 24th that you owe six deliverables, you see empty slots the whole way along and can fill them, move them, or renegotiate them while there is still time. It also makes the calendar a genuine forecast, which is the only version of a calendar that helps you decide whether to take on the next client.

Two views, not one

One layout cannot answer both of the questions you have. Keep two, built from the same rows.

• A calendar view, sorted by publish date, all clients together. This is for capacity and clashes. You read it weekly and you read it to say no to things.
• A stage view, a board or a grouped list. This is for today. You read it to decide what to touch next, and you filter it to what is waiting on you most of the time.

The critical part is that both views read the same underlying rows. The moment the calendar and the board are separate documents, they disagree within a week, and the one that disagrees quietly is the one you were relying on.

Four rules that keep it honest

1. One row per deliverable, never per platform. A piece that goes to three places is one piece of work with three destinations. Splitting it into three rows triples your bookkeeping and loses the fact that they share a cut.
2. Every row has a next action and someone waiting. A row where neither is true is either finished or abandoned, and both of those should be visible.
3. If it isn't on the row, it didn't happen. Feedback that arrived in a chat gets copied onto the row, in the client's words, before you act on it. This costs thirty seconds and prevents the argument.
4. Review it on a fixed day. A calendar nobody audits drifts within about two weeks. Fifteen minutes on the same morning each week, reconciling stage against reality, is what keeps it trustworthy. A calendar you don't trust is worse than none, because you'll keep a second one in your head.

Start from a structure that already works

If you're building this from scratch, don't start with an empty grid. Start from a layout that already has the client, stage, publish date and waiting-on columns in it, then delete what you don't use. A content calendar template gets you to a working structure faster than designing one, and the columns you delete teach you as much as the ones you keep.

Whatever you build it in, the structure above is the part that matters. A spreadsheet holding these columns well beats a purpose-built tool holding them badly. It's worth knowing where a spreadsheet does start to give. That's a separate question about files, feedback and scheduling, not about columns.