Own the guest
Hospitality has more software than ever and less memory than it used to have. Here is the bet we are making about why, and what we are building instead.
A stack that forgot.
Hospitality runs on more software than it has ever run on, and knows less about its guests than it used to. A booking sits in one tool, the Wi-Fi login in another, the card payment in the till, the review in somebody’s inbox. Every one of those is a fact about the same person, and none of them are ever introduced to each other.
The result is a room full of regulars that the system treats as strangers. Operators feel it before they can name it: not a missing feature, but the sense of being amateur at the one thing they are actually good at, which is remembering people.
One record wins.
Our bet is that the unit of value in hospitality software is not the booking, the campaign or the loyalty scheme. It is the guest record, and whoever holds a complete one can do every other job better than a specialist tool that holds a fragment.
That is why the platform is built the other way round from the category. The modules exist to feed one profile, not the other way round: a Wi-Fi login and a card payment are two ways of learning the same thing, and they should land in the same place without an export, a nightly sync or a spreadsheet in between.
Every action a guest takes is published once and consumed by everything that cares. Adding a module means subscribing, not building another point-to-point sync.
You should be able to leave and take your guests with you. Portability is a design constraint, not a support request.
Consolidation is the product. Anything that reintroduces a second system to reconcile is a step backwards.
Foundations first.
The interesting AI in hospitality is not a chat box bolted onto a booking tool. It is what becomes possible when the data underneath is already clean, connected and one hop apart: when “lapsed high spenders who came for the Christmas menu” is a question the graph can answer rather than a report someone has to build.
So we are doing the unglamorous half first. The graph, the event bus, the resolution of one guest across six touchpoints. The models get better every few months whether we do anything or not; the data model does not improve on its own, and it is the part that is genuinely hard to retrofit.
We ship.
We are an engineering-led company in Edinburgh, working with roughly two and a half thousand UK venues, and most of what we know comes from support tickets rather than strategy decks. That shapes what we will and will not claim: we would rather tell you the Wi-Fi hardware needs a proper setup than sell you a five-minute install and lose you in month three.
The same instinct runs through these Engineering pages. If the architecture is a real differentiator, showing it should be more convincing than asserting it.
The rest of the Engineering pages go deeper on the parts worth arguing about: the box in the venue, and how the platform fits together.