By Marie Carlsson, HSG, September 27, 2026
What HSG found across 42 observed hotel booking implementations.
Table of Contents
HSG examined the mobile booking journeys of 42 small accommodation properties using a wide range of hotel booking engines. The study looked at the experience presented to a prospective guest: how rooms and rates were shown, how easily choices could be changed, when important conditions appeared, how much information guests had to enter, how well the hotel’s identity carried into the booking environment, and how straightforward the overall journey felt.
The sample was deliberately varied rather than statistically representative. The findings below therefore describe the 42 implementations observed, not hotels or booking-engine products as a whole.
For details of how the properties were selected and observed, see the Hotel Booking Engine Study — Methodology. Definitions for each classification are available in the Hotel Booking Engine Study — Coding Guide.
Key findings
1. Most booking journeys worked, but genuinely easy ones were uncommon
Of 41 assessable booking journeys, 28 were rated adequate overall, 6 easy and 7 difficult.
The dominant experience was therefore workable rather than effortless. Serious technical failure was uncommon; more often, relatively small points of friction accumulated across forms, navigation, information presentation, progress indication or payment reassurance.
This was one of the clearest themes of the study: the difference between an adequate booking journey and an easy one was often the accumulation of smaller implementation decisions rather than one major defect.
2. Room presentation was one of the strongest areas
Room presentation was rated strong in 27 of 41 assessable implementations and adequate in the remaining 14. None was rated poor.
In most journeys, guests were given enough imagery and information to understand the accommodation and distinguish between room choices.
In some cases, the room presentation remained on the hotel website while the booking engine functioned more like a transactional checkout. The result therefore reflects the booking journey available to the guest rather than the booking-engine software in isolation.
3. Guests could usually change or undo booking choices
Changing dates, room or rate was rated easy in 25 of 41 assessable journeys, with only four rated difficult.
Discarding an already selected room was even stronger: 32 of 41 implementations made this easy, while only four were rated difficult.
Together, these results suggest that most observed booking journeys gave guests reasonable control over revising or undoing their selections rather than locking them into an early choice, even where this relied on the browser back arrow rather than a dedicated booking-engine control.
4. Booking summaries were common, but full journey progress was not
Booking-summary visibility was exceptionally strong. 32 of 41 assessable journeys kept a summary persistently available, and the other nine provided it during part of the journey. None left the guest without a summary until the final stage.
Progress indicators were much weaker. Only 2 of 41 assessable journeys clearly represented the full booking progression; 24 were limited and 15 had no meaningful indicator.
A recurring reason was that the formal progress indicator began only after the guest pressed Book, excluding earlier date, guest and room selection even though those stages formed a substantial part of the guest’s actual journey.
5. Form burden varied considerably
Guest-detail forms were rated heavy in 18 of 41 assessable implementations, moderate in 11 and light in 12.
Observed friction included duplicated email entry, postal-address requirements, expected-arrival questions, referral-source questions, vehicle details, additional acceptance stages and other inputs beyond basic guest and payment information.
Mobile form design mattered too. Some implementations made email entry noticeably easier with appropriate keyboard controls, while others introduced unnecessary friction through poor keyboard behaviour or automatic capitalisation.
The study records the burden presented to the guest; it cannot determine whether individual fields resulted from legal requirements, hotel operating practices or booking-platform configuration.
6. Cancellation information was usually clear — but sometimes appeared too late
Cancellation terms were rated clear in 34 of the 42 implementations.
That strong result does not mean the information always appeared at the best moment. In 19 journeys, guests had to begin supplying personal details before all important booking conditions were readily reviewable.
This distinction matters. Cancellation terms can be clear once found but still appear after the guest has completed a substantial form or progressed deep into the transaction.
One of the wider findings of the study was therefore that information being present is not the same as information being presented at the right time.
7. Rate information was usually clearer than tax and payment information
Rate and inclusion clarity was strong: 31 of 41 assessable implementations were rated clear.
Tax and fee disclosure was more variable, with 24 clear, 10 adequate and 7 poor. A displayed total that merely included taxes was not treated as equivalent to showing the guest how compulsory charges contributed to the price.
Payment information showed a similar middle-ground pattern: 15 clear, 23 adequate and 3 poor. Guests could often understand the final amount while receiving less-clear information about when payment would be taken, whether a deposit was required or whether card details were being used only as a guarantee.
The study therefore suggests that showing a price and providing full price transparency are not necessarily the same thing.
8. Hotel identity usually carried into the booking journey, but seamless continuity was uncommon
Brand and ambience continuity was rated retained in 20 implementations and seamless in 4, while 9 were neutral and 9 diminished.
A booking engine did not have to remain technically inside the hotel website to preserve continuity. Hotel imagery, colour, typography and clear identity could make a separately hosted booking environment feel coherent.
Conversely, generic or strongly provider-controlled visual elements could weaken the connection with the hotel even where the underlying booking process worked well.
Provider branding itself was absent in 25 implementations, subtle in 11 and prominent in 6. Its presence was not automatically negative; the effect depended more on whether it competed visually with the hotel’s identity.
9. Payment methods were recognizable; payment reassurance was much less consistent
Every assessable payment stage — 40 of 40 — made the payment method recognizable.
Visible security reassurance was much more mixed: 14 implementations were rated clear, 13 adequate and 13 poor, with two not assessable.
Clear reassurance could come from explicit secure-payment wording, recognizable payment-provider or bank branding, PCI references or similar cues. Conventional card-entry fields alone established how the guest could pay, but did not necessarily provide the same reassurance about the payment environment.
That distinction is useful: recognizing a payment method is not the same as feeling reassured about the transaction.
10. Technical stability was generally stronger than information presentation
Interface stability and performance was rated strong in 26 of 42 implementations, adequate in 15 and poor in only one.
By contrast, information presentation/readability was rated clear in just 7 of 41 assessable implementations, adequate in 29 and poor in 5.
The booking technology therefore usually functioned reliably, while the way information was written, formatted and structured offered considerably more room for improvement.
The observations often suggested that booking systems provided mechanisms such as headings, sections, expandable content and lists that could support good presentation. The study cannot determine, however, whether weaker presentation resulted from hotel-supplied content, developer work, platform defaults or configuration choices.
What these findings suggest
Taken together, the observations do not point to hotel booking engines being broadly “good” or “bad.”
The larger weaknesses were more often found in the details: forms that asked for too much, important conditions that appeared too late, weak progress communication, inconsistent payment reassurance, information that was functional but not especially easy to scan, and some booking changes that depended on browser back arrows rather than clear in-engine controls.
For hotels, developers and booking-engine providers, the practical opportunity is therefore often not to redesign the whole journey, but to reduce unnecessary form fields, surface key terms earlier, make progress and payment reassurance clearer, improve information structure, and provide obvious controls for changing or undoing selections.
For hotel owners, that distinction is important. The booking-engine platform matters, but so does how the hotel, developer or implementation team configures and populates it. The same technology can support very different guest experiences.
About the study
The study covered 42 small accommodation properties across the United States, England, Scotland, Australia, New Zealand and India, using a broad range of booking-engine providers.
The sample was purposive and exploratory. Properties were selected to expose the study to different booking systems and implementation approaches rather than to estimate booking-engine market share or represent the hotel industry statistically.
Initial property and provider discovery took place in August 2026, followed by detailed mobile booking observations in September 2026. Each journey was assessed from the perspective of a prospective guest using a physical smartphone, without completing a real transaction.