PatientLow clinical risk
Booking an appointment
Choosing a clinician, a place and a time from what is actually available, and receiving a confirmation that can be trusted: the appointment exists, it is with the person named, and it can be changed or cancelled without a phone call. In healthcare the booking is often the first thing a person does with a service, and the first place it can lose them.
Why it matters
A booking that fails quietly (a slot that was already taken, a confirmation that never arrives, a change that needs a call during working hours) costs the person a visit and the clinic a slot. It is also the moment a service asks for the most personal data with the least trust established.
The products in the library treat the confirmation as the product. Vezeeta's site says a booking is confirmed the moment a time is chosen from the doctor's available slots; Okadoc's app listing leads with real-time availability and booking at any hour, then reminders by SMS or email.
Products that use it
- Vezeeta · Vezeeta
The company's site describes searching by speciality, doctor name or hospital, and says a booking is confirmed as soon as the user chooses from the doctor's available times, for a clinic, a hospital, a home visit or a call. Arabic-language page; Recent's translation.
Source: VezeetaPrimary source
- Practo · Practo
The company's App Store listing describes finding and booking appointments with doctors nearby across the specialities it lists, with reminder messages about the upcoming appointment.
Source: Apple App StoreIndependent reporting
Healthcare considerations
Two things separate a clinic booking from a restaurant one. The first is urgency: a person booking because they are unwell needs to see, before they commit, how soon the next slot is and what to do if that is too late. The NHS service manual's care cards give a tested shape for that escalation.
The second is that the wrong appointment is a clinical risk in its own right: the wrong speciality, the wrong site, a follow-up booked in place of a first visit. Booking flows therefore carry the information a person needs to choose correctly (what the clinician does, where the appointment is, whether it is in person or remote) and make the consequential choices confirmable and reversible, which is what WCAG's Error Prevention criterion (3.3.4) asks of any transaction that commits a person to something.
Accessibility considerations
Booking is dense with the components that most often fail accessibility: date pickers, time-slot grids and long forms. Slot grids need pointer targets of at least 24 by 24 CSS pixels (WCAG 2.2 Target Size Minimum, 2.5.8), a keyboard route through them, and a text alternative to any colour that means “taken” or “free” (Use of Color, 1.4.1). Forms that ask for a name, date of birth and contact details should not ask twice (Redundant Entry, 3.3.7).
A confirmation should be announced, not only shown (a status message a screen reader can detect (Status Messages, 4.1.3)) and the details should survive in a form the person can find again: an email, a message, or a page that does not depend on the session that made it.
Recent analysis
Recent’s own reading, clearly as analysis. Where a product’s behaviour is described, it is worded as the company’s description or cited to an independent source.
Three products in the library (Vezeeta, Practo and Okadoc) describe booking as a marketplace problem: search by speciality, doctor or facility; see real availability; confirm instantly. What their public pages emphasise is the moment of confirmation and what happens after it: reminders, and rescheduling without a call.
What they say little about is the moment before. How a person who does not know which speciality they need is helped to choose, and how a booking flow behaves when the honest answer is that no suitable slot exists soon enough, are not described. That gap between search-and-confirm and choose-correctly is where a symptom capture step, or an escalation route, would sit, which is why those patterns are related to this one.