At the core
It all starts with knowing who is who.
Most ticketing systems store the booking and treat the person as a name attached to it. We built it the other way round — and everything else in this product reads the answer.
A guest record
Customer profile detail: orders, tickets, waivers and payments on one screen.
Three layers, kept apart on purpose
Muddle them and one family turns into three customers — or three families turn into one. Both are expensive, and both are hard to unpick later.
- Someone browsingAnonymous, before they buy
- Someone who boughtA purchase at one site
- Someone you knowThe person, across the group
- A browser is not a customer. Someone looking at your calendar has no name yet. We keep that visit separate so your customer count is not inflated by people who never bought anything.
- A purchase belongs to a site. The billing details on a booking are a snapshot of that transaction at that location — which is what keeps each site's own books accurate.
- The person spans the group. Above both sits the actual human being, with one history and one lifetime value across every site you run.
How we work out that two records are the same person
- Worked out once, used everywhere. The website, the till, the guest portal, waivers and saved cards all ask the same question and get the same answer. There is no second version of the rule sitting somewhere else to drift out of date.
- Email and phone, scrambled. Contact details are locked away, and matching runs on a scrambled version of them — so a returning guest is recognised without their email sitting in the open.
- The card catches what the email misses. Same card, different address: the parent who books on their work email in March and their personal one in July is still one person.
- Never guessed. We match on things that are actually the same, not on names that look similar. Two families called Smith stay two families.
It does not start with us
Identity rarely begins the day you change system. You already know who your regulars are — that knowledge just happens to live somewhere else.
- Bring the guests you already have. Import your existing bookings and the same matching runs across them, so somebody who has been visiting for six years does not look like a first-timer in the week you switch.
- Keep the link to wherever they came from. A record can carry the id it had in your previous system, so a guest here and a row over there can still be reconciled long after the migration.
- Duplicates are surfaced, not buried. Imported data is messy. Likely duplicates are found on the same scrambled email and phone indexes as everything else — never by comparing names that merely look similar — and put in a review queue rather than merged behind your back.
- A merge keeps the safest version of the truth. The record with more history survives, the earliest first visit and the most recent one are both kept, linked bookings and waivers are combined, and where the two disagree about marketing consent the more restrictive answer wins.
- And it reads back out. Guest records are available through the API, so what you brought in — and everything added since — stays yours to use elsewhere rather than being locked in here.
- Done with help, not a self-serve wizard. Bringing a customer list across runs through the API or an import we work through with you. There is no drag-and-drop screen for it today, and we would rather tell you that now than have you find out in week two.
The boundaries that make it safe
- Your guests are yours. Records never cross between businesses. That is built into the shape of the data rather than being a setting somebody could change by accident.
- Each site keeps its own books. Local reporting stays accurate to that location, and head office still sees one customer. Both are right at the same time, which is the whole trick.
- Everything hangs off the person. Tickets and whether they were used, visits, memberships, waivers, form answers, payments, messages and open enquiries — all on one screen, because they are all attached to the same record.
Identity matching
The identity matching panel on a customer profile, showing the linked order contacts it resolved.
See it running on your own products.
Bring one activity, one ticket type and one price. We will show you what it looks like in a real checkout.