The short version
- A communication plan is one page that answers: which channel, how fast, and who decides. Anything longer will not be read.
- The failure it prevents is the most common one on distributed teams: everything gets sent the same way, so everything reads as equally urgent.
- Channels need a stated response time. A channel without one becomes the fastest channel by default, which is how phones start buzzing at 23:00.
- Add one row most plans miss: where to look before you ask a person at all.
A team spread across three countries needs a written agreement covering four things: which channel carries which kind of message, how quickly each channel is answered, who decides what, and where to look before asking a person. Four things, one page, reviewed quarterly. Everything beyond that is decoration.
"Nobody knows which channel means urgent."
Why most communication plans fail
They fail for three reasons and all three are avoidable. They are too long, so nobody finishes reading. They describe tools rather than expectations, listing which platforms exist without saying what each one obliges you to do. And they contain no response times, which is the single most important thing in a plan and the thing most often omitted.
Without response times, people calibrate by guessing, and guesses default upward. If there is any chance a message is urgent, the sender picks the loudest channel and the receiver checks everything constantly. That is how a team ends up with four channels that all function as an alarm.
The template, one page
Copy this and change the names. The response times are examples, but the discipline of having one per row is not.
| Channel | Use it for | Answered within |
|---|---|---|
| Team channel | Anything the team benefits from seeing | One working day, sender's zone |
| Direct message | Personal, sensitive, or one-to-one only | One working day, recipient's zone |
| Ticket or board comment | Anything about a specific piece of work | Next working day |
| External parties, records, long-form | Two working days | |
| Phone or paging | Production is broken, defined below | Fifteen minutes, on-call person only |
| Their StandIn | Status and context questions, any hour | Immediately, from what they wrote down |
Underneath the table, three lines. Working hours per person in their own local time. The named decider per area. The current on-call person and how to reach them. That is the whole page.
Defining urgent so the word means something
Urgency inflates unless it is defined by consequence rather than by feeling. Write the definition down and keep it short.
A workable version: urgent means customers are affected right now, or a deadline today fails without an answer in the next hour. Everything else is important, which means it gets answered during the owner's working hours. Two categories, not five, because five categories collapse back into two within a month.
Then hold the line where it is hardest. The test of an urgency definition is the first time a senior person's non-urgent request is treated as non-urgent. If that request jumps the queue because of who sent it, the definition is decorative and everyone will learn that within a week.
The row most plans miss
Every plan tells people where to send a question. Almost none tell them where to look first, which means the default answer to any uncertainty is to interrupt a person, and across three countries that person is frequently asleep.
Add one line to the plan, above the channel table: ask their StandIn before you ping them. Each person spends ninety seconds at the end of their day on a brief, mostly drafted from the work they already did. While they are off, their StandIn answers questions from it in their words, with a source under every answer, clearly labelled, and never guessing. If the answer is not in the brief, it says so and names who to ask, which is when a human ping is genuinely warranted.
That one row changes the arithmetic of the whole plan. Status questions stop needing a response time, because they stop needing a person, and the response times you publish for the human channels become promises the team can actually keep. See working across time zones.
Rolling it out without a launch
Do not announce it as a policy. Write the page, put it in the team channel topic and the onboarding checklist, and then do the only thing that makes any norm real: redirect gently and in public when someone uses the wrong channel. "Putting this in the ticket so the whole team can see it" costs nothing and teaches more than a document.
Review it once a quarter, and delete a row whenever you add one. Communication plans die of accumulation. If your team also needs channel-level etiquette, pair this with Slack norms a team actually keeps.
Common Questions
How long should a communication plan be?
One page, and it should be readable in two minutes. Anything longer is a policy document, and policy documents are read once during onboarding and never again. The test is whether a new joiner can use it in week one without asking what it means.
Should response times be in working hours or elapsed hours?
Working hours, in the recipient's own time zone, always. "Within one working day" means something fair across three countries. "Within 24 hours" quietly obliges someone to answer at midnight.
What if someone ignores the plan?
Redirect in public and without friction, every time, for the first month. Norms are established by consistent small corrections, not by escalation. If a senior person is the one ignoring it, fix that first, because everyone is calibrating on their behaviour rather than on the document.
Do we need a separate plan per country?
No. One plan, with working hours listed per person in local time. Separate plans create seams between the seams, and the point of the page is that anyone can predict what happens to their message regardless of where it is going.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.