Hotel guest app: QR page, web app or app-store app?

A hotel guest app is the page a guest opens on their own phone to see the bill, order room service, book the spa, send a request or take an offer. Three formats exist: a QR web page, a web app installed from the browser, and an app-store app. For short stays, the first two ask less of the guest.

A guest arrives at 23:40, wants a sandwich and cannot find the room-service number. The hotel has three ways to answer that: a page behind a QR code, a web app on the home screen, or an app in a store that nobody will download at midnight. This article explains what a hotel guest app is, how the three formats differ, what the page should hold, how to put it in front of guests, and what the law allows it to ask. By the end you should be able to pick a format for your property and know what to test before printing a single code.

What is a hotel guest app, and what are the three formats?#

A hotel guest app is a page the hotel owns, opened on the guest's own phone, that holds what a guest would otherwise call the desk about. The three formats differ in one thing: how much work the guest does before first use.

A QR web page is a code at the desk, on the key card or in the room that opens a page in the phone's browser. Nothing is installed, and nothing stays on the phone after the stay. A browser-installed web app is the same page, added to the home screen so it opens from an icon like an app; on iPhone and iPad this is done from the share menu in Safari. An app-store app asks the guest to find the hotel in a store, download, install, open, and often create an account before seeing anything useful.

All three can hold the same content. The difference is distribution, plus what the phone allows the page to do afterward. The effort is paid at the moment the guest has least patience: arrival, with a bag in one hand. Remember that a guest app is one stage of a longer journey, not the whole of it; the desk, the room and the bill still have to work. If you are designing the guest journey stage by stage, the app is one stop on that map, not the destination.

What does the guest actually do, from the code to the first use?#

On a QR page the guest points the camera, taps the link and is reading within seconds. On a browser-installed web app the extra step is one menu action; on an app-store app it is a download and often an account.

The QR path is camera, tap, page loaded. There is no install and there should be no password if the hotel ties the page to the booking reference plus surname. On iPhone and iPad, the install path is: open the page in Safari, use the share menu, choose Add to Home Screen. The icon then opens like an app rather than a browser tab.

Notifications follow from that step. WebKit, the browser engine behind Safari, announced on 16 February 2023 (opens in a new tab) that web apps added to the Home Screen on iOS and iPadOS can receive push notifications, and that such an app may ask for notification permission only in response to a direct user action such as a tap. Other phones and browsers differ by maker and version; we describe only the iPhone and iPad path here because it is the one we have verified. For the rest, write one line of instructions or let the desk do it.

Sign-in is where apps lose guests. Every field costs a guest: a booking reference and a surname are usually enough to open a stay, and an email address plus a password are not. Print the code large enough to scan from a bed, a desk or a sun lounger, and put the same link in the confirmation for guests who never scan.

What should a guest app hold?#

Only the things that remove a phone call, a queue or a paper form: the bill, room service, spa bookings, requests and the hotel's own offers.

The bill comes first: what has been charged so far, in plain lines. A guest who can see it stops asking at checkout, and the desk stops explaining. Room service and outlet orders come next, with a menu, a price and an honest delivery time, and with the order landing where staff already work rather than in a separate inbox. Spa and facility bookings need a time slot the hotel can actually hold, not a request that quietly disappears. If you want the full picture of how the bill and the daily work fit together, the principle is the same one: one record, one place.

Requests are the fourth item: an extra towel, a late checkout, a taxi at 05:00. Each needs a named owner and a status the guest can see, or the app becomes a complaint channel. Offers are the fifth: upgrades and extras before arrival and during the stay, with an accepted offer going onto the guest's bill rather than into a second system. For matching each offer to the right moment, timing matters more than volume.

What not to promise matters as much as what to promise. Door keys, tours and transfers: if the hotel has not connected them, leaving them off is better than a button that fails. One test covers every item: does it remove a phone call, a queue or a paper form? If not, it is decoration.

How do you get the app in front of guests?#

Four placements do most of the work: the booking confirmation, the pre-arrival message, the desk at check-in and a code in the room.

The confirmation carries one plain link and one sentence on what it is for; this is the moment the guest has time and a reason to look. The pre-arrival message is one message with one purpose, sent close enough to the stay to be useful rather than forgotten, as covered in more detail in what to send before arrival and when. At the desk, the receptionist says one sentence and turns the screen or card around while the key is being prepared. In the room, a code sits where the guest looks when they want something: the desk card, the television screen or the key sleeve.

Consent governs the messaging around these placements. Under the Law on the Regulation of Electronic Commerce (No. 6563, Articles 6 and 8) (opens in a new tab), commercial electronic messages such as marketing emails and SMS may be sent only with the recipient's prior consent. No separate consent is needed for messages about changes to, use of or maintenance of a service already supplied, when the guest gave contact details to be reached, and a recipient may refuse commercial messages at any time without giving a reason. Keep stay messages and marketing offers in separate streams, so a refusal of one does not silence the other, and give every placement one job: a code that promises everything gets scanned once.

What are the trade-offs: notifications, offline use, updates and languages?#

The app-store app wins on notifications and offline behaviour; the browser formats win on effort, updates and cost. Most hotels do not need the first.

Notifications: an app-store app can notify by default. A browser-installed web app can too on iPhone and iPad once it is on the Home Screen, and only after the guest acts (WebKit, 16 February 2023). A plain QR page cannot. Behaviour varies by phone and browser, so promise to try, never to guarantee.

Offline use: an app-store app can keep content on the phone; a browser page needs a connection unless it was built to cache. Guests are offline in lifts, on beaches and on planes. Updates: a web page or web app updates for everyone at once, while an app-store app waits for each guest to update, and old versions stay on phones for months. Languages: check that the languages you publish match the languages your guests actually book in, and open the page in the language of the booking rather than the language of the phone.

Maintenance is the quiet cost. One web codebase stands against a store listing, review cycles and two platforms; the second is a permanent commitment, not a one-off build. And an app-store listing is a public window: it carries ratings and reviews the hotel cannot switch off, and store rules it does not write.

Privacy and access: what may the app ask for?#

Only what the stay needs. Under KVKK Article 4 (opens in a new tab), personal data must be processed for specified, explicit and legitimate purposes and be relevant, limited and proportionate to those purposes.

A bill is personal data, and so is a room number tied to a name. A guest must see only their own stay, and a code left on a table must not open someone else's account. Under Article 10, when personal data are obtained the data controller must tell the person who the controller is, why the data will be processed, to whom and why it may be transferred, the method and legal basis of collection, and the person's rights.

Special categories need more care. Turkish data protection law treats data on health, religion or belief, dress, and biometric and genetic data as special categories, prohibited except in the cases the law lists, such as the person's explicit consent. A dietary or medical note collected before arrival can fall into this group, so ask for the minimum and say why. Turkish data protection rules require clear separation between privacy notices and explicit consent requests: different headings, separate declarations, no consent text where processing rests on another legal ground, and no request to approve the privacy notice itself. Consult a legal adviser for the exact wording required for your property.

Two practical rules close the section. Access should expire with the stay: a link that opens a bill should stop working when the guest checks out. Identity is still checked in person at the desk, and a guest app does not replace that step. Confirm your own wording, retention periods and consents with a lawyer or data protection adviser before publishing the page.

Which format fits which property? A decision checklist#

Start with the smallest format that carries what your guests actually ask for, and move up only when a specific need justifies the extra effort.

Pensions and small properties fit a QR page: few rooms, staff at the desk, and the code does the repeating. City and boutique hotels fit a browser-installed web app: the guest is out all day, the phone is the channel, so start with the bill and a late checkout, the two items this segment tends to ask about. Resorts and large hotels need a web app plus a printed code in every room, because several outlets make room service and spa booking worth the build. Groups and chains should run one format across properties, one language set and one privacy notice, with content owned per property.

An app-store app is justified when there are repeat guests, a loyalty scheme, or a service that genuinely needs notifications in the background. Whatever you choose, the operating rules are the same: one named owner, one test phone kept at the desk, and one review each quarter against the questions guests actually ask.

What to do next#

Open your own booking confirmation on a phone and count the taps to the bill; that number decides which of the three formats you need. Work in this order: content first, placement second, format last, with privacy wording running alongside all three. AI Otel's guest app is built on the browser-installed format: 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, built and working ahead of launch. The guest app page describes it in more detail, and you can request a briefing if you want to compare it with what you run today.