A small desk needs an editorial calendar that answers practical questions in seconds: what is being made, who owns the next move, when is it due, and what blocks publication? A plain table with a few maintained fields is a practical place to begin.
Use one row per publishable item
Create fields for working title, audience question, format, owner, editor, stage, draft date, publication date, primary source, and blocker. Add a URL after publication. If a field never changes a decision, remove it. Long forms discourage updates and drive the real status back into private messages.
Define a short stage list: pitched, approved, assigned, drafting, editing, fact check, scheduled, published, and updating. Every stage should imply one owner and one next action. “In progress” is too vague because a writer, editor, and designer can each imagine that somebody else has the piece.
Plan capacity before topics
Count the hours available for reporting, drafting, editing, production, and updates. Reserve part of that capacity for unplanned work and corrections. Then choose a sustainable publication volume. A small desk that can finish two strong pieces each week should not maintain a calendar that assumes five.
Use a rolling six-week view. The near two weeks should be specific and assigned. The middle two should have approved briefs and sources. The final two can hold shaped candidates. This keeps the desk prepared without pretending that every distant title is final.
Run two short meetings
Hold a weekly planning meeting to select work, resolve conflicts, and confirm capacity. Hold a brief production check later in the week to discuss only blockers and changed dates. Read the calendar before the meeting. Do not turn the call into a spoken version of rows everyone can already see.
End each meeting by recording decisions in the calendar. A side conversation that changes a due date is not complete until the row changes. That habit gives freelancers and part-time contributors a dependable source of truth.
Review the system monthly
Measure on-time publication, revision rounds, stalled stages, and update debt. Read the results as process signals, not employee grades. A repeated delay in fact checking may mean the briefs lack sources. Several late approvals may mean the approver has too many pieces at once.
Put six real assignments into the view
Use a small pilot rather than importing every idea the team has ever discussed. For each of the next six pieces, name the reader question and write the next action as a verb: confirm interview, review outline or approve final text. A working title alone does not tell a contributor what to do. A date alone does not show which dependency could prevent completion.
Take an illustrative two-person desk publishing twice a week. Its first week might contain a reported guide and a short reference. The guide needs an interview before drafting can finish; the reference needs an expert to check its examples. Record those dependencies in the same view as the planned publication date. Otherwise both pieces can appear on track until the final afternoon.
Use a stable assignment identifier or link to the brief so that a title change does not detach comments and source notes. The calendar should point to the actual work rather than duplicate a draft inside a spreadsheet cell. Keep sensitive interview material in the appropriate working record, with access suited to that material.
Plan backward from a credible release date
Choose dates for evidence, draft, review and production based on who is available. A Tuesday publication may require approval the previous Friday if the expert reviewer is unavailable on Monday. Moving the last date without moving its dependencies merely conceals a late assignment. When a date changes, check every piece that relies on the same person.
Add a small buffer for tasks the desk repeatedly underestimates. For one publication that may be image permissions; for another it may be technical verification. Do not copy a generic percentage into the plan and assume it fits. After several cycles, compare the actual delay with the original assumption and adjust the next set of assignments.
Make blockers specific enough to resolve
“Waiting” is a status with no instruction. “Waiting for the editor to confirm the quoted figure” identifies a decision and a person. Add the date the question was raised and the fallback if it remains unanswered. The fallback might be removing a claim, replacing a planned article or delaying publication. It should be an editorial choice, not an accidental consequence of silence.
A blocked assignment still consumes attention, but it should not hide the capacity of the rest of the desk. Limit the number of pieces that can wait at each stage. If too many drafts reach review together, change the assignment pattern. Asking writers to draft faster will not fix a bottleneck in approval.
Keep a replacement item genuinely ready
A spare article is useful only if its evidence and production needs have already been checked. Maintain a small ready queue for times when an interview falls through. Label which items remain timely and which require a source refresh. A list of undeveloped ideas is not a replacement queue, because it still needs the same work the delayed article could not finish.
For a website and newsletter publishing together, distinguish editorial approval from delivery setup. Ghost's email documentation includes preview and delivery operations. Whatever software the desk uses, record who checks the actual web preview and test email. A completed draft and a correctly configured release are separate milestones.
Make updates visible work
Reserve calendar rows for revisiting important older material. Add the original URL, the reason for review and the scope of the check. An article about a changing tool may need the process repeated; a reference might need a broken link repaired. The responsible editor should be able to tell the difference before assigning the work.
Do not clear an update task merely because its date has been refreshed on the public page. The source record should show what was checked and what changed. This protects the desk from an expanding archive of apparently current pages whose instructions nobody has recently tested.
Review the calendar by asking better questions
At the end of the pilot, look for patterns rather than individual blame. Which assignments changed scope after drafting began? Where was the source request late? Did a task spend longer waiting than being worked on? Those questions identify a process change the team can try during the next cycle.
Keep the fields that helped answer a real question and remove ones everyone ignored. A shared calendar works when contributors can maintain it during an ordinary busy week. After two weeks, each person should be able to open it and identify the next decision without asking for a separate status report.