How To Build An Event Reminder Automation

An event reminder automation should do more than send a sequence of messages before a start time. It should recognise who is genuinely registered, use the correct event details and time zone, stop when a booking is cancelled, and avoid adding promotional pressure to an operational message.

That sounds straightforward until an event changes venue, a session is rescheduled, someone registers late, or the same contact is receiving other campaign email. The strongest programmes treat the automation as a small operational system with clear data, rules and exception paths, rather than a collection of scheduled sends.

Start by defining what the reminder is for

The first decision is whether the email is a service message, a marketing message, or a mixture of both.

A confirmation that says, “Your workshop starts at 10:00 on Tuesday and here is your joining link,” is normally a service communication connected to a registration. If the same email also promotes a paid course, asks the recipient to bring a colleague, or advertises unrelated sessions, it may be direct marketing as well. This distinction affects consent, unsubscribe treatment, internal approval and recipient expectations.

For UK senders, the Information Commissioner’s Office explains that organisations can provide customers with important information needed as part of their relationship, but direct marketing by electronic mail is separately regulated. Promotional content should therefore not be slipped into a reminder simply because the recipient has registered for an event. See the ICO’s guidance on identifying direct marketing and electronic mail marketing rules.

In practice, separate the operational reminder from any optional promotional follow-up. This makes the core message clearer, reduces complaints and means an unsubscribe from marketing does not accidentally prevent essential booking information from reaching a registrant where there is a valid basis to send it.

Build around an event record, not around a fixed schedule

A reliable automation needs a current source of truth for the event. Do not hard-code a date, webinar link or venue into every email step and hope the campaign is edited in time. Instead, store the event information in structured fields that the automation reads at send time.

Field	Why it matters
Event ID	Links each registration, reminder, calendar file, attendance record and cancellation to one unambiguous event.
Start and end date-time	Provides the calculation point for reminders and supports calendar entries.
Event time zone	Prevents the common mistake of calculating reminders in the account or server time zone rather than the event’s local time.
Status	Allows the automation to distinguish scheduled, sold out, postponed, cancelled and completed events.
Attendance mode	Changes the practical content: joining link and access instructions for virtual events; address, arrival information and accessibility details for in-person events.
Current joining or venue information	Must be centrally maintained so an update reaches every reminder without rebuilding the journey.
Registration status	Determines eligibility. Useful values include registered, waitlisted, cancelled, attended and no-show.
Registration time and source	Supports late-registration logic and helps diagnose unexpected enrolment.

Keep the event record separate from the person’s registration record. One person may attend several sessions, and one event may have several registrants from the same organisation. A contact-level field such as “next event date” is convenient, but it often fails once registrations overlap. A separate registration object, table or custom record is safer where the platform permits it.

Use an event-triggered entry point

The preferred trigger is a confirmed registration event from the booking system, rather than a nightly import into a mailing list. The trigger should create or update a registration record with the event ID, attendance status and contact details, then enrol that specific registration into the reminder flow.

Before enrolment, apply a small set of checks:

• the email address is present and has not been suppressed for a hard bounce or a prior complaint;
• the registration is confirmed, rather than merely started or abandoned;
• the event is still scheduled and has not passed;
• the person has not already been enrolled for the same event under a duplicate registration; and
• the chosen communication type is permitted for that registration and jurisdiction.

Deduplication matters particularly for events that permit edits. If someone corrects their email address, changes a ticket type or selects a different session, the update should amend the existing registration where possible. Creating another record each time can produce duplicate confirmations and reminders.

Choose timing based on the decision each email supports

There is no universal reminder cadence. A two-hour virtual briefing and a three-day conference create different decisions for attendees. The useful question is: what can the recipient do after receiving this particular message?

A practical starting pattern for a standard webinar might be:

• Immediately after registration: confirmation, start time expressed in the event time zone, joining method, calendar option and a route to amend or cancel the registration.
• Several days before: an agenda or preparation reminder, only if enough time remains for the recipient to act on it.
• The day before: a concise operational reminder with the start time, time zone and joining details.
• Shortly before the start: a minimal “starting soon” message, used selectively for events where it is genuinely useful and only for people who have not cancelled or already checked in.

For an in-person event, the earlier reminder may need travel, venue, accessibility or registration-desk information. For a high-value live demonstration, the immediate pre-event reminder may be appropriate. For a routine monthly session, it may merely add pressure without improving attendance.

Build each timing step as a calculation relative to the event start time, such as “send 24 hours before”, rather than a fixed weekday or clock time. At the point of sending, re-check the registration and event status. A person who cancels after entering the journey must not receive the next reminder simply because they were eligible when they entered it.

Handle late registrations deliberately

Late registrations expose weak automation design. Someone who registers two hours before a session should receive the confirmation with access information, but not a reminder that was intended to arrive 24 hours earlier. They may receive a short pre-start reminder if the remaining interval meets a sensible threshold.

Define the rule in advance. For example: send the confirmation immediately; skip any reminder whose planned send time has already passed; send the final reminder only when at least 30 minutes remain before the event. The exact interval is an operational choice, but the rule must prevent a burst of outdated messages.

Make time zones visible and technically consistent

Store the event start in a recognised time zone, not as an unqualified local date-time. This is essential around daylight-saving changes. Then decide how it will be displayed.

For an international audience, show the event time in the event’s named zone and, where your platform can reliably calculate it, the recipient’s local time too. Avoid ambiguous abbreviations. “10:00 BST” is clearer than “10:00”, but a recipient in another country may still need a local-time rendering or a calendar entry.

Test with registrations in different regions and with an event that crosses a daylight-saving transition. Also test the platform’s date formatting: some systems calculate a delay accurately but merge a date in the account’s default time zone, creating an email that says one time while the calendar event says another.

Use calendar invitations carefully

An “add to calendar” link can reduce friction, but it should not replace the information in the email. Include the event title, date, time zone, duration, location or joining link, and a plain-text alternative for people who cannot use the calendar option.

For a downloadable calendar file, use a properly generated iCalendar event rather than hand-assembled text. The iCalendar specification defines the event structure and scheduling methods, including RFC 5545. If the event is rescheduled or cancelled, the calendar update needs the same stable event identifier and an increased sequence value so calendar clients can recognise it as an amendment rather than a separate booking. This is one reason a stable event ID is more than a database convenience.

Where calendar invitations are sent as email attachments or meeting requests, test across the calendar clients your audience actually uses. Some clients display attachments differently, and some recipients prefer a landing page with calendar links for Google, Outlook and Apple Calendar.

Design the exception paths before the main path

The normal sequence is easy to visualise. The operational value comes from the branches that prevent confusing or harmful sends.

Cancellation

When a person cancels, immediately mark the registration as cancelled, remove it from outstanding reminder eligibility and send one clear acknowledgement if appropriate. Do not delete the record if it is needed for reporting or suppression logic; change its status instead.

Event cancellation or postponement

Stop all scheduled reminders as soon as an event changes status. Send a dedicated update that explains what has changed, what the recipient needs to do and whether their place will transfer. A postponed event should not remain in the original journey with its previous reminder dates; create a controlled re-entry or update the schedule only after the new details are confirmed.

Joining-link or venue changes

Use a centrally managed destination where possible. If a joining link changes, a stable access page can be updated without relying on every old email being replaced. For substantial changes, send an explicit operational update rather than assuming attendees will revisit the previous reminder.

Waitlists and capacity

Waitlisted contacts should not receive attendee reminders. If a place becomes available, change the registration status first, send a confirmation that requires acceptance where necessary, and enrol the person into the appropriate remaining reminder path.

Write reminders for retrieval, not persuasion

Most recipients will open a reminder while busy and look for one thing: when and how to attend. Put the essential information near the top:

• what the event is;
• when it starts, including time zone;
• how to join or where to go;
• any preparation requirement; and
• how to cancel, amend or get help.

A subject line such as “Reminder: [event name] starts tomorrow at 10:00” is usually more useful than a creative campaign line. Match the sender name and address to the organisation or event the person remembers registering with. Misleading sender details and subject lines are poor practice; Gmail’s sender guidance also requires message elements to accurately represent the sender and content.

Keep the final reminder especially short. The recipient should be able to find the access button or venue details without scrolling through a speaker biography, a sales offer or several secondary calls to action.

Protect deliverability as the programme scales

Event reminders are expected mail for registrants, but they can still cause deliverability problems if lists are poorly maintained, sending volume changes abruptly or messages contain marketing material that recipients did not expect. Authenticate the sending domain with SPF, DKIM and DMARC, and ensure the visible From domain aligns with authentication. Google requires SPF or DKIM from all senders to personal Gmail accounts, with SPF, DKIM and DMARC requirements for bulk senders; its guidance also sets additional requirements for subscribed and marketing mail at higher volumes. Google’s email sender guidelines set out the current details.

Yahoo similarly asks all senders to authenticate mail and places further requirements on bulk senders, including SPF, DKIM, DMARC alignment, visible unsubscribe options for relevant messages and low complaint rates. See Yahoo’s sender best practices.

Do not solve the classification question by putting every event reminder into a promotional stream, or by treating promotional material as transactional to avoid opt-outs. If a reminder contains marketing or is part of a subscribed marketing programme, provide the appropriate unsubscribe mechanism and honour suppression records. Google requires one-click unsubscribe support for marketing and subscribed messages from qualifying bulk senders, alongside a visible unsubscribe link in the body.

At larger volumes, monitor hard bounces, deferrals, spam complaints, unsubscribe events, delivery by mailbox provider and evidence of inbox placement. More importantly, watch for unusual patterns after a schedule or audience change: a sudden increase in complaints from a particular provider may indicate that recipients did not expect the message, the stream has been misclassified, or the automation has sent duplicates.

Test the journey as an attendee would experience it

A test send of one template is not sufficient. Create test registrations that cover the key paths: normal registration, late registration, cancellation, reschedule, changed joining link, waitlist promotion, duplicate signup and a recipient in a different time zone. Inspect the actual emails, calendar behaviour and landing-page links.

Then test timing. Confirm that the date and time shown in the message match the calendar entry and the event platform. Confirm that a cancellation made minutes before a reminder stops the send. Review message headers to ensure the expected sending domain and authentication are in use.

For organisations with a fragile or recently damaged sending reputation, it can be sensible to review the automation before expanding it across a large event programme. Email Foundry’s work is relevant here when the issue is not the journey logic alone but the surrounding sending infrastructure: authentication, suppression handling, contact pressure, provider-level pacing and mailbox-provider signals may all affect whether legitimate reminders arrive reliably.

Measure outcomes that improve the next event

Attendance is the primary operational outcome, but it needs context. Compare attendance by registration lead time, reminder exposure, event type, time zone and attendance mode. Be cautious about treating opens as proof that a reminder worked: privacy features and image blocking make open data incomplete.

Useful operational measures include registrations that received each reminder, skipped sends and the reason for the skip, cancellations after each message, joining-link clicks, check-ins or attendance, bounce and complaint rates, and duplicate-send incidents. A lower attendance rate may be caused by event relevance, time, registration quality or technical access problems rather than reminder timing alone.

The result should be an automation that communicates only when it helps the registrant attend, adapts as the booking changes, and remains safe to run repeatedly at scale.

Frequently asked questions

How many event reminder emails should I send?

Use the fewest messages that help people attend. A confirmation and a day-before reminder are often sufficient for a simple webinar. Add an earlier preparation message or a short pre-start reminder only when it gives the attendee useful information or a realistic action to take.

Should event reminders include an unsubscribe link?

It depends on the message’s purpose and applicable rules. A purely operational booking reminder may be treated differently from marketing, but adding promotional content can change that assessment. Marketing and subscribed mail should provide an appropriate opt-out route; qualifying bulk mail to Gmail and Yahoo also has one-click unsubscribe requirements.

What should happen when an event is rescheduled?

Immediately stop the old reminder schedule, update the event record, notify registrants clearly, and send a calendar update where one was issued. Do not leave contacts running through reminders calculated from the previous start time.

How do I stop duplicate reminders?

Use a stable event ID and a separate registration record, enrol only confirmed registrations, and apply a unique enrolment rule for the combination of contact and event. Re-check eligibility immediately before every send, especially after registration edits or cancellations.

Sources and further reading

• Email sender guidelines — Google
• Sender best practices — Yahoo Sender Hub
• How do we comply with the PECR electronic mail marketing rules? — Information Commissioner’s Office
• Identify direct marketing — Information Commissioner’s Office
• RFC 5545: Internet calendaring and scheduling core object specification — IETF