Recurring events and series

If you run the same thing every Tuesday, there is an obvious shortcut and it is the wrong one: keep a single event page and change its date each week. It works for about a month, and then it quietly takes away every number you might have wanted.

Why separate events

Each occurrence gets its own capacity, its own attendee list, its own check-in and its own sales figures. That sounds like bookkeeping until you try to answer an ordinary question with the single-page approach.

• "Who is coming on the 14th?" — with one page, your attendee list is everybody who has ever booked, and you cannot tell this week's from last week's.
• "Which Tuesday sold badly?" — with one page, there is one sales figure. The bad week is invisible, averaged into the good ones.
• "Is the 21st full?" — with one page, capacity is a single number across all dates, so a sell-out in one week blocks sales for every other week.
• "How many actually turned up in March?" — with one page, check-ins from every date are in one pile.

None of these are exotic. They are the questions you ask about a recurring event, and they are the ones that decide whether you keep running it.

Generating a series

You set the pattern — weekly, monthly, a specific set of dates — and the generator creates the occurrences for you. Afterwards they are ordinary events in every respect. There is no special "series mode" that constrains what you can do with them later.

That independence is the useful part. You can change the price of one date, cancel a single occurrence for a public holiday, move one to a different room, or give one a different description because there is a guest speaker — without touching the rest.

What carries across

Ticket types, description and settings come from the template, so you configure once rather than twenty times. Attendees then book a specific date, which is what they think they are doing anyway — nobody buying a ticket to a Tuesday class believes they are buying into a series.

One thing worth deciding early: how far ahead to generate. A term, a quarter or a season is usually right. Generating two years of weekly classes produces a hundred events you will have to edit individually if anything changes, and a listing page nobody can navigate. It is easier to generate another batch than to delete eighty.

Cancelling one occurrence

Cancel a single date and only that date's attendees are affected — they are refunded and told, and the rest of the series carries on untouched.

This is genuinely difficult to do safely when a series is really one page in disguise, because there is no clean answer to "which of these bookings belongs to the cancelled date". With real events there is no ambiguity, and the cancellation is the same operation as cancelling any other event.

Practical advice

• Generate a term at a time. Enough that people can book ahead, few enough that a change is a manageable edit.
• Check the holidays before you generate. Removing three dates afterwards is fine; realising in week six that you sold tickets for a date you were never going to run is not.
• Get the template right first. Ticket types and description propagate at generation time, so ten minutes on the template saves an hour of repetition.
• Use the per-date figures. The whole reason for this structure is that it tells you which weeks work. A class that sells out in October and half-fills in February is telling you something about February, and you can only see it if the dates are separate.

If your event genuinely is one thing happening once, none of this applies — use a normal event. Recurrence is for the case where "the same event" is a description of the format, not of the occasion.