By Marie Carlsson, HSG, September 27, 2026
How HSG selected, observed and assessed 42 hotel booking journeys for this study.
Table of Contents
1. Study purpose and scope
This study examines the booking journeys presented by small accommodation properties using third-party or integrated hotel booking-engine systems.
The purpose is to observe how these booking implementations function from the perspective of a prospective guest, with particular attention to booking flow, information and price transparency, confidence and continuity, mobile navigation, interface behaviour, and overall ease of use.
The study is observational rather than experimental. It is not intended as a technical audit of the booking platforms, an accessibility audit, a legal compliance review, or a professional UX assessment.
Observations are limited to what can reasonably be encountered during a normal prospective booking journey without completing a real transaction.
The principal unit of observation is the individual hotel booking implementation, rather than the booking-engine software product in isolation.
2. Sample
The study comprises 42 accommodation properties.
The sample focuses primarily on small accommodation businesses, including hotels, inns, B&Bs, motels, guest houses, cabins, lodges and small resorts.
Property size ranges from very small establishments with only a few accommodation units to properties with approximately 35 rooms or units. Based on the recorded sample:
- 19 properties have fewer than 10 rooms or accommodation units;
- 19 have approximately 10–19 rooms or units; and
- 4 have 20 or more rooms or units.
The approximate median property size is 10 accommodation units.
Because some properties comprise cottages, cabins, suites or villas rather than conventional hotel rooms, size is treated as an approximate count of rooms/accommodation units rather than strictly hotel bedrooms.
Original descriptive property-type labels are retained in the source data. These include distinctions such as inn, B&B, boutique hotel, motel, cabins/lodges and resort. Broader property-type groupings may subsequently be used for summary analysis, while preserving the original descriptions.
3. Sampling approach
The sample is purposive and exploratory rather than statistically representative.
Properties were selected primarily to expose the study to a varied range of booking-engine providers and booking implementations.
Geographic variation was introduced deliberately as part of this discovery process. The intention was not to create a geographically representative hotel sample, but to increase the likelihood of encountering different booking technologies, provider ecosystems and implementation approaches.
The resulting geographic distribution is:
- United States: 18 properties
- England: 7
- Scotland: 4
- Australia: 10
- New Zealand: 1
- India: 2
The geographic proportions should therefore not be interpreted as representative of accommodation supply, hotel technology use or booking-engine market share in those countries.
Similarly, the number of observations associated with each booking-engine provider reflects the discovery-led sampling process rather than provider prevalence in the wider market.
4. Booking-engine/provider coverage
The 42-property sample contains a deliberately broad range of booking-engine systems and provider implementations. Observed providers or associated booking domains included:
- ResNexus — 5
- ThinkReservations — 5
- Little Hotelier / book-directonline.com — 4
- Cloudbeds — 3
- SiteMinder / direct-book.com — 2
- eviivo — 2
- Hostaway — 2
- RMS Cloud — 2
- STAAH / SwiftBook — 2
- eZee / ResAvenue — 2
- Beds24 — 1
- freetobook — 1
- Guestline / The Access Group — 1
- GuestPoint / bookus.direct — 1
- GuestRoomGenie — 1
- Hop Software — 1
- Lodgify — 1
- NewBook — 1
- Profitroom — 1
- ReservationKey — 1
- WebRez — 1
- Wix Hotels / HotelRunner — 1
- Zonal / High Level Software — 1
Repeated observations of the same provider may reveal differences between individual implementations. They should not, however, be treated as controlled tests of the underlying software because hotel configuration, website integration and third-party development work can differ.
Provider frequency within the sample must not be interpreted as an estimate of market share.
One property initially identified as using GuestPoint / bookus.direct during the August discovery stage was found to be using Little Hotelier / book-directonline.com when observed again on 21 September 2026. The later observed provider was used for the scored analysis.
5. Property and implementation metadata
A contextual first-pass record was created for each property before or alongside the detailed booking observation.
The following fields were recorded:
- Hotel/property name
- URL
- Property type
- Engine/provider
- How the engine/provider was identified
- Location
- Approximate room/accommodation-unit count
- Website platform/build, where identifiable
These fields provide context for interpreting the booking observations but are not themselves treated as quality scores.
Property type is recorded descriptively. Where broader comparison is useful, these original labels may subsequently be grouped into categories such as hotel, inn/guesthouse, B&B, motel/roadside accommodation, cabins/lodges/villas, and resort.
Approximate property size is used only as contextual information. Exact counts were not always available, and ranges or mixed accommodation types are retained where appropriate rather than converted into falsely precise values.
6. Identification of booking-engine providers
Booking-engine providers were identified using one or more publicly observable indicators.
These included:
- visible “Powered by” or equivalent provider attribution;
- the booking-page URL or domain;
- publicly accessible page or source code;
- identifiable platform references within the booking journey; and
- combinations of these indicators where a single source was insufficient.
The method used to identify each provider was recorded for the individual property.
Some booking systems may operate through white-labelled domains, reseller arrangements, integrations or other third-party layers. Provider identification should therefore be understood as observational identification rather than a technical systems audit.
Where attribution is uncertain, the evidence used should be retained rather than presenting an inference as confirmed fact.
7. Observation perspective
Each booking journey is assessed from the position of a prospective guest attempting to make a direct reservation.
The observer follows the interface as presented rather than testing hidden technical functionality or attempting to determine how the system operates internally.
Observations therefore address questions such as:
- Can the guest understand the available room and rate choices?
- Can important cancellation, payment and pricing information be found before commitment?
- Can the guest move backwards or revise a selection without becoming trapped?
- Does the booking journey retain a meaningful summary of the proposed stay?
- Is booking information organised, readable and sufficiently complete from the guest’s perspective?
- Does the transition between the hotel website and booking environment preserve confidence and brand continuity?
- Is the journey straightforward to use on a mobile interface?
The study evaluates the presented guest experience, not the theoretical capabilities of the underlying software.
8. Observation environment
Initial property and booking-engine discovery was carried out on a 14-inch ASUS laptop running Windows 11, principally using the Google Chrome browser. This desktop environment was used to locate suitable properties, identify booking-engine providers and inspect publicly accessible booking URLs, provider attribution and page/source code where necessary.
The booking journeys themselves were subsequently examined on a physical Samsung Galaxy A36 5G smartphone. The device was running Android with Samsung One UI 8.5.
The principal browser used for the mobile observations was the DuckDuckGo browser app. Where a property website or booking engine did not display or function adequately in DuckDuckGo, the Samsung Internet browser was used instead. Such browser changes were made only where necessary to enable observation of the booking journey.
The use of a physical smartphone, rather than browser emulation or a resized desktop browser window, was intended to reflect the booking experience presented to a guest using an actual mobile device. This allowed observation of behaviours that may not be apparent in desktop emulation, including mobile viewport sizing, scrolling, touch interaction, on-screen keyboard behaviour and the positioning of booking controls and information.
The same smartphone and principal browser were used across the study where practical in order to reduce variation attributable to device or browser differences.
Where a browser-specific display or functionality problem was encountered, it was treated cautiously. The study records the guest-facing behaviour observed but does not assume that such behaviour necessarily originates from the booking engine itself rather than the browser, hotel website, integration or another implementation factor.
9. Booking scenario
A broadly comparable booking journey was used across properties where practical.
The observer followed a normal prospective booking path from availability search through room and rate selection, relevant booking stages, personal-detail entry where required, and the final payment or commitment stage. A real transaction was not completed.
The standard booking scenario was generally:
- 1 room
- 2 adults
- 1-night stay
- booking dates approximately one month in advance
- a room with breakfast, where available
- otherwise a room-only rate
- selection of one optional upsell or extra, where available
Where a property imposed a minimum-stay requirement, the minimum number of nights required for the selected dates was used instead of a one-night stay.
Exact dates varied where necessary because of availability, but the intended lead time and booking behaviour were kept broadly comparable.
Where several rate types were available, preference was given to a breakfast-inclusive rate in order to provide a reasonably consistent basis for observing rate presentation, inclusions and price progression. Where no such rate was available, a room-only option was used.
Where optional extras were offered, one was selected where practical so that the booking journey could be observed beyond the initial room/rate selection and any effect on price progression, booking summary and subsequent steps could be recorded.
The aim was not to reproduce an identical laboratory transaction at every property, but to reduce unnecessary variation while preserving a realistic booking journey appropriate to each individual property.
Observation procedure
During the detailed observation round, each property’s booking journey was followed from availability search through to the final payment or commitment stage. Whether the booking journey remained within the hotel’s main website environment or moved to a clearly separate booking domain or booking environment was recorded as a descriptive observation.
10. Coding procedure
Observed booking journeys are coded using the separate Hotel Booking Engine Study — Coding Guide.
The coding framework covers five principal dimensions:
- Booking flow and selection
- Information and price transparency
- Confidence and continuity
- Navigation and interface behaviour
- Overall guest experience
The coding guide defines each observation category and provides criteria for classifications such as poor, adequate, clear, difficult, easy, absent, partial and persistent.
Where a feature cannot reasonably be assessed, it is recorded as N/A / not observed rather than inferred.
Unusual behaviour is recorded under Notable observations instead of creating new scoring categories during the study.
This approach is intended to improve consistency across all 42 observations and reduce changes in interpretation as the study progresses.
11. Descriptive versus evaluative fields
The observation framework distinguishes between fields that describe what is present and fields that evaluate how effectively the implementation functions for the guest.
Examples of descriptive variables include:
- booking environment off-site;
- currency alternatives available;
- booking-engine/provider branding;
- detail presentation method; and
- number of major booking steps.
These should not automatically be interpreted as positive or negative characteristics.
Other fields assess observable performance or usability, including:
- cancellation-term visibility;
- rate/inclusion clarity;
- price progression;
- mobile navigation;
- back navigation;
- information organisation; and
- overall ease.
This distinction is intended to prevent the study from treating a particular design choice or technology as inherently superior simply because it is present.
12. Implementation versus platform attribution
A central limitation of the study is that an observer generally cannot determine whether a particular characteristic results from:
- the underlying booking-engine platform;
- configuration choices made by the hotel;
- the integration between the hotel website and booking engine;
- work performed by a web developer or agency;
- optional modules or provider settings; or
- another third-party component.
For this reason, findings are attributed primarily to the observed booking implementation.
An observation such as difficult back navigation, prominent upselling, weak brand continuity or unclear information organisation should not automatically be interpreted as a characteristic of every property using the same booking-engine provider.
Where several properties using the same provider exhibit a similar behaviour, the pattern may be reported descriptively, but causal attribution to the platform should still be made cautiously unless independently established.
13. Limits of observation
The study records only what can be observed during the booking journey.
It does not attempt to determine matters that cannot reliably be established from the interface alone.
For example, the observer does not infer:
- how long entered personal data is retained;
- whether abandoned bookings are stored server-side;
- the final settlement currency unless explicitly stated;
- underlying payment-security architecture;
- technical accessibility compliance;
- system performance under load;
- contractual features available to hotels but not enabled in the observed implementation; or
- the internal cause of an interface problem.
Where the booking engine explicitly provides information on such matters, it may be recorded descriptively, but no additional technical conclusion is inferred.
14. Observation dates and change over time
The date of each detailed booking-journey observation is recorded.
The study was conducted in two stages. Properties were identified and the initial contextual fields were recorded between 7 and 22 August 2026. The second round of detailed booking-journey observations began on 13 September 2026 and ended on 23 September 2026.
Booking websites and booking-engine implementations can change through software updates, hotel configuration changes, redesigned websites or changes in commercial settings. The detailed findings therefore describe the implementations as observed during the second-round study period and should not be treated as permanent characteristics of the properties or software providers.
Where information recorded during the initial August discovery round differs from what is encountered during the later detailed observation, the later observed state should be used for the booking-journey analysis, with any material change noted where relevant.
One property initially identified as using GuestPoint / bookus.direct during the August discovery stage was using Little Hotelier / book-directonline.com when the detailed observation was conducted in September. The later observed provider was used for the scored analysis, while the earlier identification was retained as a change-over-time note.
15. Interpretation of results
The study is designed to identify patterns, contrasts and notable examples within a deliberately varied sample of small-property booking implementations.
The results should not be used to estimate:
- booking-engine market share;
- the prevalence of specific features across the hotel industry as a whole;
- national differences in hotel-booking technology;
- the performance of all implementations of a particular provider; or
- statistically representative rates for the wider accommodation sector.
Findings are reported in relation to the observed sample rather than generalised to hotels as a whole. For example, results may be expressed as “Among the 42 observed booking implementations…” or “In 12 of the 42 observed booking journeys…”. Provider-specific observations similarly refer only to the implementations observed and should not be interpreted as a comprehensive assessment of that provider’s product.
16. Researcher and study limitations
The observations are conducted and coded by a single researcher.
This supports consistency of perspective across the sample, but it also means that interpretive fields are not independently coded by multiple observers.
The coding guide is used to reduce subjective variation by defining the criteria applied to each category.
The study is intended as a structured independent observation exercise rather than academic or statistically representative research.
Its value lies primarily in the consistent examination of real booking journeys, the breadth of implementations observed, and the recording of concrete guest-facing behaviour across the sample.