Getting reminders delivered: what "sent" does not mean

The most dangerous number on an event dashboard is the one labelled "sent". It is always high, it always goes up, and it describes an event that happened entirely inside your own building.

Sent means your software handed a message to a provider and the provider accepted it. Everything interesting happens afterwards.

The states, and what each one actually claims

Sent. Your system called an API and got a success. The message exists. Nobody outside your provider has seen it.

Delivered. The receiving mail server accepted the message. This is the first state involving the delegate's side of the world, and the one to build your operational filters on. Note what it does not claim: not that a human saw it, not that it reached the inbox rather than the promotions tab or a quarantine folder.

Opened. A tracking pixel loaded. Treat this as a weak positive and never as a negative. Mail privacy features fetch images on the recipient's behalf and corporate scanners fetch everything, so a recorded open may be a security appliance — and a person with no recorded open may have read the message twice.

Bounced. The receiving server refused it. A hard bounce means the address does not exist — a typo, or somebody who left the company. That address is dead; stop sending to it and go and find the person another way. A soft bounce is temporary: full mailbox, greylisting, a server having a bad afternoon. Soft bounces that persist for days are hard bounces wearing a coat.

Failed. It did not get as far as the receiving server. Bad request, provider outage, a template that would not render, a WhatsApp number that is not on WhatsApp. This bucket is your bug tracker, and it is usually small and usually your fault.

The gap between sent and delivered is where a delegate turns into a queue-stopping exception at the door. Which is why a delivery record per message matters more than a delivery percentage: you do not need to know the rate, you need the list of names.

The failures view is a work queue

Most platforms will show you failures. Fewer treat them as work, and the distinction is whether the view has an owner and an expected end state. A failures list nobody empties is a report; the same list, assigned to one person with the instruction that it should be empty by Friday, is a process. The work is genuinely small — most entries are a typo in an address, which the person who registered can be phoned about — and doing it in week one costs a fraction of what it costs on the morning.

Sender identity: send as the event, not as your platform

A delegate does not know your registration software exists, and should not have to. The reminder should arrive from the organisation running the event, with that organisation's name and reply-to address, because two things follow.

The first is recognition. A message from a name the delegate recognises gets opened; one from a vendor they have never heard of gets a suspicious pause at best.

The second is replies, and this is the one people forget. People reply to reminders — to say they cannot come, to ask about parking, to ask whether a colleague can take the slot. If the reply-to points at a no-reply mailbox, every one of those is lost, the seat is never released, and the parking question turns up at the door instead.

Set a per-event sender name, from-address and reply-to, and make sure the reply-to is a mailbox somebody reads during the week of the event.

One thing worth being precise about, because it is often assumed: sending under your own name and address is not the same as the event having its own web address. Sender identity is about the message.

The domain has to authenticate

None of the above helps if the sending domain cannot prove it is allowed to send. This is dull, one-off, and the single highest-yield thing on the list.

Publish SPF. Publish DKIM, signed with a key on your domain. Publish DMARC, start it in monitoring mode, read what comes back for a fortnight, and only then tighten it. Alignment between the visible from-address and the authenticated domain is what large mailbox providers check first, and a mismatch is the commonest reason an innocent reminder lands in spam for an entire company at once.

If the domain has never sent bulk mail before, do not make the first thing it does a blast to four thousand addresses. Start with the small, engaged batches — confirmations, which people are expecting — and let volume build.

WhatsApp is a different medium with different rules

WhatsApp is not email with a better open rate. Business messaging is template-based: the exact copy has to be registered and approved by Meta for your sender in advance, with variables in fixed positions. You cannot improvise the wording at nine in the evening because the venue changed.

So get templates approved early, keep them generic where details are still moving, put the changeable parts in variables — and keep an email path for anything that has to be said in a hurry.

Schedule relative to the event, not to a date

Reminders should be defined as offsets — fourteen days out, three days out, one day out, and a thank-you afterwards — rather than as fixed timestamps. Events move. When the date shifts by a week, an offset schedule follows it and a hard-coded one sends a "see you tomorrow" to people who are not travelling for another eight days.

Three reminders is usually right for a professional audience. The fourteen-day one catches diary conflicts while they can still be resolved, and is your best source of returned seats. The three-day one lands when travel is booked. The one-day one is logistics: gate, time, what to bring.

Preview against a real registration before you send

Every template bug is obvious in hindsight and invisible in the editor. A merge field that renders empty, a name in capitals because that is how it was typed on the form, a date formatted for the wrong locale, a link that was right in staging.

Rendering the template against an actual registration — real person, real fields, real event — catches nearly all of it in thirty seconds, before four thousand copies exist. Do it every time, including for the template you have sent nine times before: the thing that changed may have been the data.

Version the templates

Somebody will ask, weeks later, what exactly the second reminder said — usually because a delegate is quoting it back and it does not match what is in the editor now. If templates are versioned, that is a lookup. If they are not, the honest answer is that you do not know, which is uncomfortable to tell a sponsor and worse to tell a regulator.

Keep the versions. Keep the delivery record. Between them they turn "I think we told everyone" into a sentence you can defend.