The lowest measured friction score of 12 systems

We measured real booking flows on one test property, in one market, using automated runs. Every run's raw output is posted to a public GitHub repo. The protocol was pre-registered before any run took place, so the metrics, formula and scope were fixed in advance, not fitted to the results afterward. This page reports what that protocol produced. Nothing here was measured retroactively or adjusted after the fact.

We tested 12 systems spanning four categories: hotel IBEs, PMS booking engines, channel managers and OTAs. Each system completed the same booking task on the same property, dates and party size. The set was chosen to represent how hoteliers actually sell today, not to isolate a single competitor. Full system names and configurations are listed in the public repo alongside the raw run data.

Friction is scored as `F = C + 6.6H + Fld_excess + P + 9.8I − 3.7A − 5.4Acc`. Each letter corresponds to a measurable step in a real checkout: clicks, domain handoffs, excess form fields, page-load time, interactive interruptions, address autocomplete and accelerated checkout. The formula is pre-registered and frozen. We disclose a known discrepancy in panel 4 rather than silently reconcile it.

F = C + 6.6H + Fld_excess + P + 9.8I − 3.7A − 5.4Acc

Weights: C clicks 1.0 · H domain handoffs 6.6 · Fld_excess form fields beyond 8, 1.0 · P page-load seconds 1.7 · I interactive interruption (CAPTCHA or challenge) 9.8 · A address autocomplete −3.7 · Acc accelerated checkout (Shop Pay, Apple Pay, Google Pay) −5.4. Weights are calibrated to the Form-Field Unit, where one field equals 4.1% relative conversion loss. Disclosure: the displayed formula string shows P unweighted, while the pre-registered protocol carries P at 1.7. The string is frozen as originally published; the discrepancy is disclosed here rather than silently reconciled.

Agentic readiness is scored as `ARS = 0.20·SD + 0.15·BM + 0.20·CW + 0.15·AP + 0.20·API + 0.10·PA`, on a 0–3 scale. Signals: SD structured data, BM robots/bot posture, CW CAPTCHA/WAF friction, AP express payments, API public API, PA protocol adherence. "Agent-ready" means an autonomous agent can discover and complete a booking on the open web without a private commercial agreement. This is separate from the friction score and measures a different property of each system.

We used intent-to-treat: every system starts every run, with no exclusions after assignment. Timeouts score the maximum penalty rather than being dropped from the sample. Each run resolves to one of four outcomes: reached payment, redirected off-domain, agent-blocked, or errored. This taxonomy is applied consistently across all 12 systems so partial failures are counted, not discarded.

All compared systems were tested against the same property, the same dates and the same party size. This holds the booking task constant across systems so differences in friction and outcome reflect the checkout path itself, not variation in what was being booked. Property details and configuration are published in the repo.

Friction times are modeled as lognormal. Confidence intervals use cluster bootstrap with bias-corrected acceleration and 10,000 resamples. We also ran a sensitivity analysis on the un-recalibrated click weight to check whether results depend on that calibration choice. Full statistical code is in the public repo alongside the raw runs.

No real bookings were completed during any run. No CAPTCHA solving was performed. No terms-of-service violations occurred in the course of testing. Where a system presented a CAPTCHA or similar challenge, that run was scored as an interactive interruption and stopped there.

This study covers one test property and one market; results may not generalize beyond that scope. The Mews result is provisional, based on a 3-run morning sample. Plekify sponsored this study and topped the table. We mitigate this conflict with a pre-registered protocol, a public repo of raw runs, and an open invitation to replicate or challenge the results.

The full protocol, raw run data and scraper are published in the public GitHub repo. Anyone can rerun the study, audit the scoring, or extend it to another property or market. We built it this way because a friction study that cannot be checked is not evidence. Replication attempts and disputes are welcome.