Designing Guest-centric Digital Ecosytems for Hotels

If you're running a boutique in Marylebone or a 400-key upscale property in Riyadh, you've likely sat through three "hotel app" pitches already this year. Most of them miss the argument they should be having with you. The technology behind these products has matured to the point where it is close to a solved problem. What has not moved is the strategic frame most of the pitches arrive in, which treats an app as a discrete product the hotel buys and installs on the guest's phone, when it should be treating the app as one layer inside a much wider ecosystem the guest is already living inside from the first moment, they Google the property.

The Marriott and Accor numbers keep getting quoted for good reason. Marriott's app now drives more room nights than any other single channel across the group's direct digital estate. Accor's ALL app grew booking volume 45% in 2024 and crossed 100 million loyalty members in 2025. Elsewhere in the same market, fewer than 20% of guests download a branded app for a one-time stay, and about a quarter of the guests who do download abandon it after their first session. Sitting between those two poles is where every hotel technology programme actually lives.

‍

What a guest-centric digital ecosystem actually is

An ecosystem is a set of joined-up touchpoints running on shared identity and shared preference data. The booking engine, the loyalty account, the native app, mobile responsive website, in-room controls, F&B ordering, spa reservations, the staff-facing PMS, and the post-stay CRM should all read from and write to the same guest record. Continuity for the guest and a single operational profile come out of that shared record. The mobile app plugs into that system as one of its components.

citizenM is probably the current textbook case for what this looks like when it works. The app itself is bold, playful, and reasonably feature-complete: booking, digital key, in-room controls for lights and blinds, F&B, a "citizen passport" gamification layer. Anyone who has actually stayed at a citizenM will tell you the coherence of the experience comes from the way the app, the website, and the physical ambassador model at reception all use the same brand language on the same data layer, more than from any specific feature the app happens to have. Frictionless check-in is what falls out of that architecture downstream.

‍

Why most hotel apps fail

Most branded hotel apps end up as check-in wrappers the guest downloads under mild pressure at the front desk, uses digital key twice, and deletes somewhere over the Atlantic. The property paid six or seven figures for the build and will not see a durable return on it.

Some hotels were built for a guest who was never coming back to begin with. Where the mix skews leisure and independence, most of those guests will not return to the same flag inside a year and asking them to install a 90MB app for a three-night stay is asking them to do work for no meaningful reward. Consumer research suggesting that 78% of people abandon a transaction when they are asked to download an app should tell you to route that interaction somewhere lighter.

Other hotels ship whatever their org chart requests. F&B wants ordering, spa wants booking, marketing wants a loyalty layer, security wants two-factor on everything, and what lands in the app store does eleven things poorly. Guests hunt for the digital key on the second screen, give up, and open the app exactly once before writing it off.

The most damaging pattern is building the app as though it lives on an island next to the loyalty programme, the website, and the on-property experience. Where the front desk agent cannot see what the guest just told the app about pillow preference, dinner reservations, or arrival time, all of the technology in the building starts to read as theatre.

‍

How to design one guests will actually use

Start with customer insight, because features chosen without it always ship the wrong things. A guest journey has maybe six to eight moments where digital genuinely helps: shortlist, book, pre-arrival personalisation, arrival, in-stay service, F&B, checkout, post-stay. Look hard at yours and cut the moments where a human interaction is the actual point of the encounter.

Beyond that, the operators getting this right converge on similar habits.

Meeting the guest where the guest already is starts to sort itself out once you separate occasional stays from loyal ones. For occasional stays, a well-designed mobile web experience will out-convert a native app because there is no download tax between the guest and the room. IHG's rebuilt digital platform, which picked up Webby recognition in 2024, leans deliberately toward loyalty members for exactly this reason; those are the guests whose lifetime value justifies the install ask in the first place.

They solve one friction properly before adding another. Hilton spent years getting digital key reliable enough for daily use, including the shareable version that lets a couple or a family both hold access, before layering on conversational check-in. The order of operations was deliberate; a digital key that fails 5% of the time will erode trust in the entire app long before any newer capability has a chance to shine.

Integration budget matters more than most operators want to hear. The ecosystem argument falls apart when the app is quietly collecting information the housekeeper and the F&B server never actually see. That integration work is the boring, expensive part of the programme, and in most of the ones we've looked at it runs to about 40% of the total build. Underfund it and everything else starts to feel performative.

Contextual, moment-aware design is the last habit worth calling out. citizenM's contextual card, the dashboard element that shifts based on where in the journey the guest is, sounds obvious as a pattern. It is rare in practice because it requires the app team, the operations team, and the brand team to agree on what the guest needs in each moment, and most organisations struggle to get those groups in the same room, let alone aligned on that answer.

When to build an app versus a web-first ecosystem

Not every property should have a native app. The question is whether repeat behaviour justifies the install cost.

Global loyalty operators like Marriott, Hilton, Accor and IHG have earned the right to a native app. Members stay across dozens of properties a year and the app pays back its download cost many times over. Marriott has reported a 78% jump in mobile-app active users since 2019, sitting on top of a Bonvoy base of hundreds of millions of members, and that base changes the underlying economics in a way an independent 90-key property will never see.

Independent boutiques, most resort properties, and single-brand smaller portfolios usually should not build one. A responsive mobile web experience, deep-linked from confirmation emails and QR codes at check-in, delivers most of the value at a fraction of the build cost and asks the guest to install nothing. Aman has stayed almost entirely out of the branded-app race, and the choice reads consistently once you look at the brand; the promise is human service, and a phone screen between the guest and the doorman would work against that promise.

Our work with Center Hotels is a reasonable illustration of what that looks like in practice. Eight properties in Reykjavík, family owned. Instead of a native app, the group built its layers around the web experience: a booking journey re-designed with increasing direct bookings as an explicit goal, on-site messaging that meets a guest heading for the exit with a genuine reason to book direct, pre-stay emails tailored to the individual property rather than the group, and an automated response layer handling the questions that arrive by email. None of it required a download, and measured against the same period, direct bookings rose 61.3% while website conversion grew 77%.

The harder call sits in the middle. Regional groups and luxury collections with 15 to 40 properties usually end up with a lightweight native app for repeat guests plus a functionally identical mobile web experience for first timers, both running on the same backend. That arrangement works because the two flows share everything on the operations side, so the choice for the guest is only about which front door they walk through.

In all three cases, the technology question is the third thing to work out; the brand question comes first, then the operations question. If the brand team, the operations team, and the digital team are not building from a shared customer insight, whatever app the hotel eventually ships will fail to solve the deeper problem.