A recurring series is not a pile of one-off events. It is a promise that customers can find, buy, attend, change, and return to a repeating experience without the operator rebuilding the calendar from scratch.
The right ticketing software must handle the imperfect month: a holiday, a different room, a sold-out date, a cancellation, a member booking, a refund, and a participant who needs to move. Test that month, not a perfect weekly repeat.
First, decide what “recurring” means for your offer
| Offer | What the customer buys | The system model to validate |
|---|---|---|
| Weekly drop-in | One place on one date | Separate occurrence, its capacity, and its change rules |
| Rolling time slots | Access to a chosen time | Inventory and availability across many slots |
| Multi-week course | One commitment covering several sessions | One enrolment plus attendance or completion across dates |
| Monthly membership | Ongoing eligibility or credits | Membership state plus booking and cancellation rules |
| Seasonal programme | A defined set of dates with occasional exceptions | Shared setup with controlled overrides |
These should not all be configured as the same thing. Ticket Tailor’s current recurring-event documentation, for example, says occurrences share core event details and ticket setup, and separately advises a single event when one ticket includes multiple weekly course dates. Read the vendor’s explanation. The general lesson applies to every platform: match the product model to what the customer is buying.
The operational questions to put in every demo
Can one date change safely?
Create eight dates, then change capacity on one, move one start time, cancel another, and hide a third from sale. Look at the buyer page, confirmation, staff calendar, reports, and customer message. A good system preserves a comprehensible history while showing what is now true.
Ticket Tailor’s published documentation describes managing occurrences and setting dates available, unavailable, visible, or hidden. Review its current occurrence controls. Do not assume another vendor has identical behaviour; test it.
Can the system sell the same experience in more than one way?
Many operators need drop-ins, a multi-date package, member access, a concession price, and occasional private allocation. Create each one and check whether capacity is shared correctly. The most common failure is accidentally selling the same final place twice through different products.
What happens after a cancellation?
Test a customer cancellation before the policy window, inside it, and after a session is cancelled by the organiser. Confirm customer communication, capacity release, waiting list, entitlement restoration, refund record, and staff instructions. The customer-facing policy must be clear before automation is activated.
Can the door trust the record?
Give two staff members a live attendee list. Include a valid ticket, duplicate scan, transferred name, member reservation, cancellation, and a walk-in. Confirm permissions and the single action staff should take when there is a discrepancy. The customer should not be asked to prove a system failure at the entrance.
Does a customer history survive the series?
Find a repeat attendee. Can staff see which dates they attended, what they bought, what they cancelled, and what access they hold? If the business relies on repeat attendance, this is more valuable than a report that only counts tickets sold.
Capacity and waitlists need a written policy
Software can automate a rule; it cannot decide whether the rule is fair. Set the policy first:
- Which capacity is binding: room, staff, equipment, safety ratio, or ticket allocation?
- Is a held place counted while payment is pending?
- Who joins a waitlist and for how long is an offer valid?
- Does a member have priority, and if so, until what point?
- Is a late cancellation refunded, credited, or forfeited?
- What happens if the organiser cancels a date?
Write the decisions in customer language, then run them through the system with the people at the door and in support. That prevents a “fair” policy becoming inconsistent because it is too complicated to execute.
Customer communication is part of ticketing
Every recurring programme needs a single source for date, time, location, arrival information, changes, and policy. Before launch, intentionally create an exception and inspect every touchpoint: public event page, calendar link, confirmation, reminder, staff view, and customer support response.
If the information is different in two places, customers will find the wrong one. Reliable recurring operations are often more about this discipline than about a special “series” feature.
Integration: verify the events you need
If recurring ticketing must update another system, turn the desired integration into a sentence: “When a person attends an occurrence, update their record in the CRM,” or “When capacity changes, update the website.” Then ask the vendor to identify the current endpoint, event, permission, payload, retry behaviour, and failure path.
Gomry’s API introduction documents organisation-scoped API keys and resources including events, attendees, and ticket classes. Read the API documentation. It does not itself establish support for every possible booking, membership, scan, or accounting event. Evidence needs to be specific to the integration you plan to deploy.
Where Gomry fits
Gomry publicly positions itself around ticketing, bookings, payments, memberships, distribution, and mobile operations. It is worth evaluating when a recurring series creates a customer relationship that extends beyond the next occurrence: people use membership access, buy other formats, or need staff to see ticketing and booking context in one operational view.
For a promoter with one annual event, that may be more platform than necessary. For a complex programme that also needs specialist education records, venue management, or association governance, Gomry may need to connect to a separate system. The correct choice follows the workflow, not the broadest product claim.
A controlled launch plan
Launch a single series first. Keep the policy set small: one cancellation rule, one membership rule if needed, one waitlist rule, and named people for support and finance. Run staff through test purchases and changes before opening sales. At the end of the first cycle, reconcile the records and list every manual intervention.
Only then expand to additional programmes. A successful recurring system is one where customers receive accurate information and staff can resolve normal exceptions without escalating every case.
Frequently asked questions
Can recurring events have different prices?
They can, but the important detail is scope: does the price change apply to the whole series, selected future dates, or one occurrence? Test it before publishing a promotion.
Should every date have its own URL?
Not necessarily. A stable series page can be clearer for a repeating offer. Create distinct pages only when dates genuinely have distinct intent and content; otherwise avoid thin, duplicative pages.
Do I need memberships for repeat customers?
Use memberships when repeat access changes price, booking rights, limits, or cancellation treatment. A straightforward bundle or multi-date ticket can be sufficient for a simpler offer.
How should a recurring-event refund policy work?
Define notice period, refund or credit treatment, waitlist actions, staff ownership, and customer communication before setting the automation. Local consumer rules may affect the policy, so obtain appropriate advice.
What data should be portable?
Future occurrences, event settings, customers and consent, orders, attendees, attendance or check-in data, payments, refunds, and membership balances where applicable. Check whether relationships survive the export.