General architecture
Publish.Subscribe.One guest.
Every platform in this category claims one view of the guest. This is the arrangement that actually produces one, and the reason it is hard to retrofit.
Powering 2,500+ UK venues
Reconciled, nightly.
Without a bus, the day happens in six systems that never speak: bookings here, Wi-Fi logins there, spend in the till's own report. Then an export runs at 2am and stitches together a guest view that is already out of date at breakfast.
Who does what.
The split that explains why adding a module never means rewriting the others.
A captive portal and RADIUS handle authentication and per-session limits, with the SNAPguard appliance giving each venue a managed tunnel. Every login publishes a guest.
Availability, deposits, pre-orders and the live day-planner. Publishes the booking lifecycle and consumes guest history to show staff who is arriving.
Two-way sync with the till, so spend and line items attach to a guest rather than sitting in a separate report.
Each subscribes to the events that should trigger it: enrol on sign-on, request a review after a visit, re-engage after a lapse.
Claims you can check.
The bus makes them boring questions, not roadmap items.
Live, not nightly.
Does a Wi-Fi login update the booking record without an export? Yes. Both publish to the same bus, so the profile is current by construction.
Spend moves segments.
Does yesterday’s payment change who is in this morning’s segment? Yes. Segments subscribe to spend, they do not re-import it.
Yours to take.
Can you leave with your data? Yes. One record per guest, one export, and no network holding your regulars hostage.
Built for what’s next.
A graph where a guest, their visits, their spend and their consent are already connected is the hard part of AI in hospitality, and it is not something you can add later by putting a language model in front of five disconnected databases. The homepage draws this architecture live: every section from the hero fan-in to the stage cells is the same event flow, running.