Driving instructor booking system: book a lesson

A lesson is usually booked by a parent for a teenager, but the form assumes the person on the screen is the learner. It asks for the learner's full name, date of birth, email and a permit number. A parent may not know the number, and the learner may not have an email address yet. If the parent enters the learner's address by mistake, the confirmation never arrives, and nothing on the form warns them. The parent sees a confirmation screen either way, so the mistake looks like success.

• Does the form ask for a learner's email, and can a parent enter their own email as the contact?
• Is a permit or license number required before a time appears, or only at the end?
• If the form sends a text code, the simulated visitor stops there, since it cannot read a text.
• Does the confirmation email name the lesson time and the place to meet?

A parent usually reaches the booking from a search or a listing on a phone. The first screen should show the lesson types and the lesson length, and the times should come soon after. Many booking forms do it the other way, asking for the learner first, then the lesson, then the time. A parent who has to fill in the learner's details before seeing any time has no reason to finish. Count the screens between choosing a lesson type and seeing the first open time. If the count is more than one, the first open time is probably where the parent gives up.

Two fields can end a booking before it starts. The first is a permit or license number, which some parents do not have in front of them and some learners do not have yet. Make it optional at booking and ask for it before the first lesson instead. The second is a text code. A visitor in the test cannot receive a text message, so the simulated visitor stops at that step and the report shows where. A real parent can read a code, but only if it goes to the phone in their hand, so check the number the form uses.

Give the simulated visitor a task that matches a parent: book a first lesson for a teenager next Saturday morning, with the parent's own email as the contact. The visitor is an adult with a working email inbox, so the booking confirmation reaches it. A required permit field or a text code stops the run there, and a payment that needs a real card ends it at the payment step. The report names the step and the field, with a screenshot, so you can tell whether the stop was the learner form or the calendar. Run it again after each change and check whether the parent reaches the confirmation with the lesson time they picked still in place.

Signup flow testing

The first fix moves a field, adds an option or renames a lesson, and the form then works for a parent. Rerun the same simulated parent after each change, and again when you add an instructor, a new lesson length or a new booking tool. A new listing from a different site brings parents who arrive on a different phone with a different question.