task-ops
A downloaded content calendar template usually arrives with twenty two columns. Persona, funnel stage, target keyword, word count, primary CTA, distribution channels, repurposing plan, approval status, SEO score. It looks like the work of a serious team. Four weeks later six of those columns are populated, the rest are blank, and one of the blank ones is status, which is the only column anyone needed.
The problem is not laziness. Every column is a promise that somebody will type into it forever, and most templates are built by people who will not be the ones typing. Choosing a template is really choosing how many of those promises the team can keep.
Before a field goes in, four questions settle whether it survives. Any column that fails one of them is going to be blank by the second month.
Who reads it. Not who might find it interesting. Who opens the calendar and looks at this specific field. If the answer is nobody, the column is documentation of intent rather than a working field.
What decision changes because of it. A field that never changes a decision is a field with no consequence when it is wrong, which is why it goes wrong.
Who updates it, and when. "Whoever is working on it" means nobody. A column needs a named role and a moment, such as the writer at handover or the editor at the weekly pass.
What happens if it is stale. This is the question that kills the most fields. If a stale value is indistinguishable from a correct one, the column will quietly poison every count built on it. A stale status looks exactly like a real status.
A template with six columns that are all true beats a template with twenty where four are.
Almost every working content calendar reduces to these, whatever the tool.
One date, not a range, and it needs to mean one thing. Most calendars fail here by mixing two different dates in one column: the date the team is aiming for and the date somebody has been promised. A slipped aim costs nothing. A slipped promise costs a phone call. If both exist, they need two columns, and the second one should be nearly empty.
Not the final headline. The final headline gets written last, usually at publish time, and waiting for it leaves rows with no name for weeks. A working title that everyone recognises is the identifier the team actually uses in conversation.
Where it goes out. This column is what makes a single calendar usable by people who only care about one output, because it is the filter they apply. Teams that drop it end up with one calendar per channel, and those drift apart within a month.
One person, never a team. A row owned by "marketing" is a row owned by nobody, and it will be the row that is late. If a piece genuinely passes between people, the owner field holds whoever is responsible right now, and it changes hands at each stage.
Fewer values than instinct suggests. Four is usually correct, covered below.
What actually happened, in five words. Published, cut, merged into another piece, held for the product launch. This is the column no template includes and the one that makes last year's calendar useful for planning next quarter. Without it, cancelled ideas get proposed again every six months by whoever did not remember.
None of these are bad fields. Each is worth keeping in one specific situation and worth dropping everywhere else.
| Column | Keep it when | Otherwise |
|---|---|---|
| Target keyword | Search is the main channel and a specific person owns the mapping | Drop it, it belongs in the brief |
| Word count target | Writers are external and paid by length | Drop it, it makes writers pad |
| Persona or audience | More than three genuinely distinct audiences exist | Drop it, everyone picks the same value |
| Funnel stage | Somebody reports on coverage by stage monthly | Drop it, it becomes decoration |
| Priority score | Capacity is regularly short and cuts must be justified | Drop it, the date already encodes priority |
| Approval chain | A regulated industry or client sign off applies | Drop it, one reviewer field is enough |
| Estimated hours | Work is billed or capacity is planned in hours | Drop it, nobody records the actual |
| Campaign name | Several pieces are produced for one launch | Keep it, it is cheap and useful |
The pattern in that table is worth stating directly. A field earns its place when a specific named person reads it on a specific day. Fields added because a template had them are a tax on every future update, and the tax gets paid by whoever is busiest.
Two more that deserve a mention. A link to the draft is usually better as a convention than a column, since the draft location tends to be predictable. A checkbox for "promoted on social" reliably decays, because nobody goes back to tick it after the fact.
The common mistake is eight statuses that describe a production process in detail. Idea, researching, outlining, drafting, internal review, editing, design, scheduled, published. Each additional status is another moment where somebody must remember to move something, and the ones in the middle get skipped, so the calendar shows four pieces in "outlining" that are in fact drafted.
Four states hold up in practice. Not started, in progress, waiting on somebody else, done. The value of the third is that it names the reason for delay in a way the other three cannot, and delay in content work is almost always a wait rather than a lack of effort.
The trap is treating "waiting" as a status without recording who is being waited on. A piece stuck on a legal review, a quote from a customer and a missing image are three different problems with three different fixes, and a calendar that shows only "blocked" produces a meeting in which somebody reads the list aloud and asks what each one is waiting for. A short field next to the status, holding a name, removes that meeting. It is the highest value field most calendars are missing.
A template is half a system. The other half is one recurring ten minute act that keeps it true, and calendars die when that act is never defined.
The pass has three steps and no discussion. First, every row whose publish date has passed gets resolved: published, moved with a new date, or cut with an outcome recorded. Nothing stays overdue, because a permanently overdue row teaches everyone that dates in this calendar are aspirational. Second, every row marked as waiting gets a name checked against it, and anything waiting on the same person for a second week gets chased by the person running the pass rather than raised in a meeting. Third, anything with no movement for two weeks is either given a next action or cut.
What makes this work is that it is one person's job rather than a shared responsibility, and that it happens at a fixed time. A calendar reviewed whenever somebody remembers is reviewed in the week before a launch and never otherwise, which is precisely when the information is least useful.
Two habits help the pass stay short. Adding an idea should be allowed to be lazy, with a working title and nothing else, because a form demanding eight fields means ideas get kept in private notes instead. And the pass should never be the place where new work is planned. Planning and tidying in the same meeting means the tidying gets dropped whenever planning runs long, which is every time.
The measure of whether any of this is working is not how full the calendar looks. It is whether somebody outside the team, asked what publishes next Thursday, can find the answer without asking a person. If the answer requires a conversation, the template is decoration regardless of how many columns are populated.
The right template is not a matter of taste. It follows from how work arrives.
One row per piece, dates as a column, six fields. Reviewed once a week in a pass that takes ten minutes. The whole thing fits on a screen and nothing else is needed. Teams in this situation should resist the more elaborate templates entirely.
The unit is the campaign, not the piece. A campaign name column and a shared date for the launch let the pieces move independently while keeping the deadline that actually matters visible. This is the shape where a board view earns its keep, because the pieces for one launch need to be seen together, and a board that also shows the same items on a calendar avoids maintaining the grouping twice.
Two date columns are mandatory here: the internal target and the date the client has been given. A reviewer field and a sign off state stop being optional. Volume is usually lower and the cost of a miss is higher, which inverts the usual advice about keeping fields to a minimum.
Three additions repay their cost quickly.
The name of the person being waited on, described above.
The origin of the idea. Two words saying where it came from: a sales call, a support ticket, a keyword, a conference talk. Over a year this becomes the only honest evidence about which sources produce work worth publishing, and it takes two seconds to fill in at the moment the idea is added, which is the only moment anybody remembers.
The date of the last movement. Most tools provide this automatically. Its purpose is to surface the pieces nothing has happened to, which is a different list from the overdue pieces and usually a more informative one. A piece with a publish date next week and no movement for three weeks is a different problem from one that is simply late.
Where a team is weighing a spreadsheet against a dedicated tool, the honest difference is rarely the fields, since any tool can hold six columns. It is whether a change reaches the right person, and how much of the history survives. The side by side comparisons set out where each option draws its limits.
Count the columns in the current template and delete every one that no named person reads on a named day, then add a field next to the status holding the name of whoever is being waited on. If the pieces for a single launch need to be seen together as well as on a calendar, keeping both views over the same items removes the duplicate list, which Pinateca does on the free plan for up to five people and ten boards.
Six covers almost every team: publish date, working title, channel, owner, status and outcome. Every additional column is a commitment that somebody will maintain it indefinitely, and the test for keeping one is whether a specific person reads it on a specific day. Templates with twenty columns are not more rigorous, they simply decay in more places.
Four is usually right: not started, in progress, waiting on somebody else, and done. Long status lists describe a production process in detail and then get skipped, which leaves items sitting in the wrong stage and every count wrong. The important addition is not another status but a field recording who is being waited on.
One row per published item, with a column naming the source piece when something is repurposed. That keeps every date accurate and answers the question that comes up in reviews, which is how much output came from one piece of research. The alternative, a column for each channel on a single row, makes it impossible to filter by what goes out on a given day.
In practice the terms are used interchangeably. Where a distinction is drawn, an editorial calendar covers long form publishing owned by an editor, while a content calendar includes social, email and video alongside it. The distinction matters less than keeping everything in one table, since separate calendars for separate channels drift apart within about a month.
Once a week, at a fixed time, by one named person. Continuous updating sounds better and produces worse data, because a calendar that expects attention from everyone gets it from nobody. The weekly pass has one job: make the status column true, and identify anything waiting on a person outside the team.