Write down decisions that experienced staff currently make implicitly. The goal is an enforceable workflow, not a long prompt.
Which documents should you create?
- Workflow map: trigger → checks → permitted action → confirmation → exception owner.
- Data dictionary: each field, its source, allowed values and whether it is mandatory.
- Booking rules: service area, job types, duration, travel allowance, engineer competence, access constraints and approval requirements.
- Exception register: tenants, landlords, contract customers, repeat callers, complaints, unavailable slots and incomplete information.
- Approved content register: opening hours, services, authorised prices and escalation wording, each with an owner and review date.
A practical default is to create a booking request, not a confirmed appointment. Promote a workflow to live booking only when it can demonstrate all required checks against the authoritative schedule.
What is the minimum enquiry record?
For the reference missed-call workflow, use a structured record such as:
opportunity_id
source_event_id
received_at
caller_name
confirmed_callback_number
service_postcode
service_category
existing_customer_or_job_reference
customer_description
preferred_contact_window
safety_or_human_escalation_required
record_status
assigned_owner
source_system_reference
Mark missing information as missing. Do not have the model infer a postcode, property relationship or appointment confirmation.
Which data should be cleaned first?
Prioritise the records the pilot actually touches:
- Duplicate customers and shared telephone numbers.
- Customer, site and asset relationships.
- Open quotes that are already won, lost or withdrawn.
- Outdated contact details and communication preferences.
- Maintenance dates with no reliable source.
- Engineer skills, working hours and absence information used by booking rules.
Stage exit: Another member of staff can follow the written rules and reach the same operational decision.
PUT THE RESEARCH TO WORK