A permit-review explainer published after the local application deadline may be accurate, but it arrives too late to help a client. An editorial calendar needs to track more than topics: it should show what a prospective client needs to decide, when the question is likely to arise and whether the firm has verified enough information to answer it.
For an architecture practice, consistent publishing does not mean posting at a fixed rate regardless of project demands. The aim is to build a useful body of guidance on design, approvals, costs and building operation, then revise it as requirements and practice change. The calendar is a working plan, not a promise that every project will become a case study.
Start with the decisions readers actually face
A developer assessing a constrained site needs different information from a school operator planning an extension. Before setting publication dates, list the decisions each audience faces: whether a site can accommodate the brief, how to set an initial budget, when to seek regulatory advice, which construction approaches to compare and what to prepare for after handover.
Use those decisions to group topics. An early site assessment could lead to an article on checks to make before commissioning a concept design. During detailed design, a piece might explain how changes to the brief affect cost and programme. A question about operations could become an explanation of how maintenance access is planned before equipment is installed. Give each article one identifiable question rather than an entire building type to cover.
Enquiry calls, meeting minutes and repeated requests for clarification are good sources. Note the reader’s question in their own terms, but leave out project-specific details unless you have permission to share them. If architects regularly have to explain the difference between an early cost estimate and a priced construction package, that is a stronger topic than one chosen simply because it sounds timely.
Give every planned piece a job
For each idea, record its main purpose: to explain a decision, clarify a process, show a method or correct a misconception. Add the intended reader and project stage. Those details help prevent several articles from answering the same broad question. A feasibility article, for example, need not become a guide to every step in a permit submission.
A defined scope also makes an assignment easier to write and review. “Sustainable design” leaves too much open. “What building-load information is needed before assessing a ground-source heat pump” points to both the question and the technical reviewer. If the post needs more background than it can reasonably carry, an existing resource such as the guide to ground-source heat pumps, building loads and site conditions can supply it without repeating the same material.
Plan around project evidence, not just seasons
Architecture content often depends on material that cannot be produced on demand. A completed project may still be waiting for approved photography, client permission, measured performance data or a final account suitable for discussion. Put those dependencies on the schedule. Do not give a case study a fixed slot just because the calendar calls for a practical example that month.
Keep two queues. One holds evergreen explainers based on verified standards, established practice and carefully qualified examples. The other holds project-dependent stories, which advance only when the facts, approvals and images are ready. If a case study stalls, a reviewed explainer can take its place without forcing the team to publish an incomplete account.
Project milestones are still useful prompts. Budget approval, design development, permit submission, construction and early operation each raise different questions. Capture possible topics while the reasoning is fresh, then decide what can be shared. Keep the hoped-for draft date separate from the date a story is cleared to publish.
Build a schedule the team can maintain
Begin with the time the team actually has, not a target posting rate. A technical article may need an interview, a draft, specialist review, fact-checking, client approval and image permissions. Use a few trial pieces to estimate that work before committing to a regular schedule. One reliable article a month can serve readers better than four rushed posts followed by a long silence.
A spreadsheet or shared project tool is enough for the planning record. Include the fields that expose blockers; leave out anything the team will not maintain.
- Working title and reader question: the decision the piece helps clarify.
- Audience and project stage: for example, an owner assessing feasibility or a facilities team preparing for handover.
- Evidence and reviewer: drawings, approved project facts, applicable requirements and the person qualified to check them.
- Permissions: client approval, photography rights and confidentiality restrictions.
- Status and dates: draft and review deadlines, approval status, publication window and next review date.
- Outcome: what the team will look for after publication, such as relevant enquiries or recurring questions the article helps resolve.
Keep a small reserve of drafted, reviewed material for delays such as a postponed site visit or a client taking longer to approve a project account. Do not let it sit indefinitely: technical statements can age even before publication.
Separate the editorial deadline from the publication date
Work backwards from the intended publication date. If a post needs a project architect and a cost consultant, give each a review window and a clear task. The architect might check the design sequence and terminology; the consultant might check how an estimate is described. Allow time to revise the draft after both reviews. An entry that says only “publish Friday” hides the work required to make that possible.
One editor should reconcile comments and control the final version. Several technical reviewers may be needed, but conflicting edits should not remain in the draft until publication day. If a fact cannot be confirmed, qualify or remove the claim rather than keep an uncertain detail to meet the date.
Use an editorial mix without making every post a sales pitch
Mix process explainers, decision guides, documented project accounts and updates to older material. Readers often need help with a trade-off long before they are ready to commission design work. A piece on natural light, for instance, is more useful when it distinguishes helpful daylight from glare and unwanted heat than when it praises large windows. The existing guide to daylighting, glare and heat in building design shows the value of a specific question.
Apply the same care to project stories. State the initial constraint, the options considered, the decision made and what the available evidence confirms. For a recently opened building, do not present predicted energy use as measured performance. If construction costs changed, explain the scope and timing before comparing figures. Those limits tell readers more than an unsupported claim of success.
Keep promotion separate from practical guidance. Someone trying to understand permit sequencing should not have to search through a firm's credentials for the answer. Accurate explanations and transparent examples can demonstrate competence without turning the article into an advertisement.
Make review dates part of the calendar
An article can become misleading after publication. Requirements, approval procedures, product specifications and project details change. Set a review date when the piece is approved, and review material tied to local rules or current costs sooner. A general design principle may remain useful longer than an account of a submission procedure.
At review, check the details a reader might rely on. Has the named approval process changed? Does a cost example still give its location, date and scope? Are the project images still cleared for use? Make substantive corrections in the article and record what changed. If its premise is obsolete, withdrawing it may be better than adding a brief note.
Review the calendar at a regular editorial meeting, too. Compare what was planned with what was published, then look for the cause of missed slots. Repeated delays in technical review point to a capacity problem; repeated waits for client consent suggest project stories are being scheduled too early. Change the process rather than asking contributors to meet dates that ignore those dependencies.
Measure whether the calendar helps readers and the practice
Page views cannot, by themselves, show whether an article reached the right audience. Look at whether readers find pieces relevant to their decisions, whether enquiries mention a question the content addressed and whether colleagues use an article to explain a recurring point in meetings. Consider those signs alongside publishing consistency and the work each piece required.
Be cautious about cause and effect. A specialised article on healthcare service routes may get fewer visits than a broad home-design post and still serve its intended readers. An enquiry after publication does not prove the article prompted it. Look for patterns over several months: more informed questions, fewer repeated explanations or subjects that still need clearer treatment.
At the quarterly check, note what was published, what slipped, why it slipped and which reader questions remain unanswered. Suppose three recent feasibility enquiries asked how survey findings affect a project budget. That is a concrete next assignment: give the question to an author, identify a cost reviewer and reserve a publication date once both can do the work.