Require the supplier to identify the precise action—not merely display a calendar integration logo. The following is the desk’s proposed capability ladder.
| Level | Actual outcome | What the caller should be told | Evidence to require |
|---|---|---|---|
| 1. Message capture | Information reaches an inbox or task list | The office will respond | Message, recipient and delivery timestamp |
| 2. Booking request | A request is created for review | The request is not yet confirmed | Request record, status and assigned owner |
| 3. Job creation | A job exists in the operational system | Scheduling may still be outstanding | Job identifier, customer/site match and allocation state |
| 4. Confirmed appointment | An authorised appointment is committed | The agreed time or service window is confirmed | System acknowledgement, resource validation and customer confirmation |
| 5. Operational dispatch | The right resource is assigned under business rules | Only the commitments that have been validated | Skills, geography, duration, access and service-priority checks |
This distinction is important when reading product descriptions: ServiceM8 documents online-booking actions, while the cited Simpro marketplace listing describes job creation. Neither wording should be stretched into proof that every contractor-specific dispatch constraint has been satisfied. (support.servicem8.com)
Which booking controls should be outside the language model?
Our recommendation is to let AI interpret the conversation, while deterministic software and approved business rules control consequential actions. The appointment workflow should check, as applicable:
- Service area and job type.
- Customer, property and contract identity.
- Engineer skills and authorisation.
- Visit duration, travel allowance and availability.
- Required parts, site access and purchase-order conditions.
- Existing bookings and duplicate requests.
- Approved pricing and cancellation rules.
Require the system to confirm success only after the operational software acknowledges the action. If an integration times out, it should not invent success; if it retries, it should not create a second job.
These are proposed engineering acceptance requirements. They are consistent with the NCSC’s emphasis on secure design, deployment, monitoring and maintenance across the AI system lifecycle. (ncsc.gov.uk)
Sources cited on this page
- support.servicem8.com ↗support.servicem8.com
- ncsc.gov.uk ↗www.ncsc.gov.uk