Booking says “unavailable” while Book Now is still active?
Treat the message, selection controls, availability result, price, and booking action as separate states. These five checks turn a contradictory page into a bounded reproduction without entering customer data or completing checkout.
Use public behaviour or owner-controlled staging only. Do not place a real order, hold scarce inventory, enter another person’s information, or test a payment gateway.
The visitor is receiving two incompatible interface signals.
That inventory exists, that a booking could complete, what caused the defect, or that the business lost a customer or revenue.
Five checks, stopping before checkout
Record the contradiction before changing it
Capture the public URL, visible unavailable message, current date and time, selected product or service, and which controls remain enabled. Do not infer a backend cause from the page.
Separate incomplete, valid, invalid, and unavailable states
A booking widget should not treat “nothing selected,” “invalid combination,” and “sold out” as the same result. Ask the owner for one staging example of each state that the integration can actually represent.
| State | Useful result | Primary action |
|---|---|---|
| Incomplete | Say what is missing | Disabled |
| Valid | Show owner-confirmed option and total | Enabled |
| Invalid | Name the incompatible selection | Disabled |
| Unavailable | Say it cannot be selected | Disabled |
Trace where each visible state comes from
Check whether the unavailable notice is fixed page content, cached output, a theme override, or a response from the existing booking integration. Then check the date, guest, inventory, price, and action states independently. A stale notice and a stale widget can fail in different directions.
Define a tagged staging handoff
Use an owner-approved staging item or non-scarce test slot. The successful check ends when the valid selection reaches the existing checkout handoff. It must not create an order, payment, deposit, refund, guest record, or customer record.
Test the failure path and keyboard path
Confirm that an incomplete, invalid, or unavailable selection cannot activate the booking action; that its message remains useful at a common phone width; and that every required control and status is reachable by keyboard. Do not declare success from the valid path alone.
- Incomplete selection cannot continue
- One owner-confirmed valid selection shows the expected option and total
- One invalid or unavailable selection stops with a useful message
- Only the valid selection reaches the existing checkout handoff
- No order, payment, deposit, refund, or customer record is created
- The path remains usable by keyboard at phone and desktop widths
Booking-selection FAQ
Does the unavailable message prove online booking is disabled?
No. It proves only that the message is visible. Check dates, inventory, pricing, and the booking action as separate states.
Should the test place a real order?
No. Use owner-approved staging inventory and stop at the existing checkout handoff. Acceptance must not create an order, payment, deposit, refund, or customer record.
What is the smallest useful acceptance test?
Check an incomplete selection, one owner-confirmed valid selection, and one unavailable or invalid selection. Only the valid state should reach the existing checkout handoff.
Need the contradictory selection path repaired?
The fixed £75 scope covers one reproducible public availability or booking-selection defect in one existing licensed integration and one product, service, resource, or location. A written fit check comes first, and payment is due only after every agreed acceptance check passes.