A Content Calendar Clients Can See and Approve

You shared the calendar. The client wrote back, "Looks good!" Three weeks later they read the actual post and ask who agreed to it, and you scroll up to a two-word reply that suddenly doesn't feel like much.

That's the usual trouble with client content calendar approval. A calendar is a lovely way to see a month, and a poor place to record a decision, unless you've agreed what a yes on it means. Here's how we'd set one up so a client can read it and answer it, and so you can tell later what they said.

"Looks Good" Can Mean Two Things

Ask a client what they approved when they answered a calendar, and you might get a different answer from the one you assumed. They may have meant "these are the right topics for April." You may have heard "go ahead and run these."

So ask for them separately, and say so when you send the plan:

Hi Dana, here's the plan for April: the topics, the channels, and the dates. A yes here means we'll start writing. You'll still see every post before it runs, and that's when the wording gets your yes. Anything you'd swap or drop?

The two answers do different jobs. A yes to the plan saves your team from writing a post about a product the client is quietly retiring. A yes to the words is the one you'd point to if someone later asks who approved this. Our guide to the content approval workflow covers how to ask for that second one and what to do when it doesn't come.

What Belongs on the Client's Copy

Your team's calendar has jobs to do that the client's copy doesn't. Who's writing what, how long it took, the note that says "client always changes this." Leave all of that on your side.

We'd give each row on the client's copy five things:

• The date it goes live. Say whether that's planned or locked in.
• The channel. LinkedIn, newsletter, blog.
• The topic, in their words. "Spring pricing" means something to them, and "Q2 content pillar 3" doesn't.
• Where it stands. Use a few plain words, and use the same ones every month.
• What you need from them. Usually nothing. When it's something, give the date.

That last one is what makes a calendar worth opening. Most of a client's rows should say that nothing is needed, so the two that do stand out. If every row looks equally urgent, they'll treat them all as optional.

Count Back From the Day It Goes Live

"Review by" dates work best when they come from the go-live date, not from when your writer happens to finish. Pick the go-live day first, then count back.

Three things catch people out when they set this up:

• Weekends. A Monday go-live with a two-day lead means Saturday, and nobody at the client is reading on Saturday. Decide whether you count them.
• The client's rhythm. Ask at kickoff when they're unreachable. Board weeks, trade shows, and month-end all eat review time, and it's better to plan around them than be surprised.
• Different lead times for different work. A short social post might need a day. Something a lawyer reads needs longer. Set this client by client, because a regulated firm and a local bakery won't share a schedule.

Put the review date on the calendar too, in the row the client reads. A date they can see is much harder to miss than one buried in an email from Tuesday.

One Calendar per Client

It's tempting to share the master view, filtered. In our view, that's the one thing not to do. A filter changes what shows, and it doesn't change what someone with the file can reach. Your client doesn't need to learn who else you work with, or that their competitor's launch is the week before theirs.

Tools often work this way already. Loomly, for example, lists a dedicated content calendar per brand, and Gain describes a workspace per client with separate calendars (both checked on November 5, 2026). A spreadsheet can do this too, with one file per client rather than one tab per client. If you're choosing software, our buyer's guide to approval tools goes through what to test.

If a client has more than one person who signs off, the calendar is a good place to make that visible. The row can say who the post is waiting on, so nobody has to ask around.

When a Date Moves

Dates move all the time. Launches slip and news breaks. The rule we'd follow is simple: moving a date doesn't change the words, and changing the words does change the approval.

• The date moves, and the words don't. Tell the client. Their yes still stands, unless the post mentions the date, says "this week," or was tied to something that has moved with it. Read it again for that.
• The words change, even by a line. It needs another look from whoever approved it. They said yes to the old version, and that's the only version they said yes to.
• The date has passed, and there's no yes. The post waits. Nothing runs because the calendar said so.

Here's a note for the first case:

Hi Dana, your launch moved to the 14th, so we've moved the two launch posts to match. The words are the same ones you approved. Tell us if anything else should shift.

The names and dates here are made up, and the shape is what to keep: what moved, what didn't, and one easy way to object.