6 minute read

How to organise your internal mailing lists

The question is rarely how many lists you need. It is which of them should be a list at all, and which should be a preference inside one you already have.

Last reviewed

Two ways to slice the same people

Every internal list is organised on one of two principles, and most difficulties come from using the first where the second was needed.

By who somebody is. Their department, their site, their grade, whether they are permanent or contract. The organisation already knows all of this, it lives in the HR system, and it flows automatically into the directory. Nobody maintains it, and when somebody moves it updates itself.

By what somebody wants. The topics they care about, how often they want to hear, which of six sites they actually visit. Nothing knows any of this, because nobody has ever asked.

The first is free and the second is work, so the first gets used for both. That is how a cycling club message reaches everybody in Operations.

Why it usually arrives as a ticket

Ask a room of internal communicators how their lists get made and you will hear a version of the same answer: somebody asks HR, HR raises a ticket, IT builds a group in Microsoft 365, and it propagates out to Outlook, Teams and the intranet.

That is a sensible process for a structural audience. It is fed by the system that owns the fact, it is consistent everywhere, and it needs no maintenance.

It becomes a problem when it is the only mechanism available, because then every audience has to be expressed as one - including the ones the directory has no opinion about. A volunteering programme is not a department. So either it gets approximated by one, and reaches four hundred people who did not ask, or somebody keeps it by hand in a spreadsheet, or it waits in a queue behind work that is genuinely IT’s.

  • Keep the ticket route for anything mandatory. Safety notices, closures, policy changes, payroll deadlines. These should follow the org chart automatically and nobody should be able to opt out of them.
  • Do not use it for anything optional. A group nobody chose to join, sending something they can only escape by asking a person to remove them, is the arrangement that teaches a workforce to ignore internal email.

How many lists is too many

There is no correct number, but there is a reliable symptom. If you cannot say, without checking, who is on a given list and why it exists, it has stopped being a list and become a liability.

Every list needs one owner
Not a team, a person - somebody who would notice if it were wrong and who has the authority to change it. Lists with no owner are the ones that survive three reorganisations and still reach people who left in 2023.
Every list needs a reason to be separate
If two lists hold substantially the same people, they are one list with a topic preference. Keeping them apart doubles the maintenance and guarantees they will eventually disagree about somebody's address.
Every list needs a way out
For anything optional: one click, no explanation, no request to a person. If leaving requires asking somebody, people do not leave. They stop reading, which looks like success in your open rates and is the opposite.
Every list needs an end
A list built for a single programme should be closed when the programme ends. Almost nobody does this, which is why organisations accumulate lists faster than they retire them.

The change that removes most of the work

Most organisations do not need more lists. They need fewer lists with preferences inside them.

The instinct, faced with people wanting different things, is to make a list per thing: one for the cycling club, one for the parents’ network, one for site news, one for the volunteering programme. Six audiences, six lists, six sets of joiners and leavers, six things to keep current - and one person on all six who has moved office and is now wrong in six places.

The alternative is one list with six questions on it. The same person appears once. When they move site they change one answer, and every audience derived from that answer is correct immediately. When they tire of the cycling updates they untick one box rather than unsubscribing from everything you send.

  • Split into a separate list when the audiences barely overlap. A list for the Manchester depot and a list for the executive team are genuinely different populations with different owners. Keeping them apart is right.
  • Use a preference when the audiences are the same people. Six interest groups within one workforce are one list with six topics. This is the case almost everybody gets wrong, and correcting it removes most of the administration in a single move.
  • Ask only what changes what you send. Every question is one more thing to keep accurate and eventually justify. If knowing somebody's job title changes nothing about what they receive, it is a liability with no matching benefit.

Things worth being straight about

  • Consolidating lists is a political act. Six lists usually belong to six people who each feel responsible for theirs, and proposing to merge them can read as taking something away. It goes better framed as removing their administration than as removing their list.
  • The number will go down. Letting people choose reduces the audience for any individual topic, because some of them did not want it. That is the point, and it is worth agreeing with whoever reads the reporting before you start rather than afterwards.
  • Structure and interest both matter. None of this is an argument for abandoning directory groups. It is an argument for using each where it works: the directory for who somebody is, a preference record for what they want. Most organisations should have both.
  • Sending to the wrong list is the fear, and consolidation helps. Fewer lists with obvious names is the most effective protection against the mistake every internal communicator has made at least once. A group called 'All Staff (old)' is an accident that has not happened yet.