Patient booking systems: a buyer's test checklist

Map what can actually be booked

Create a matrix of appointment types, duration, locations, clinician availability, rooms and equipment. Record which appointments require staff review rather than immediate confirmation. Separate the administrative booking journey from any clinical assessment process.

Decide what patients need to know before choosing a slot: location, format, price information where applicable, preparation and cancellation arrangements. Keep these details under named ownership so an operational change does not leave the website showing outdated instructions.

Run a realistic demonstration

Try two people booking the last available slot at the same time.
Change a clinician's availability after a patient has started booking.
Cancel an appointment and check both the diary and the patient confirmation.
Attempt a booking on a narrow screen with keyboard-only navigation.
Check how staff identify an existing patient without creating a duplicate record.
Simulate an unavailable diary connection and inspect the message and recovery queue.

Distinguish a request from a confirmation

If a submission only asks the reception team to arrange an appointment, say that clearly. Do not show a confirmed time until the system responsible for the diary has accepted it. Give the patient a useful reference and explain the next step.

Document who handles failed payments, incomplete requests and rescheduling. Where third-party payment or messaging tools are involved, test their failure paths too. A successful payment and a successful booking are separate events that need to be reconciled.

Agree acceptance and handover

Choose a small set of tasks for reception staff and patients to complete using fictional records. Record whether they finish, where they hesitate and what staff must repair manually. Ask the supplier to show how you retrieve the records and audit a booking change.

Before launch, assign owners for appointment rules, account access, support escalation and the fallback process. Keep a manual route available during the pilot. Use the results to decide whether the system is ready for wider rollout rather than assuming installation means acceptance.