Search
Search by destination or service, dates and party size.
Booking and travel
Test booking journeys with AI agents.
Verify dates, availability, total price and policies before an agent reaches a controlled booking boundary.
For hotels, travel platforms, appointments, events and rentals.
Test the constraints that make a booking valid.
Scenarios combine dates, party size, inventory, fees, policy and locale instead of testing controls in isolation.
Interpret inventory
Distinguish sold out, unavailable and temporarily failed states.
Compare totals
Compare final price, fees, cancellation rules and timezone.
Select
Choose a valid room, rate, seat or appointment slot.
Reach review
Preserve the selection through the production stop gate.
Recover
Handle an expired slot, session or inventory change without silent substitution.
Keep dates, inventory and policy attached to one choice.
The assertion chain prevents a plausible result from hiding a changed rate or slot.
Valid search
Destination, date format, timezone and party size are interpreted correctly.
Comparable option
Availability, total price and cancellation terms remain attached to the selected option.
Review boundary
The chosen option reaches review unchanged, then the public run stops.
Booking failures often appear only after several correct steps.
Hidden fee
The result changes when fees appear late in the journey.
Timezone ambiguity
A slot looks valid but resolves to the wrong local time.
Inaccessible calendar
Custom date controls have no usable keyboard or accessibility-tree path.
Lost selection
Session expiry or a modal destroys dates, party size or chosen inventory.
A fast result must also be current and recoverable.
Timing is evaluated beside inventory accuracy, retries and final-state preservation.
Session recording
Replay search, comparison, expiry recovery and final review.
Completion time
Measure search response, inventory refresh, rendering and recovery waits.
CLS and target movement
Detect shifting calendars, rate cards, modals and review actions.
State preservation
Assert that dates, guests, option and policy survive each transition.
Public runs stop before a real booking or payment.
Modification and cancellation are tested only with approved sandbox fixtures. Production actions require a separately authorized protocol.
The audit covers dynamic inventory as well as page structure.
Signals are recorded for diagnosis even when they do not directly change readiness scoring.
- Event, Hotel, LodgingBusiness and Offer structured data
- Date, time, timezone and locale semantics
- Calendar and modal accessibility
- Inventory APIs, caching and session persistence
- Hydration, CLS, network and console behavior
- OpenAPI, MCP or WebMCP when present
The result explains where booking intent was lost.
- Journey and inventory assertions
- Session recordings with timing aligned to state changes
- Price, fee, policy and timezone discrepancies
- Recovery findings with reproduction steps
- Prioritized engineering backlog and retest baseline
Booking audit questions
Do public tests create real bookings?
No. The run stops before the final booking or payment action.
Can cancellation be tested?
Yes, with approved sandbox bookings and explicit fixtures.
How are changing prices handled?
The run records timestamps, inputs and observed states so expected inventory movement is distinct from inconsistency.
Practical testing guide
Model booking state before running an agent.
Use the booking task, timezone, inventory, policy, expiry and stop-gate contracts to build a repeatable scenario.
Read the booking testing guideProtect the path from search to booking review.
Apply with one high-value search, comparison or appointment workflow for a private review.