Day one — we build it
Your restaurants, opening hours, menus, facilities and photography, taken from what your property already publishes. You do nothing on day one.
Onboarding
Open in days, not months.
The industry quotes three weeks of setup before a guest sees anything, and the three weeks are not engineering — they are somebody typing your menus into a form. We start from what your property already publishes, so you spend day two correcting rather than week three typing.
- No DNS work for you
- One card per room, printed once
- A manager can change anything afterwards
The schedule
What the first week looks like
Day two — you correct it
A manager fixes what we got wrong and signs off the prices. No tickets and no waiting on us: it is your console and the changes are live as you make them.
Day three — cards go in the rooms
One card per room, printed once. It never expires and never needs reprinting when a guest checks out.
How guests get in
A card in the room, and the surname on the booking
No app, no account, no password — and no list of codes for reception to manage.
The code belongs to the room, not to the stay. It is printed once and resolves to whoever is staying there today. Two things guard a permanent, guessable code: the guest also gives the surname on the booking, and access ends at checkout plus a short grace period — checked on every request, not only at sign-in, so a session opened at nine in the morning does not outlive the stay it belongs to.
You choose how it is printed. One hotel-wide poster works if you allow room number entry; a code with a random suffix is the stricter option and is what makes rotating a single room meaningful. The two are mutually exclusive by design — with room-number entry allowed, a suffix protects nothing.
Surname rather than email, by default. Bookings that arrive through an online travel agent carry a masked relay address the guest has never seen, so requiring email locks out most of a resort. Email is available per property for hotels that sell direct.
Honest about
What cannot be compressed
This is the part that makes the rest of the schedule credible.
- Your content sign-off
- Somebody has to read the prices and say yes. We can have the catalogue ready in a day; we cannot approve it for you, and you should not want us to.
- Your booking system provider
- If you want arrivals imported automatically, that is a conversation with your PMS vendor and it runs on their timetable. An arrivals export needs nothing from them and works from day one.
- Staff training
- The queue takes minutes. The console takes an hour with a manager. Getting a floor into a new habit takes a fortnight of gentle nagging, whatever the software does.
- Decisions
- Which outlets take bookings, how many tables are held back for non-residents, what the weekly limit is. We can suggest defaults, but a property that has not decided these will spend longer than a property that has.
- A pilot on real guests
- Everything above gets you live. A week of actual guests is what tells you which three things to change, and there is no way to have that week faster than a week.
Bringing your data
Arrivals, without retyping a name
Tonight’s arrivals can come from your booking system as an export — which needs nothing from your vendor and removes the manual entry that makes a 500-room property unmanageable. Imports are idempotent: re-running the same file, or a nightly job, changes nothing the second time.
Dates are the trap in every import, and worth knowing we handle it properly. 03/04/2026 is either the third of April or the fourth of March. The parser inspects the whole file first: any component above twelve proves the order, a file that contradicts itself is refused rather than guessed at, and an ambiguous file tells you which way it assumed. The column mapping it detected is reported too, since guessing the reference column wrong would import every row as its own stay.
“Content entry is the real cost of launching one of these. Everything else is a week.”
Questions
The usual ones
What do you need from us to start?
Your website, a logo, a room list with room numbers, and one person who can say yes to prices. That is genuinely it for the first version. Menus and photography make it better, and we can take them from what you already publish if you would rather not send anything.
Who types in the menus?
We do, from what your property already publishes, and then a manager corrects it. That is the inversion that saves the three weeks: you spend day two checking rather than week three typing.
Do we have to reprint the room cards when a guest leaves?
No. The code on the card belongs to the room and not to the stay, and it resolves to whoever is in that room today. At 500 rooms the alternative is printing hundreds of cards a week, which is why nobody does it.
What if a code leaks?
Reception rotates that one room. The new code carries a suffix, so it is genuinely a new code, and that room is pinned to code-only entry so the room number cannot become a back door. It is an exception the desk handles rather than a tax on every sign-in.
Can we use our own domain?
Yes. A property gets a subdomain of ours by default and can point its own hostname at it instead. The guest app resolves the property from the hostname, so nothing else changes.
What does it cost to set up?
Onboarding is quoted per property, because it depends on how much content exists and how much of it we are building for you. It is a one-off, and it covers building the directory and catalogue and the first round of corrections.
Send us your website, and see it back as an app.
That is the fastest way to know whether this is for you. It costs you one email and it is the same work we would do on day one anyway.