Travel Booking Journey Audit — Conversion & Usability Sample

This is a demonstration portfolio sample, not a completed client engagement. The product, test data, and findings are illustrative. It shows how I structure a travel-booking audit, prioritize user friction, and connect QA observations to operational consequences.

Role demonstrated: Travel Technology & Booking Journey Auditor Scope: Search, fare selection, passenger details, checkout, payment recovery, and confirmation Deliverable: Four-page demonstration report with five illustrative findings Environments described: Mobile-web and desktop-web scenarios, not a verified device test matrix

The sample follows an end-to-end customer journey rather than reviewing screens in isolation. It examines pricing clarity, fare-rule visibility, field persistence, date editing, and the guidance provided after booking.

Each detailed example includes an environment, reproduction scenario, expected versus illustrative actual behaviour, and recommendation. Priorities consider customer impact, booking friction, and potential support workload; those impacts are hypotheses to validate in a real engagement.

High — Checkout total increases without explanation. The sample follows a return itinerary for two passengers from selection to checkout. It recommends showing mandatory charges and a persistent fare breakdown before commitment.

High — Fare conditions appear too late. A desktop scenario checks whether change, cancellation, and baggage rules can be understood before traveller details are entered. The recommendation is to present key restrictions beside the fare, with complete rules readily accessible.

High — A failed payment clears passenger details. The sample's declined-payment scenario forces data re-entry. It recommends safe recovery that preserves appropriate booking information and offers a clear retry or alternative-payment path.

Two medium-priority examples address losing the return date after editing departure and an unclear support or amendment path on confirmation.

These reformatted extracts are examples of reporting structure and reasoning from the original demonstration report. They are not screenshots or measurements from a live client's product.

The report proposes earlier price disclosure, clearer fare conditions, resilient payment recovery, and better post-booking guidance. In a real engagement, priorities would be checked against analytics, support data, product requirements, and release constraints.

Suggested measurement includes search-to-selection progression, checkout starts, and abandonment after payment failure. No conversion lift, revenue improvement, or implemented fix is claimed for this sample.

Want this approach applied to your travel website? Send your booking URL, priority routes or journeys, target devices, and deadline through Contra.