Editorial calendar software: fields, states, lead time

Editorial calendar software is a shared schedule where every planned piece of content is a record with an owner, a status, a stage deadline and a publish time. It is more than a title sitting on a date. Choose it by what that record has to hold and how many handoffs it has to survive. One writer shipping four posts a month can run the whole thing in a spreadsheet. Once a second person starts moving drafts between stages, a tool where changing a status takes one action and the next owner is told automatically usually pays for itself.

Drawing a month grid is the easy part. Nearly any tool can do it, a spreadsheet included. The hard part is keeping the date honest after the draft slips, the approver is out for a week and the slot moves. So this evaluation skips the calendar view and looks at what sits underneath it: the record, the states, the lead time, and a scorecard you can use during a two-week trial.

The record behind every calendar entry: 12 fields

A calendar entry is only as useful as the fields behind it. The table below is the minimum record to set up before trying any tool. Each row names the specific thing that goes wrong when that field is missing.

Plan fields and production fields move at different speeds

Fields 1 to 5 are plan fields. Someone sets them when a topic is accepted, and after that they should barely move. Fields 6 to 11 are production fields, and they change every few days while a piece is being made. Field 12 connects the two: the planner sets it, and production moves it.

This split gives you a practical test for a trial. Suppose a writer has to open the same long form a planner uses for new topics just to push a deadline back two days. Then the update competes with the actual writing, and the update loses. Look for a tool that lets you edit production fields straight from the board or list view.

Store publish times with an offset, and check the week of 25 October

A publish time without a time zone works fine until the clocks change. A slot stored as 07:00 UTC goes live at 09:00 in Berlin during summer time. After EU clocks go back on Sunday, 25 October 2026, the same slot goes live at 08:00. The US follows on Sunday, 1 November 2026, so for that one week Berlin and New York are five hours apart instead of six.

Many teams store a recurring "9:00" slot as local time with no zone. For a distributed team, every such slot is ambiguous that week. The fix is dull but worth doing: store timestamps with an explicit offset and show them in each viewer's local time. SEO Autopilot stores the slots in its own schedule this way, for example `2026-09-15T06:30:00+00:00`.

Six states and two exits, each with an entry condition

A status model is the fixed list of states a piece can be in, plus the rule for entering each one. The rule is the part that matters. A label only tells you where someone dragged a card. An entry condition tells you what is actually true.

Two exits sit outside the main line. Blocked needs a reason and the name of someone who can unblock the piece. Killed needs a reason, and it frees up the keyword so another piece can target it. The thresholds in the last column are starting values, not norms. Adjust them once you have a month of your own data.

Why "In progress" is the first state to delete

"In progress" merges Drafting and In review, and those two states have different owners. Say a piece has sat in "In progress" for nine days. The writer could be late, or the approver may never have opened it, and the calendar cannot tell you which. Split the state, and every stall points at one person.

Count the status changes before you choose a tool

With six forward states, each piece goes through five status changes. Add one date change per piece for a single slip. Then assume each update takes two minutes: find the row, change it, tell the next person. Here is the monthly bookkeeping:

The minutes are not the real cost. The real cost is the updates that never happen, because each skipped one makes the calendar a little less accurate. The decision rule: if one person makes about 40 status changes a month or fewer, a spreadsheet with a dropdown status column is enough. Past that point, or as soon as a second person moves pieces between states, choose software that notifies the next owner when the status changes, so nobody has to send a message.

Lead time: plan backwards from the week the post should be visible

In this article, lead time means the days between locking a topic and the post showing up in search. A calendar that tracks only the publish date hides the first part of that span. That is how a seasonal post ends up landing after its season.

The model below has two inputs. Production takes 10 calendar days: brief 1, draft 4, review 3, revise and schedule 2. Visibility is assumed to take 35 days, because the planner that generated the brief for this article assumes roughly that gap between publishing and appearing in search. Added together, a topic has to be locked 45 days before the week it should be seen. On a five-day working week, the 10 production days stretch to 14 calendar days, which makes 49.

If you are planning in October, read the first row closely. A post meant to support a late-November promotion needed its topic locked in the first half of the month. If that date has passed, this year's search window is most likely gone. Spend this year's effort on email, the pricing page or in-product messages instead. Then create next year's calendar entry now, with its lock date already set.

For October and November planning, the second row is the useful one. Anything meant to be found in the first week of January has to be live by the end of November. If your approvers are away between Christmas and New Year, keep review deadlines out of that week entirely.

Measure your own publish-to-visibility gap

The 35 days is a planning assumption from one pipeline. Search engines do not work to it, and your site may be faster or much slower. To measure your own gap, take your last ten published posts and note each publish date. Then open the Performance report in Google Search Console, filter by each page and find the first day with impressions. Use the median, not the average, because one post that took four months will pull an average far off.

Build the result into the calendar as a default lead time that new entries inherit. It should not live only in one person's head.

Where the tool should do the arithmetic for you

A tool that stores one date per item pushes this calculation somewhere else, usually a spreadsheet next to the calendar. After the first slip, the two disagree. During a trial, check for three things:

• Stage dates that shift, or get flagged, when the publish date moves
• A lock date field or a computed deadline
• A saved view along the lines of "lock date within 14 days, status still Planned"

Five kinds of editorial calendar software, and when each fits

Tools sold as editorial calendar software rest on different ideas of what the calendar is. That idea shapes daily use more than any feature list does.

The examples are there to help you build a shortlist, not to rank anything. Features and plans change, so check each point against the vendor's current documentation during your trial.

When a spreadsheet is enough

A spreadsheet is enough for one editor, one channel and about 40 status changes a month or fewer. Add data validation to the status column so free-text states like "nearly done" cannot creep in. Add a "last updated" column so stale rows stand out. The spreadsheet usually stops working the week a second person starts changing statuses without telling the first.

When a work-management board fits

If launches, campaigns and sprints already live in one tool, a separate calendar product just adds another place to check. Trello and Asana both market this use directly. Trello's editorial calendar use case presents boards as a command center for content curation, revisions, handoff and publishing. Asana's content calendar page describes planning the calendar and tracking content production in one place.

You still have to define your own record: the 12 fields, the entry conditions and the lock-date view. Budget a working day for that setup, and name one person who owns the template afterwards.

When the calendar should trigger the work

In a pipeline model, the slot is not a reminder for someone to start. The slot itself starts brief generation, drafting and the pre-publish checks. This fits teams that publish on a fixed schedule and would rather maintain rules than chase handoffs. It fits poorly when most pieces depend on an expert interview, legal sign-off or custom design, because a slot can schedule a job but not a person. Publishing control plane software: state machine, gates, break-even explains how the states and gates in that model are designed.

What to check before relying on a free plan

A free tier is a reasonable place to run the trial script below. It is a risky place to keep a calendar your publishing depends on. Before you commit, check these limits on the vendor's current pricing page on the day you decide:

• Number of seats, and whether guests or approvers count as seats
• Caps on items, cards or records
• Whether the calendar or timeline view is included at all
• Automation runs per month
• How long version or activity history is kept
• Whether full export is available

A 100-point scorecard for a two-week trial

Give each criterion full points, half points or zero. The weights follow the failure points covered in this article: status model and slip handling first, integrations after.

The decision rule: under 60, drop the tool. From 60 to 79, it can work for a single-channel team with one editor. At 80 or above, it goes on the shortlist. These cut-offs are a working rule, not an industry standard. Move them if one criterion is a hard requirement for you.

The trial script: five real posts, five deliberate problems

Load five real upcoming posts, not sample data. Then break things on purpose:

1. Push one publish date back by seven days. Count how many other fields you had to edit by hand.
2. Reassign the owner of a piece in Drafting. Check whether the new owner was notified and whether the history shows the change.
3. Kill a piece. Check whether its keyword is clearly free again or whether the dead item still takes up the slot.
4. Schedule a post for 09:00 in a second time zone during the week of 25 October. Confirm that both people see the correct local time.
5. Export everything and open the file. Check whether it contains status history and past dates, or only current values.

Time each task. If a task takes more than ten minutes in a calm trial, assume it will be skipped in a busy week.

Security questions before unpublished plans go into a cloud tool

An editorial calendar holds things you are not ready to publish: launch dates, draft pricing pages, customer names for case studies. Ask the vendor:

• Where is the data hosted?
• Who on the vendor's side can access it?
• Are single sign-on and role permissions available on the plan you would buy?
• How does a complete export work if you leave?

For a structured list of questions, borrow from the Cloud Computing Compliance Criteria Catalogue (C5) published by Germany's Federal Office for Information Security, which cloud customers can use to compare providers' security (BSI, C5 criteria catalogue). Treat the vendor's answers as statements to confirm in the contract.

Where editorial calendars break

Dates nobody believes. Every Monday, count the pieces whose stage due date has passed with no status change. If that is more than one in five, the team is working from somewhere else and the calendar has become decoration. Fix owners and entry conditions before buying anything new, because a new tool inherits the same habits.

A graveyard in Planned. Cap the Planned state at three months of capacity. At eight posts a month, that is 24 items. Everything beyond that goes on a backlog list that stays off the calendar, so the calendar shows commitments rather than wishes.

Two owners on one card. When a writer and an editor are both listed as owner, neither of them owns the status. Keep one owner per state, and hand the piece over at each transition.

The calendar and the CMS disagree. If someone copies the publish time into the CMS by hand, the two drift apart at the first slip. Pick one direction: either the calendar writes to the CMS, or the CMS is the source and the calendar reads from it. Content operations software: evaluate it by where the work stops shows how to find the queue where this kind of drift starts.

No refresh date. A post reaches Published and drops off the calendar for good. Set the refresh date as part of the Published transition, not as a cleanup task for later.

How the schedule works when it drives the pipeline

In SEO Autopilot, the calendar is a list of slots. Among other fields, each slot carries a keyword, a locale, a cadence, a source, a status and a scheduled time with offset. There is no "Drafting" card for anyone to drag: the slot ties a keyword to a pipeline run of brief generation, writing and the pre-publish gate. If a draft fails the gate, it is held for human review instead of going live at the scheduled time.

The brief for this article shows the lead-time idea at work. It was generated on 14 September 2026 with a note that the post would become visible in roughly 35 days. That is why the examples here fall in late October and November rather than September.

The trade-off is the one from the table above: you give up hand control over each piece and maintain rules instead. If your bottleneck is approvals rather than dates, read Editorial workflow software: evaluate, choose, and implement before you choose a calendar at all.

FAQ

How do I create an editorial calendar?

Start with the record, not the tool. Define the 12 fields and the six states with their entry conditions, then fill in no more than three months of capacity. Set each topic's lock date by counting back from when it should be visible: production days plus your measured publish-to-visibility gap. Run the calendar in a spreadsheet for a month, and move to software once a second person changes statuses or you pass about 40 status changes a month.

What is the difference between an editorial calendar and a content calendar?

The terms overlap, and vendors use them interchangeably. A workable distinction: an editorial calendar tracks each piece through production, with owner, status and stage deadlines. A content calendar shows what goes out on which channel and when, often including social posts. If your tool covers only the content calendar side, you still need somewhere to keep the production view.

What to include in an editorial calendar?

At minimum, include these fields:

• Working title, keyword or topic, and angle
• Channel and locale
• Owner, status and stage due date
• Brief link, draft link and approver
• Publish date and time with time zone
• Refresh date

Add a reason field for Blocked and Killed items. Leave out any column nobody will update weekly, because a column that sits empty makes the others look optional too.