Communication Plan Template: Who Needs What, When, and Why
Download a practical project communication plan with audience, channel, timing, ownership, response expectations, and a complete worked example.
A project communication plan states who needs information, what they need to do with it, where it will appear, when it is due, and who sends it. Add a response expectation and an escalation route. Without those, an update can be delivered correctly while the decision it needs never happens.
Make the next useful action obvious to the right person.
What belongs in the plan?
Create one row for each distinct audience and communication purpose. Two groups may use the same channel but need different detail, timing, or decisions, so a single “send everyone an email” row rarely tells the whole story.
Download the communication plan. This editable text file contains the fields, a completed example, and an escalation message. You can use it without creating an account or adopting a new app.
| Field | Question to answer |
|---|---|
| Audience | Who needs this information? |
| Purpose | What should they understand, decide, or do? |
| Message | What information supports that purpose? |
| Channel and record | Where is it sent, and where is the current version kept? |
| Timing | Is it recurring or triggered by an event? |
| Owner | Who prepares and sends it? |
| Response | Is acknowledgment, approval, or no reply expected? |
| Escalation | What happens if the response is missing or circumstances change? |
Asana's communication planning guide identifies audience, message, channel, frequency, and owner as core elements. Our additional response and escalation fields make the handoff explicit; they are a practical format choice, not a claim that every project needs eight columns.
Write the purpose first. “Approve the revised instructions” requires a different message from “know that the instructions have changed.” An approver needs the proposed text and the decision deadline. A reader may need only the changed steps and a reliable link.

What does a completed example look like?
A useful example separates people doing the work, people approving it, and people affected by it. The following fictional plan concerns a small team updating a shared support guide. Its timing is illustrative, not a measured best practice.
| Audience | Purpose and message | Channel and timing | Owner and response |
|---|---|---|---|
| Writers | Coordinate unfinished sections and blockers | Shared project note each Tuesday | Jo updates; writers correct their own commitments |
| Approver | Accept the revised instructions | Review request when the draft is ready | Jo sends; Avery confirms a review window and returns a decision |
| Support colleagues | Use the current approved guide | Team channel at publication, linking to the guide | Avery announces; readers use the named contact for questions |
The live plan should also specify the escalation route. For example: if the reviewer cannot meet the agreed window, Jo asks Avery whether to reduce scope, use an authorized backup, or revise publication timing. Jo does not silently assume approval.
Notice that the plan does not promise a response within an arbitrary number of minutes. The response expectation is negotiated with the recipient and recorded alongside the actual request.
Here is the difference between two possible review messages:
Unclear: “Here is the new guide. Thoughts?”
Usable: “Please approve or correct the revised escalation instructions in sections two and three. The remaining sections are unchanged. Can you confirm whether you can review them before Thursday's publication decision? If not, I will revise the schedule before announcing it.”
Atlassian's communication plan template emphasizes audience, timing, channels, and responsibilities. Treat that as a planning discipline: a message is part of a coordinated handoff, not evidence that the sender has discharged every responsibility.
For the recurring written update itself, use the weekly status report template. The communication plan decides who receives that report and why; it does not need to duplicate the report's contents.
Which updates need a meeting?
Use a meeting when people need to resolve an uncertain choice together. Use a written update when the information can be understood and acted on without everyone being present at the same time.
Asana distinguishes synchronous from asynchronous communication: the former happens in real time, while the latter does not require an immediate response. Neither format is automatically better. Match it to the decision, the people, and the time available.
For the fictional guide project, a routine statement that drafting is on track can go in the shared note. A disagreement about which team owns a sensitive escalation may need a conversation with the authorized decision maker.
Before adding a meeting, write its required result in one sentence. “Decide who accepts urgent cases after the handoff” is a result. “Discuss the guide” is only a topic.
Use these checks:
- Does the recipient need to make a choice or simply receive information?
- Is the question understandable without a live explanation?
- Can the relevant people respond within the available window?
- Would the meeting end with an owner or decision that is currently missing?
If you meet, record the outcome in meeting notes and link it from the plan. Otherwise, people who were absent must reconstruct the decision from someone's memory.
Handle individual support or workload concerns in the appropriate one-on-one conversation. A project-wide update is usually the wrong place to expose a colleague's private circumstances.
How should urgent changes travel?
Define the trigger, the person who needs to act, and the backup route before the regular update would be too late. “Urgent” should describe a consequence and a decision window, not simply the sender's level of anxiety.
For a normal work project, a trigger might be: “A missing approval now threatens the promised publication date.” That is more actionable than “something feels behind.” Your organization may have separate required procedures for incidents or emergencies; this planning template does not replace them.
An original escalation message could read:
The review window has passed, and the publication date is now at risk. The draft is ready, but the escalation section is not approved. Please choose between a narrower release of approved sections and a revised full-publication date. I have listed the effect of each option in the project note.
Keep the facts separate from the requested decision. Do not bury the consequence below a long history of unanswered messages.
Confirm the backup before relying on it. Copying a more senior person does not automatically give that person context, availability, or authority. Record who can actually decide when the primary approver is absent.
Atlassian's template includes responsibilities for preparing, reviewing, and distributing communication. Apply the same clarity to escalations: identify who sends the message, who decides, and who tells the affected people what changed.

How do you check whether the plan works?
Check whether recipients can find the current information and take the intended action. Counting sent messages alone can reward activity while leaving the same confusion unresolved.
After the first delivery, ask a writer where the approved version lives. Ask the approver what decision is next. Ask a reader whom they should contact when an instruction is unclear. A wrong or inconsistent answer identifies a concrete gap to repair.
Keep a small list of observed failures: duplicate updates, unanswered decisions, conflicting versions, or people discovering a change too late. Adjust the row that caused the problem rather than adding another channel for everyone.
You can also retire a message. If nobody uses a weekly summary because the same information is already available and understood elsewhere, discuss removing it. The plan should protect attention as well as distribute information.
Do Only 3 Things a Day helps you decide what deserves that attention. A clear communication agreement supports focus by reducing the need to keep checking whether an important request has disappeared into the wrong place.
Frequently asked questions
Is this a marketing communication plan?
No. This template coordinates information within a work project. Marketing plans address audiences, positioning, campaigns, and external messages that need a different set of decisions and measures.
How many channels should we use?
Use as few as the work allows while meeting accessibility, confidentiality, and response needs. State the purpose of each channel and identify the authoritative record so people do not search several competing copies.
Who owns the plan?
Usually the person coordinating the project maintains it, while each communication has its own sender and recipient responsibilities. Confirm those roles with the people named rather than assigning them silently.
How often should it change?
Review it when the audience, scope, decision process, or timing changes, and when an observed failure shows that the current arrangement is ineffective. Keep the current version accessible to everyone who relies on it.