How to map your internal communication audiences

The cost of a single all-staff list

When everything goes to all staff, the internal channel carries everything and addresses no one. An update about a client win matters to the delivery team, is context for finance, and is noise to the night support rota. Treating these as one audience is the most common structural failure in internal communication, and no amount of tone work fixes it.

The cure is a map: one page naming each internal audience group, what it needs, when it needs it, which channel reaches it, and where its replies go. The rest of this article is how to build that map.

Segment by what people must do

The instinct is to start with demographics: age bands, departments, locations. Those axes describe people, and they predict little about what someone needs to know. The axis that predicts behaviour is action: what must this group do, or decide, or be ready to answer questions about?

Take a pricing change. Engineers shipping it need the date, the mechanics and the support script. Finance needs the revenue impact. Everyone else needs to know it happened. That is 3 rows, not one broadcast, and none of them is defined by age.

Role and location still earn their place where they change the answer: a shift pattern changes when, a site changes who briefs, a language changes the version. Where they do not change the answer, they are describing people, and the map does not need them.

Two structural cases deserve their own rows wherever they exist: people without regular desk access, and contractors outside your systems. Both are internal audiences by any definition that matters, and both are unreachable on the channels most maps assume.

The classification that helps

The older stakeholder vocabulary sorts audiences into primary and secondary. It is a blunt instrument: it records importance without recording why, so it cannot tell you what to do differently for each group. The stakeholder map in the stakeholder engagement framework sorts each row by what that group can decide or stop and what they hold at stake, which is information a communications plan can act on. The internal and external boundary is covered in internal versus external stakeholders.

The internal audience map

One page, one row per group, 5 columns:

Group	What they need	When	Channel	Where replies go
Delivery team	What changed for each client, and what to say in Monday stand-ups	The Friday before the week it lands	Team meeting, then the written record	The account lead
Client-facing staff	The change, the reason, and what may be promised	Before any client is told	Briefing at 9am, then email from the MD	The account lead
Engineers and operations	The mechanics, the date, the rollback plan	At sprint planning	Sprint planning, then the ticket	The tech lead
Part-time and support rota	What customers will ask about this week	At the start of their shift	Shift handover notes	The support lead
Contractors off-system	Anything that changes their scope or access	Before the change	Their named contact, by email	Their named contact

The replies column is the one that survives contact with reality. It names who answers when the message raises a question, which is the moment the map gets tested.

How many rows is too many

Splitting one audience into 5 is the fix. Splitting it into 40 is the same failure wearing better clothes.

An over-segmented map fails quietly. Nobody objects to it, because more precision always sounds like more care. What happens instead is that maintaining it costs more than sending the messages, so it stops being maintained, and a stale map is worse than no map: it gives you a reason not to think about who needs this.

The test is whether 2 rows ever receive different things. If a group has never once needed a different message, at a different time, on a different channel, from the group above it, it is not a separate row. Merge them and keep the distinction in your head until it earns its place.

For most organisations under a few hundred people, the honest number is between 4 and 8 rows. Larger or more federated organisations need more, and the extra rows are usually driven by location, shift pattern and language rather than by function.

The map is not static

A map built for one announcement will be wrong for the next phase of the same programme, because what each group must do changes as the work moves.

The Teal Book, the UK government's project delivery standard, makes this point about stakeholders generally: expect interest and engagement to evolve across the life cycle, and expect it to shift with events nobody planned. Its example is that service user interest typically peaks during implementation and transition, when changes actually arrive. The internal equivalent is familiar. During design, the delivery team needs detail and everyone else needs reassurance. At launch, the support rota suddenly needs more than anyone. Afterwards, the group that needs the most is whoever inherited the work.

So date the map, and rebuild the What and When columns at each phase change rather than treating the map as a fixture. The Group and Channel columns are usually stable. The other 3 are not.

Where a message also has an external version, run both through the same-message worksheet in internal versus external communication. The two worksheets share their replies logic: whoever answers externally needs to know what the internal rows were told.

Checking the map against reality

The map is a hypothesis until a message lands. 3 checks are cheap:

• Ask each group's lead what their team asked about after the last announcement. Questions the map did not anticipate mark a missing or wrong row.
• Watch where replies actually arrive. If questions come through a channel the map does not list, the map is wrong about the channel, and that channel is winning anyway.
• For the numbers to watch over time, the role of internal communications in employee engagement sets out a minimum measurement plan adapted to internal audiences.

Map your next announcement

List the groups who must act on, or answer for, your next internal announcement. Beside each, write what they need, when, on which channel, and who takes their questions. Test the map against that one announcement, then correct it. Maps that survive 2 or 3 announcements are usually right. Maps written in the abstract are not.