Communication Plan Template for Releases

A communication plan is easy to write and easy to write uselessly. The test isn't whether it covers the release. It's whether it holds up on the night the release goes wrong.

Aldermoor Health's auth cutover had a communication plan with eight rows: pre-announcement, integrator notice, support brief, on-call heads-up, status page during, status page after, leadership summary, internal engineering note.

All eight were sent, on time, to the right people. By its own measure the plan executed perfectly.

At 02:40 the cutover was rolled back. The plan had nothing to say about that. There was no row for we tried, it didn't work, you're back on the old version, and here's what that means for you. Someone spent ninety minutes drafting that message at three in the morning — and it went out four hours after customers had started noticing on their own.

The plan is judged on the worst night, not the good one

The announcement rows are the easy half. They're written in daylight, by someone with time, for an event that hasn't happened yet. They are also the rows that would mostly have been fine as an ad-hoc Slack message.

The rows that earn the artifact are the ones you write hoping never to send, because those are the ones you'll need when nobody has ninety minutes:

The row	Trigger	Why it can't be written live
Rolled back	Cutover abandoned, old version restored	Needs legal/support sign-off, and it's 3am
Degraded but up	Shipped, but something is slower or partly broken	Hardest to word — must be honest without sounding worse than it is
Running long	Window exceeded, still going	Sent while everyone is busy doing the thing that's running long
All clear	Verified stable	Easy to forget entirely once the pressure lifts

Aldermoor's plan had the last one. It had none of the first three.

The test you can run: open your most recent release's communication plan and count the rows that assume the release worked. If that's all of them, the plan covers the outcome you didn't need help with.

The field everyone fills in wrong is Timing

Almost every plan writes timing as a date or an offset — T-7d — chosen by feel, or by whatever the last release used.

That's backwards. A lead time isn't your deadline. It's the audience's, and its length is set by what they have to do with the notice.

Audience	What they must actually do	So the lead time is	If it's shorter
API integrators	Ship a code change through their release cycle	14–30 days	They break, and find out from their own customers
Support	Read a runbook and be able to answer "I'm locked out"	3 days	They improvise, inconsistently, on the busiest call day
On-call	Be awake, informed, and not mid-holiday	The shift before, plus the rota check a week out	The pager goes to someone with no context
Customers, nothing to do	Be unsurprised	24 hours is plenty	Mild annoyance, no real cost
Customers, must act (re-auth, re-consent)	Take a manual step	7–14 days, then a reminder	Support absorbs it as ticket volume

Notice the last two rows are the same people and different answers. The audience doesn't set the lead time; the action does.

The test: for each row in your plan, name what that audience does with the notice. If the honest answer is "nothing, they just need to know", the lead time is courtesy and can shrink freely. If the answer is an action, the lead time is that action's duration plus slack — and it is not negotiable downward because the release date moved.

Pre-drafting is the artifact, not the table

The table is a routing decision. The thing that saves you at 02:40 is text that already exists and has already been approved.

Approval is the slow part, and it's slow for exactly the messages you need fastest — anything customer-facing usually wants support, legal or a comms owner to look at it. At three in the morning none of them are awake.

So the four failure messages get drafted and approved with the plan, not during the incident. Aldermoor's now live in the release doc as filled text, with the variables marked:

• Rolled back — what happened, what state customers are in now, whether they need to do anything, when you'll try again. That last clause is the one people forget, and it's the one that stops the follow-up questions.

• Degraded — what specifically is affected, what still works, and what you're doing. Naming the working parts is what keeps it from reading worse than it is.

• Running long — new expected time, and a commitment to the next update even if there's no news.

• All clear — short, and sent to everyone who got any of the others.

Each of the four needs a named sender, not a team. "Support will send it" is how a message doesn't get sent at 03:00 — and if the owner column of your plan is a list of teams rather than people, that's the same gap the RACI exists to close.

The test: for your next release, ask who would approve the customer-facing rollback message. Then check whether they've seen it. If the answer is "they'd approve it in the moment", you have a plan that depends on a person being reachable at the worst possible hour.

Match the channel to whether it interrupts

Channel choice is usually treated as a style question. It's an interruption question: some channels reach people who aren't looking, and most don't.

A breaking API change announced only in a Slack channel has technically been communicated and practically has not — integrators don't read your Slack. A pager note reaches someone at 3am; an email doesn't. A status page reaches people who already suspect something is wrong, which makes it the right instrument during an incident and the wrong one for advance notice.

The rule that falls out: the more the audience must act, the more the channel has to interrupt. Advance notice of a breaking change goes by email and into the docs and to the account contact. A behind-the-scenes deploy goes in one channel and nobody minds.

The test: for each row, ask whether that audience would see the message without going looking for it. If not, and they have something to do, the channel is wrong regardless of how well the message is written.

When the full plan is the wrong instrument

Running this for every release trains people to fill it in without reading it, which is worse than not having one.

• Nothing customer-visible and nothing to coordinate. One internal note is the whole plan. Writing eight rows for a routine deploy is how the template earns its reputation.

• The change is behind a flag. The communication belongs at the flag flip, with the audience who'll actually notice — not at the merge.

• A genuine emergency. You're communicating live, from the incident, not from a table. The plan's job here is only to have supplied the pre-drafted degraded and all-clear text.

• The audience is one team you can walk over to. Coordination that involves nobody else is a conversation. Keep the change record — skip the plan.

Where it always earns its cost: anything with an external audience, anything where a rollback would be visible, and any migration with a cutover window.

The test: if this release were rolled back, would anyone outside the team need to be told? A yes means write the plan. A no means one line in the release notes.

What to change this week

Don't build the template. Take the plan for your next release and add one row: rolled back.

Write the actual message — not a placeholder — and get it approved by whoever would have to approve it at 3am. That single row is most of the value of the whole artifact, and it's the one nearly every plan is missing.

Then, for the rows you already have, replace each timing offset with the reason for it. Any row where you can't name what the audience does with the notice is a row whose lead time was guessed.

Aldermoor's plan is eleven rows now. Three of them have never been sent. The rollback row was used once, seven weeks later, on a different release — and the message went out nine minutes after the call, because it already existed.