The guest’s phone
Directory, dining, facilities, room service and live order status. The in-room tablet is the same application with a layout mode set — not a second product.
The platform
Three systems. Everything else is a view over them.
Strip the marketing away and a hotel guest-experience product is three things wearing ten names: somewhere to keep what you offer, something to route what guests ask for, and something to tell everybody what happened. We built those three properly and stopped. It is why the product behaves consistently, why your team only learns it once, and why adding a module does not mean adding a system.
- One codebase for phone and tablet
- Hosted in the EU
- No app to download
One
The content engine: what you offer
Your directory, your outlets, your catalogue and your prices, entered once and read by every surface.
Everything a guest can read or order lives in one place. Categories and information pages replace the printed room folder. Restaurants, bars, the pool, the spa and the meeting rooms are the same kind of record with a different kind set on them, because a pool session and a table booking are the same shape — a claim on a limited thing at a time, routed to a department.
Opening hours are the part everybody underestimates. A window can cross midnight, so a bar open until one in the morning is not closed all evening. A restaurant serves breakfast, lunch or dinner with its own hours, days and seatings for each. A day the kitchen is shut returns no times at all rather than accepting a booking and refusing it later.
Prices carry the rules a property actually uses: a different price on a Saturday than a Tuesday, a children’s band with the ages your property uses rather than the ones the software assumed, and a list you replace as a sheet rather than editing line by line — which is the only way a line somebody deleted actually goes away.
Two
The request router: what guests ask for
A basket becomes tasks. Each one lands with the department that owns it, ageing against a target.
- Split by department
- A club sandwich and two extra towels in one basket become two tickets for two teams, not one task nobody owns. The split follows what the item is, not who tapped it.
- A state machine, not a status field
- Submitted, acknowledged, in progress, completed, with rejected and delayed branches. Which transitions are legal is decided in the database, so no client and no integration can put an order into a state it cannot be in.
- Acknowledgement targets
- Per department, with the queue sorted by what is closest to breaching rather than by what arrived first. A breach escalates to a manager on its own rather than waiting to be noticed.
- Bookings, not orders
- A table or a sunbed is a claim on a seat at a time, so it has its own rules: seats left, tables left in that room, how many people are actually in the room, lead time, and whether the slot has already passed.
- Charge to room
- Recorded on the order, with what was charged and to which stay. Card payment is a later addition rather than a prerequisite.
- A full audit trail
- Who moved it, when, and from what to what. It is what lets you answer a guest complaint with a fact rather than a recollection.
Three
The messaging hub: what everyone is told
Live status to the guest, the ticket to the right queue, a push when it moves — and a cap so nobody is spammed.
Status reaches the guest’s phone as it changes, over a stream rather than a poll. Threads go to a department inbox rather than to a person who went off shift at four. Push notifications are addressed by a rule rather than a list: a guest stops being reachable at the moment their stay ends, checked on every send, not when somebody remembers to prune a list.
Promotional sending is capped per guest per day across the whole property rather than per campaign, because per campaign is a cap that means nothing — three campaigns simply send three times. Transactional messages about an order a guest placed are never capped, and must name the stay they belong to, so a kitchen can tell its own guest the food is coming and cannot address the property.
The payload carries only the words to show and where to go. No order contents, no guest name, no room number: it travels through a third party and lands on a lock screen in a public place. Anything private is fetched behind the session when the guest taps through.
The surfaces
Three ways in, one system underneath
Your team’s queue
One screen per department, oldest first, two taps to acknowledge. Housekeeping never sees the kitchen’s queue, and that is enforced in the database.
Your console
Content, catalogue, prices, opening hours, rooms, teams and reports. A manager changes it at eleven at night without raising a ticket.
What the database decides
Anything a client could lie about is settled in SQL
Price, availability, department routing, who may see what, and which status transitions are legal. The console hiding a button stops nobody who can read HTML and post a form.
This is the least visible decision in the product and the one that matters most over time. Rules that live in application code get copied, drift, and eventually disagree — the phone offers a table the console thinks is gone. Rules that live in the database are checked once, for every caller, for ever, including the integration somebody writes in two years.
It is also what makes tenant isolation real rather than aspirational. A cross-tenant leak between two competing hotels is not a bug you recover from commercially, so it is not left to be remembered.
Questions
The usual ones
Is the in-room tablet a separate product?
No. The tablet runs the same application as the guest’s phone with a layout mode set, so the content, the prices and the opening hours are the ones you already entered. Most vendors sell the tablet separately because in their systems it genuinely is separate; ours is one codebase with larger touch targets and an idle reset.
Do guests have to download an app?
No. A guest scans the card in the room, gives the surname on the booking and is in. They can add it to their home screen afterwards if they want to, on iPhone and on Android, but nothing requires it and nothing is gated behind it.
What happens when the Wi-Fi is bad?
Submissions queue locally and retry, and the guest sees an optimistic state rather than a spinner. Live order status arrives over a server-sent event stream rather than polling, so a weak connection costs latency rather than correctness.
Can two hotels in the same group see each other’s data?
No, and that is enforced by the database on every single query through row-level security rather than by application code that has to remember. A test suite runs as the application’s own restricted role and attempts to breach the tenant boundary on every build.
Which languages does it support?
Every content-bearing row carries its translations with it, so a category, a menu item, an opening hour or an information page can be written in as many languages as you serve. The guest sees their own; your team sees yours.
“Anything a client could lie about — price, availability, who sees what — is decided in the database, not in the app.”
Twenty minutes, and you’ll know.
We will put your own property into the demo before the call, so you are looking at your restaurants and your rooms rather than somebody else's.