Practical Guides · 4 October 2026
A content calendar needs states, not just dates
A publishing date can create the appearance of control while the copy, visual, approval or platform confirmation is still unresolved. A small state-based workflow makes the real next action visible.
By María José Ospina · 4 min read

In this article
A date is a promise; a state is evidence
A content calendar is useful, but it answers only one question: when do we want this to go out?
That is not the same as knowing whether the item can move. A post dated Tuesday may still be waiting for a photograph. A Thursday article may have finished copy but no verified source. A Friday carousel may have approval for the wording but not for the exact visual pairing. All three look planned in a calendar, yet none is ready for the same reason.
This is where a simple workflow earns its place. The point is not to turn a small creative team into a software department. It is to separate intention from evidence. A date records the intention. A state records what has actually happened.

Six states are enough for most content teams
The labels should fit the work, not a fashionable tool. For a small studio or in-house team, six states usually provide enough clarity:
1. Captured
The idea exists with a purpose, an intended audience and a source or brief. It is not yet a commitment to publish. This is where loose ideas belong, without pretending they are production-ready.
2. In editing
One person owns the working draft. Copy, footage, design or web content is being shaped. The item should have one named next action, not a cloud of general responsibility.
3. In review
The reviewer can see the complete decision: exact copy, exact visual, intended account and planned time. “Please approve the caption” is not sufficient when the image can change the meaning.
4. Approved
The decision is recorded. If the item changes materially, it returns to review. This boundary matters: Metricool's current approval guidance says editing a post after it has been sent for review resets the earlier review. Its documentation also distinguishes pending, approved and rejected states rather than treating a calendar date as approval.
5. Scheduled
The platform or publishing tool has accepted the item for a specific time. Keep the returned identifier or planner record. This is a delivery receipt, not proof that the public post exists.
6. Published
The live item has been checked on the public destination. The correct text and media are visible, and the public URL or platform record has been retained.
“Blocked” works best as an exception across the board, not a seventh destination. Add the reason: missing photograph, unresolved source, owner approval, account connection or platform failure. A blocker without a reason is just a quieter form of delay.

Review is the bottleneck worth protecting
Most teams do not run out of ideas. They accumulate unfinished items around feedback and approval.
Atlassian's guidance on work-in-progress limits makes a useful point beyond software development: setting a maximum for each active state makes inefficiency easier to see. Applied to content, that could mean allowing only three items in review at once. When the column is full, the priority is to finish a decision, not add another draft.
This does not mean every team needs formal Kanban practice. The underlying decision is simpler: limit the number of items that require attention at the same time. A visible queue makes it harder to mistake activity for completion.
There is another practical reason to protect review. Metricool's help centre says a post still pending approval at its scheduled time receives a three-hour grace period; after that, it remains unapproved and is not published. The specific platform rule may change, but the operational lesson is stable: a date cannot substitute for a decision.
The minimum viable board can be a table
The counterpoint is important. A six-column board can become theatre if nobody updates it. Complex software, colourful labels and automations do not rescue unclear ownership.
A shared table is enough if it contains: item, intended account, date, state, owner, next action, approval evidence and live link. The process should be smaller than the work it supports.
The test is whether someone can open the board and answer three questions without a meeting:
- What is genuinely ready?
- What is blocked, and why?
- Who makes the next decision?
If the board cannot answer those questions, adding more dates will not fix it.
A 20-minute Sunday reset
Before the coming week begins:
- Close published items and add their live links.
- Mark every blocked item with one specific reason.
- Give each active item one owner and one next action.
- Limit the review queue; finish decisions before adding more.
- Protect the first 48 hours of the week from speculative additions.
The business decision is straightforward: plan the flow before filling the calendar. Dates coordinate attention. States prevent a team from calling unfinished work ready.
Sources
- Working with WIP limits for Kanban
- How to send posts for review with Metricool's approval system
- How to approve or reject a scheduled post in Metricool
- Kanban board example — Dr Ian Mitchell, 13 July 2012, CC0 1.0 · 2012-07-13
- Sample Kanban Board — Andy Carmichael, 21 January 2017, CC BY-SA 4.0 · 2017-01-21
0 likes
0 comments
Working on something this applies to? Tell us.
Start a project