Planning a conference email sequence

Conference emails tend to be written in a rush, one at a time, whenever someone remembers that delegates need to know something. The result is a run of messages that repeat each other, contradict the programme or arrive after the information has changed. A little structure up front stops most of that.

Give every message a reason

Before drafting anything, list each email with five details: who receives it, why it exists, what triggers it, who owns its content and what the reader should do next. If a message cannot fill in all five, it probably does not need to be sent.

A common order of messages

1. Invitation, explaining who the conference is for and how to register.
2. Confirmation, sent when someone signs up.
3. Programme update, once speakers and sessions are settled.
4. Arrival note, with directions, check-in instructions and what to bring.
5. Day-of reminder, short and limited to essentials.
6. Follow-up, with thanks, any agreed materials and a short survey.

Speakers and sponsors are not delegates

Speakers need rehearsal times and an AV contact. Sponsors need build access and artwork deadlines. VIPs may need a different entrance. Sending them the delegate email and hoping they work out which parts apply is how a sponsor ends up queuing at the main registration desk.

Track what each email depends on

The arrival note cannot go out until the venue confirms room names and access times. The programme update waits for speaker sign-off. Put these dependencies on the schedule next to each send, so a delay in one place shows up early rather than producing a hurried, wrong message later.

The page on mapping conference emails to the delegate journey sets out this sequence in more detail, including how to handle programme changes once messages have started going out.

Respect registration status

Someone who has already registered should not receive another invitation, and someone who has cancelled should not receive joining instructions. Agree these suppression rules with whoever holds the registration data before the first send, and test them with a handful of real records.