For the host planning the send calendar
Send too early and people forget the date; too late and their diary is already full. A sensible timeline from first announcement to the last automatic reminder, with the gaps filled deliberately.
Early sends fail by being forgotten. Someone registers three weeks out, the confirmation email sinks, and the reminder at twenty-four hours arrives to a person who no longer remembers agreeing. Late sends fail by being blocked: the diary is full by Tuesday for a Thursday session, and a good page cannot rescue an impossible date.
The useful way to think about the runway is that registrations happen early and decisions to attend happen late. So the invitation should go out with enough room for people to register while the date is still abstract, and the reminders should carry them across the gap into the day itself.
Approximate, deliberately. The point is the order and the gaps, not the exact day count.
Publish the page before you announce anything, then send once to the people most likely to want it. This is the registration window, and it is when most names arrive.
Not a repeat of the first message. New angle — the agenda chapter you have since written, a question you were asked — sent to those who have not registered rather than to everyone again.
The automatic reminder at twenty-four hours does more work here than another announcement. Anything you still need to say to registrants goes as a broadcast to that segment.
One hour and fifteen minutes before the start, by email, each carrying the way back to their own access link. These are on unless you switch them off.
Replay, slides or feedback links you supply yourself, sent to the segment you choose. Sent a week later, nobody opens it.
There is no calendar sync here, and it is worth saying plainly since so many tools claim it. What arrives in the confirmation email is an .ics file and a Google Calendar link, both of which the guest can use to save the date themselves. Nothing writes into anyone's calendar automatically and nothing converts the start time into each visitor's local zone; the time zone appears as a label next to the time you set. So state it the way people read it: 18:00 CET, spelled out on the page and in the message.
The practical consequence for timing is small but real. Because saving the date is a voluntary act by the guest, reminders do the remembering for you, and the schedule above is built around them rather than around a clever send cadence.
How it works
The page carries the date with its zone, the agenda chapters, the speaker and the seat cap. Nothing goes out while it is still a draft, because a draft link shows guests nothing.
Two or three weeks out, to a segment you would recognise, with the date and the promise in the message text itself.
One follow-up to non-registrants mid-runway, and a broadcast to registered people only if something genuinely changed.
Twenty-four hours, one hour, fifteen minutes, all by email and all switchable. Then send the replay to the segment that attended while the session still feels recent.
Questions
For most single sessions, two to three weeks. Enough time to register while the date still feels reachable, short enough that the session is on their mind when the reminders arrive.
One bump, to the people who have not registered. A third message to the same audience reads as noise and mostly annoys the people who already said yes.
Yes — at twenty-four hours, one hour and fifteen minutes before the start, by email, to everyone registered. The host can switch them off, which at short notice would be an own goal.
It does not convert automatically. The time zone appears as a label next to the start time you set, so write it in the message too and avoid a room of people arriving an hour apart.
A series needs a page per session, since one webinar page is one date. Timing is then planned per page, not for a run of dates on a single link.
Get Started
A short runway with clear gaps beats a long campaign. The reminders are what actually bring a registered room back on the day.
