A booking request records intent; a confirmed appointment commits operational capacity. Your contract and customer script should name the level of commitment explicitly.
Use this acceptance ladder:
| Level | Required evidence in your test |
|---|---|
| Enquiry captured | Contact details and requested work are recorded |
| Request created | The office has an actionable item, with no implied commitment |
| Appointment offered | The offer respects your availability and eligibility rules |
| Appointment confirmed | The job system records the agreed slot and assignment |
| Appointment changed | Old and new records, notifications and capacity remain consistent |
Our recommended rule is: no confirmation until the authoritative job system has acknowledged the permitted booking. If the result is uncertain, communicate that uncertainty and create a visible exception for staff.
Test two callers requesting the last available slot. Also test a system that accepts a booking but fails to return a timely response. Ask how the supplier prevents a retry from creating another appointment.
This distinction matters when assessing native products too: ServiceM8’s documentation separately lists message-taking, booking-link delivery and booking submission. Treat those as distinct actions during acceptance testing. (support.servicem8.com)
Sources cited on this page
- support.servicem8.com ↗support.servicem8.com