AI Otel’s guest app: the bill, requests and offers from one browser link

A hotel guest app is the hotel's own web app, opened from a link or QR code and added to the phone's home screen without an app store. AI Otel's guest app, Built, puts the bill, room service, spa bookings, requests and offers in one place, and an accepted offer goes onto the guest's bill.

It is 22:40. A guest wants to know what the minibar added to the bill and whether a late checkout is possible tomorrow. The front desk line is busy, and the answer exists in the hotel's system but not in the guest's hand. This article explains how a browser-based guest app closes that gap: what the guest sees, how an accepted offer reaches the bill and the kitchen, how requests reach a department, and what a hotel should prepare before switching it on.

Why a browser link instead of an app-store app?#

Because the guest does not need a download to get a working app: the hotel's link opens in the phone's browser, and the guest can add it to the home screen in one tap.

The mechanism is plain. The hotel sends the link before arrival and prints it as a QR code at the desk and in the room. The browser offers to add the icon to the home screen, and from then on the app opens like any other. There is no store, no download and no review queue.

That last point matters more than it sounds. When a hotel changes an offer or a price in an app-store app, the change waits on an update, and the update waits on a review process the hotel does not control. With a web app, the guest sees the new version on the next open. The app also carries the hotel's own name and look, so the guest does not have to find the right property inside a shared marketplace listing.

There are trade-offs, and they should be stated honestly. A browser app cannot reach every phone feature a native app can. Notifications exist but are conditional: WebKit, the browser engine behind Safari, announced on 16 February 2023 (opens in a new tab) that iOS and iPadOS 16.4 add Web Push for web apps the user has added to the Home Screen, and that such an app may ask for permission only in response to a direct user action such as a tap. In other words, the guest must first add the app and then deliberately allow notifications. Treat notifications as a bonus, never as the delivery mechanism.

The honest consequence: some guests will never open it. The front desk and the telephone must keep working exactly as before. If you are weighing this against other options, see QR page, web app or app-store app.

What does the guest see in the app?#

One page for the guest's own stay: the bill as the hotel's system holds it, room service, spa bookings, requests and the hotel's offers.

The bill comes first, because it answers the question guests actually ask at 22:40. The guest sees the charges the hotel has posted, before check-out. This turns the minibar argument at the desk into a question answered on the phone.

Room service is an order, not a phone call. The guest orders from the phone, and the order must arrive in the kitchen as a task someone can accept, not as a call written on paper and carried across the floor.

Spa bookings are slots with capacity. A booking is a time slot with a limit, so the app has to refuse a slot that is already taken rather than promise it and disappoint later. Refusing is a feature, not a failure.

Requests cover the rest: extra towels, a late checkout question, a lamp that does not work. A request is not a charge, and the two must not be mixed. Offers are the hotel's own upgrades and extras, shown where the guest already is, not in a separate email the guest may never open.

Keep one boundary clear: the app is the guest-facing side of the hotel operating system, not a second system with its own copy of the bill. AI Otel's guest app, Built, works this way: every hotel gets its own guest app, installed from the browser with no app store, holding the bill, room service, spa bookings, requests and offers in one place. Upgrades and extras are offered before arrival and during the stay, and an accepted offer goes straight onto the guest's bill.

How does an accepted offer go from yes to the bill?#

The guest taps accept, the price is posted to the guest's bill as a charge, and the department that delivers the service receives the task in the same step.

Offers run in two windows. Before arrival, the offer travels with the pre-arrival link: for example, a room upgrade at a stated price for the whole stay, so the guest decides before reaching the desk. During the stay, the offer appears in the app: for example, a late checkout or a spa slot, at the moment the guest is most likely to want it. Matching the offer to the moment is its own discipline; see matching each offer to the right moment.

The price the guest saw is the price posted. Nothing is re-keyed at the desk, which is where most manual upsell mistakes are born, not where the revenue is. The charge goes onto the guest's bill, so it is settled with everything else at check-out rather than as a separate transaction the guest has to pay twice over.

The task goes to the department that delivers: housekeeping for the upgrade, the spa for the slot, the kitchen for the extra. A declined or ignored offer posts nothing, and an offer that expires leaves no trace on the bill.

How do guest requests reach a department, and how does the guest know?#

A request becomes a logged item with an owner and a status, so it can be assigned, closed and seen by the guest, instead of living inside a phone call.

The guest sends from the phone, and the request carries the room number and the time, so nobody has to ask who called and when. Routing is a decision the hotel makes in advance: which department owns which request type, and who owns it on the night shift.

The guest sees a status: received, on the way, done. Silence is the failure mode, not delay. A guest who sees "on the way" waits; a guest who sees nothing calls the desk again, which defeats the purpose.

A request is closed by a person, not by time passing, and the open list is visible to the front office so an app request is never invisible to the desk. Requests that turn into charges, for example a bottle of wine, must post to the bill; requests that do not, for example extra towels, must not. And the same rule as offers applies: if the hotel cannot deliver, the app should say so plainly rather than accept the request and fail quietly. The wider discipline is described in log, assign and close each guest request.

What is designed and what is planned?#

Third-party extras such as transfers, tours and local experiences are designed to sit next to the hotel's own offers; flights and connectivity are planned.

Third-party extras are Architected: designed to carry transfers, tours and local experiences next to the hotel's own offers. Designed is not built, so no guest books a tour in the app today. Flights and connectivity are Roadmap: planned, not designed, not built.

The order is deliberate. The hotel's own offers are the ones it controls and delivers. A third-party extra brings a supplier, a commission question and a delivery risk the hotel does not own alone. Getting the hotel's own offers right first is not caution for its own sake; it is the only way to know the posting and routing machinery works before a partner's name is attached to it.

Read the status word before the promise. Built means working software ahead of launch. Architected means designed. Roadmap means planned. A hotel planning its own guest communication should ask any supplier for the same three words, and for the evidence behind them. The full vocabulary is in the five status words AI Otel uses.

What should a hotel prepare before switching it on?#

Decide who owns the offer list, who delivers each offer and who closes each request, before the first guest opens the link.

Name one owner for the offer list and a rule for when offers may change. A price live at 22:00 must be the price posted at 22:00. For every offer, write down the delivering department and the time it needs, so the task does not arrive at a closed kitchen.

Write the request types and their owners. A request type without an owner fails on the first busy night, not on a quiet Tuesday. Agree what the guest sees when nobody can deliver: a clear "not available" is better than a request that disappears.

Keep the desk's own tools working. The app is an additional door into the same hotel, not a replacement for the telephone. For the first week, check every app charge against what the guest saw, and fix the offer wording rather than the guest's memory.

What to do next#

Pick one offer and one request type, run both end to end for a week, and only then widen the list. The pieces fit together in one direction: the guest sees the bill and the offers in one place, the accepted offer becomes a charge and a task, the request becomes a logged item with an owner, and the hotel learns where its own process breaks before it adds anything new. To see the guest app against your own front desk and billing flow, request a briefing at info@ai-otel.com or through the contact page.