Hoteliers have accepted that AI will change, and in most cases has already changed, how their business runs. Where they get stuck is in deployment. There are so many places you could use it that it becomes easy to do everything and nothing at the same time, and more often than people expect, the problem turns out to be the systems sitting underneath.
Hospitality trained people to choose: cheap or beautiful, scale or soul, warm or efficient. At Mollie’s we were never very good at choosing, and it turns out that is the advantage. You can automate the booking, but you can’t automate the welcome. Most of what makes a stay good happens between people, and that stays with our team. What technology takes on is the process around it: the queue, the form, the reconciliation, the check nobody enjoys doing. It does that work, a person checks and validates the result, and the burden of process comes off our on-property teams so they can focus on the guest experience. Technology takes the transaction; people keep the connection. Getting there depends on groundwork that rarely features in the AI conversation, mostly because it is the least glamorous part of the job and the hardest to get right.
Mollie’s is a value-luxe motel and diner brand with three sites (Oxfordshire, Bristol and Manchester), all running on the same API-first technology stack.
Hold every decision to the same test
Every decision we make, technology included, has to improve the stay, the job and the economics. In practice, that means three questions:
- Does it improve guest satisfaction?
- Is it financially viable?
- Does it increase employee wellbeing?
It has to be all three, all the time, even if the balance shifts from one decision to the next. Most operators trade one against the others: efficiency at the cost of warmth, or service at the cost of margin. A tool that answers only one test does not make the cut, however impressive the numbers look.
We hold AI to that test like anything else. Where it can handle a transactional task well for the guest, we use it. Mollie’s is a human brand, though, and we have no interest in passing a machine off as a person, so guests should always know when they’re dealing with one. The main benefit so far has been speed, but it still makes mistakes, so we adopt it cautiously and refine it through small trials before rolling anything out across all our sites.
Get your data somewhere you can reach it
Most hotels already hold the data they need to run better, yet very few have the systems to act on it. It sits across siloed tools and legacy platforms, and much of it only moves when someone copies it across by hand.
At Mollie’s, the first step was visibility. We brought data such as corporate booking information into one place, and that clarity is what made automation possible.
Getting to the data is only part of it, because it also has to be structured consistently enough for AI to read across it, or every model you put on top inherits the same gaps. At Mollie’s, we have found that most AI strategy failures are data-layer failures mistaken for AI failures. Our rule is that no operational system doubles as the reporting system: the property management system (PMS) is a ledger, not an analytics tool. Data flows out of each system into one shared layer, and agents and reporting sit on top of that rather than being wired to each other. Occupancy is a good example. Our commercial definition excludes out-of-order rooms from inventory, because a room we cannot sell should not count against the revenue team. USALI (the industry’s standard accounting framework) and STR (the global hotel benchmarking service) both keep those rooms in. Neither is wrong, but a model reading across systems that use different definitions will compare numbers that were never alike, and give you a confident answer to the wrong question. So both definitions now sit in our data layer, clearly labelled, and every report states which one it uses.
Bookings from travel management companies sometimes arrive with the guest’s title merged into their first name, a small fault that is enough to stop that guest using our self-service kiosk and send them to reception. An automation now repairs that kind of fault at source, before the guest ever reaches the kiosk.
What it looks like in practice
We have three sites open, a fourth in development at Edinburgh Park, and more to follow. A centralised support model is essential to delivering value-luxe. Bookings, marketing, finance, supply and brand (the work that would pull an on-property team off the floor) sit with a central team that stays small by design. We treat it as architecture rather than overhead, because it is how boutique quality holds at motel economics. As bookings grow, so does the finance and data work behind them, and at some point, a manual approach can’t keep pace. Efficiency at scale is not a bigger team running more sites; it is the same centre absorbing them. Every automation after the first is cheaper than the last, and taking it to the next site is configuration, not build. The cost of the centre barely moves as sites are added, so with scale, the returns compound.
We now have more than 50 automations live across reservations, finance and front of house. Four flagship workflows proved the approach in June, and the three we fully quantified have removed 487 hours of human effort to date across 13,634 bookings:
- Invoice checking: An agent reads every invoice from one corporate travel partner against its contracted terms and passes anything needing judgement to the team. More than 65% of those invoices used to need correcting; now it is circa zero.
- Reference matching: Another partner requires a unique reference that only appears on its booking confirmation email, so for six months, every invoice it sent was declined. An automation now writes that reference into the reservation before the invoice is generated, and the declines have stopped.
- Payment reconciliation: At one site, we matched and closed 3,500 stays against Expedia payments in 45 minutes, work that had taken two finance colleagues four full days by hand.
Everything here is back-office by design. None of it touches the guest directly, and that is the point. Judgement stays human; mechanical matching does not. And the accuracy matters more than the hours. A system doesn’t tire or skip a check on a busy Friday, and errors removed before they are made show up as cashflow that isn’t delayed and margin that doesn’t leak. The hours saved have to go somewhere, and at Mollie’s they go back to the floor, because you can’t systemise warmth. You see it at check-in: every guest who checks themselves in at the kiosk frees a team member for a guest who actually needs one.
Keep the stack open
Running a best-of-breed stack asks something of your team, because instead of finding workarounds to force rigid systems to behave, people have to start from the output they actually want and build towards it. That is a different skill from the one most hotel teams were built around, and it rewards people who can think in processes before they automate. The payoff is flexibility, the freedom to adopt new tools as they emerge without being tied to infrastructure that slows you down.
At Mollie’s, we don’t need every platform to build its own agentic solution. When the data is exposed, we’re not locked in, and we’re not paying several vendors to develop overlapping features that then get in the way when we want to analyse across them. Once you can run AI models over open data, a lot of the AI built into individual applications starts to look redundant.
A single platform makes every choice for you, so we built the stack as a kit of parts instead. Each system should be the best in its domain and chosen to be replaceable: better tools integrate, and obsolete ones are replaced without dismantling anything around them. What lasts is how the parts connect, through the API, the event stream and the guest identifier. The joint is the asset, not the part. So every vendor, incumbents included, is held to the same short list of non-negotiables: a two-way open API (read-only is not an integration), events pushed in real time rather than polled, clean export of the full history, and data portability without an exit fee.
We built our automation layer directly on the open APIs of our property management system, Apaleo, which gives us real-time access to our own data.
Our F&B data platform, Tenzo, which pulls payroll, purchasing and sales into one dashboard, added a native connector to an AI model, an opportunity we hadn’t planned for. Because nothing in our stack was in the way, the team could start asking questions in plain language across rooms and F&B data at once.
Make experiments small enough to fail
Big technology projects are hard to deliver well and hard to measure. We try to keep things small and run experiments constantly, because you often don’t know where the win is until the data shows you. When an experiment can’t do serious damage if it goes wrong, the fear of failure goes away, and a failed test becomes useful information.
Our rollout of Apple Wallet room keys is a good example. We tested it in a sandbox, piloted it in one hotel and thought it was working, then found something that didn’t line up because no two properties are the same. We paused, fixed it and got it live, because if you wait for perfect the world has moved on by the time you get there. It is now live in Manchester and Bristol, where for circa 28% and 16% of guests respectively the key arrives on their phone before they do, with Oxfordshire to follow.
You can’t predict which tools will end up mattering, so the aim is simply to stay ready to reach for them. When you next evaluate a system, ask how you would get your data out of it and into a tool that doesn’t exist yet, and whether an AI agent could act inside it through an open API or an MCP server (the emerging standard that lets AI assistants read and act in live systems). If the answer involves a new contract or a development project, you know how much room you will have when the next opportunity arrives.
