Stage 4A: How do you build the first missed-call recovery workflow?

Route A: Configure a native receptionist

For an existing ServiceM8 user, the documented configuration route is Account → Settings → ServiceM8 Phone → ServiceM8 Phone Agent → Settings. ServiceM8 recommends starting with its Structured setup method, which uses an agent profile and business FAQs rather than an entirely free-text setup. (support.servicem8.com)

Our recommended rollout sequence is:

1. Complete the charter, data checks and escalation procedure first.
2. Choose one call mode that has a workable human fallback.
3. Enter approved opening hours, service area, services and contact procedures.
4. Configure enquiry capture rather than broad appointment authority.
5. Define what must transfer and what may become a callback task.
6. Test with staff using synthetic customer details.
7. Enable only the agreed route and review every early outcome.

ServiceM8 itself recommends beginning with one mode and testing before enabling others. Choose after-hours only if your escalation and review arrangements are suitable; “after hours” does not automatically mean low risk. (support.servicem8.com)

For visual orientation, Hazel Whicher’s August 2026 YouTube tutorial covers setup modes, structured configuration and testing. Treat a walkthrough as implementation help, not independent evidence of performance. (youtube.com)

Route B: Build a restricted cross-system workflow

The following is a recommended architecture, not a claim that any named connector supports every step:

Telephone event or approved enquiry form
        ↓
Validate source and assign event ID
        ↓
Capture only required enquiry fields
        ↓
Check service area, scope and existing records
        ↓
Create draft enquiry / review task
        ↓
Human verifies details and decides next action
        ↓
Authorised update in job-management system
        ↓
Confirm result and log outcome

Implement it in this order:

1. Create business-owned accounts. Use named administrators and an agreed recovery method; do not make an employee’s personal account the only owner.
2. Connect a test trigger. Use a supported connector or approved API route. Confirm webhook authentication or the equivalent source-validation method with the implementer.
3. Assign a unique event ID. Store it with the outcome so a repeated delivery can be recognised.
4. Validate fields. Reject missing mandatory data into a review queue instead of inventing values.
5. Search existing records conservatively. Treat ambiguous matches as exceptions; a shared telephone number should not automatically merge customers.
6. Create a draft or task first. Restrict the initial workflow to the smallest useful write action.
7. Require human approval. Display the captured details and intended action before approval.
8. Check the destination result. Do not tell the customer that a booking or change succeeded merely because the AI attempted it.
9. Separate failed and uncertain outcomes. An uncertain write needs investigation before retrying, to avoid creating duplicate work.
10. Reconcile daily. Compare source events with created tasks and resolved outcomes.

What must sit outside the AI prompt?

Permissions, recipient restrictions, spending controls and write validation should not depend solely on the model obeying instructions. The NCSC explains that prompt injection can arise when untrusted content is mixed with application instructions without a reliable boundary. (ncsc.gov.uk)

Our recommended design is to give the model only the minimum information and actions needed. Treat caller speech, emails, uploaded documents and CRM notes as untrusted inputs; do not let them authorise new recipients, change bank details or broaden the system’s access.

If nobody on your team can verify these controls, keep the workflow native or pay for a narrowly scoped technical implementation—not an open-ended transformation mandate.