AI Lead-to-Booking Playbook for Service Businesses

An open calendar slot is not yet a valid service appointment: the job must also fit the service area, skill, equipment, duration, safety rules, and price authority. This playbook moves one request to a verified booking, safe route, or accepted human handoff only when those facts agree.

Copy the pilot card below into a document or spreadsheet and begin with one service request. If the catalog rule or dispatcher who receives an exception is unknown, stop and repair that gap first.

Copy the pilot card and define completion

Service transition	Source to check	Allowed result	Stop or human handoff
When [service request] occurs, move from [start] to [end]	[catalog, coverage, resource, and calendar source]	[booking, safe route, quote handoff, or no action]	[scope/safety conflict and receiver]

• Start: one booking break has an owner, baseline, approved service catalog, coverage rules, and live capacity source.
• End: the request reaches a verified booking, accepted estimator/dispatcher handoff, safe alternative route, explicit follow-up state, or stop.
• Evidence: service/version, customer-stated need, location, permission, eligibility decision, booking ID, handoff receipt, correction, and outcome.
• Time horizon: one scheduling cycle including out-of-area, no-capacity, reschedule, cancellation, urgent/safety request, duplicate, and opt-out.

Roles and prerequisites

Role	Owns	Approves	Receives handoff
Service catalog owner	Scope, exclusions, duration assumptions	Service answer	Scope ambiguity
Dispatcher/operations	Coverage, skills, equipment, capacity	Appointment	Resource conflict
Commercial owner	Price, estimate, deposit, promotion authority	Financial wording	Estimate exception
Safety/escalation owner	Urgent and hazardous scenarios	Safe route	Risk signal
Workflow owner	Pilot, QA, and expansion	Keep/pause/expand	Cross-team issue

Map service code, scope and exclusions, service area, travel rules, skill/equipment, duration buffer, calendar, estimate/deposit authority, verified contact, consent, active job/complaint, and stop state. Publish emergency and out-of-scope routes before launch.

Phase 1: map request, resource, and booking state

• Owner: dispatcher with catalog owner.
• Inputs: catalog, coverage map, roster, calendar, CRM/job system, message events.
• Actions: trace inquiry through scope check, safety screen, resource match, booking, reminder, completion/change, and follow-up.
• Output: source/state map with owner, freshness, and precedence.
• Exit gate: every eligibility fact and resource has an authoritative source.
• Escalation/rollback: stop when calendar availability cannot be tied to the required skill/equipment or location.

Phase 2: select one service transition

• Owner: workflow owner.
• Inputs: journey evidence, baseline, common request types, reversibility.
• Actions: choose one narrow job such as standard inspection inquiry to appointment; define minimum questions, no-action rules, and human routes.
• Output: transition and acceptance criteria.
• Exit gate: service eligibility and safety can be decided from approved rules without diagnosing the underlying problem.
• Escalation/rollback: route ambiguous, hazardous, regulated, or custom-scope work.

Zalo describes an appointment-management utility for Official Accounts. It supports a booking mechanism, not service eligibility, capacity, quality, or outcome. Review the source.

Phase 3: validate scope, safety, and capacity

• Owner: catalog owner for scope; dispatcher for capacity; safety owner for urgent signals.
• Inputs: customer-stated symptoms/need, location, current roster, equipment and policy.
• Actions: classify only against approved service rules; check coverage and resource bundle; route danger before commercial questions; avoid a firm estimate without authorized inputs.
• Output: eligible booking context or named route.
• Exit gate: scope, location, skill, equipment, time, and authority agree.
• Escalation/rollback: clear calendar holds and provide the approved emergency/out-of-scope path.

Phase 4: write, confirm, and reconcile the booking

• Owner: dispatcher/operations accepts exceptions and records the assigned service resource.
• Inputs: eligible context, approved message/action, live calendar and job events.
• Actions: create one idempotent booking; issue its ID only after success; revalidate before reminders; record changes and cancellations.
• Output: booked, changed, cancelled, routed, stopped, or human-owned state.
• Exit gate: calendar, job system, resource owner, and customer-facing states match.
• Escalation/rollback: suppress confirmation after partial write and restore the last verified state.

Google Business Profile documents customer-facing action links, including appointment links where supported. The source illustrates a discovery-to-action mechanism, not operational readiness. Review the source.

Phase 5: review and expand by service cell

• Owner: workflow owner with dispatcher and safety owner.
• Inputs: valid bookings, reconciliation, scope conflicts, handoffs, cancellations, complaints, opt-outs.
• Actions: review by service code, area, channel, language, shift, and crew; inspect all safety and wrong-scope cases.
• Output: signed keep/pause/expand decision.
• Exit gate: quality thresholds hold through representative demand and exceptions.
• Escalation/rollback: disable only the affected service/area/channel cell.

Fictional completed run

A fictional home-maintenance company pilots standard electrical inspections in two districts. One customer reports a burning smell at the panel and asks for tomorrow; the safety rule stops booking and displays the approved emergency instruction and human contact without diagnosing the cause. Another customer requests a routine inspection, falls inside the service area, and matches an electrician/equipment slot. The system creates booking S-318, then sends confirmation. When the technician is reassigned, the reminder check detects the resource conflict and the dispatcher accepts the reschedule. No repair, safety, response-time, or revenue result is claimed.

Service transition	Source to check	Allowed result	Stop or human handoff
Electrical-inspection request to verified appointment	Service catalog, two-district coverage, electrician/equipment roster, and calendar	Book routine inspection only after resource-backed write	Burning smell uses emergency route; reassigned technician goes to dispatcher for rescheduling

Handoff, QA, and measurement

The Trigger column is the join key between the two compact tables.

Trigger	Severity	Owner
Hazard/urgent signal	Critical	Safety/dispatcher
Scope/area/resource conflict	High	Catalog/dispatcher
Estimate/deposit exception	High	Commercial owner

Trigger	Required context	Response target	Fallback
Hazard/urgent signal	Exact wording, location, action withheld	Immediate	Approved emergency route
Scope/area/resource conflict	Service code, location, skill/equipment, slot	Before confirmation	Human assessment
Estimate/deposit exception	Request, known inputs, approved range/status	Before financial wording	Human quote

QA checks: current catalog; exclusions; service area; minimum necessary questions; safety precedence; skill/equipment bundle; duration/buffer; price authority; duplicate booking; accepted handoff; reminder recheck; rollback.

The Metric column is the join key between the two compact tables.

Metric	Definition	Baseline
Valid-booking rate	Bookings with current scope, location, resource, permission, and safety state / attempted bookings	Pre-pilot replay
Booking reconciliation	Due transitions matching calendar, job, resource, and customer states / due transitions	Pilot
Safety containment	Detected critical signals with no standard booking and an approved route / detected critical signals	Safety test set

Metric	Decision threshold	Owner	Cadence
Valid-booking rate	Set before launch	Dispatcher	Weekly
Booking reconciliation	Set before expansion	Workflow owner	Weekly
Safety containment	100% required	Safety owner	Weekly

Failure	Early signal	Corrective action
Wrong scope, area, skill, or equipment	Eligibility/resource check differs from catalog, coverage, or roster	Clear the hold and send the case to the catalog owner or dispatcher/operations
Diagnosis, hazard, or unapproved estimate	Safety term or financial claim appears without the declared owner	Stop standard booking and route to the safety/escalation or commercial owner
Duplicate/partial booking, stale reminder, or orphaned handoff	Reused key, missing booking ID, cancelled state, or no owner acceptance	Suppress the message, restore the last verified state, and require dispatcher/operations acceptance

Pause the affected service, area, or channel cell until correction is verified.

Frequently asked questions

How many questions should qualification ask?

Only the approved minimum needed to identify service category, location, resource need, timing, and safety route. Do not turn chat into an unreviewed diagnostic interview.

Can the assistant give a fixed quote?

Only where the service and inputs meet an authorized fixed-price rule. Otherwise explain the estimate process and route to its owner.

Should every open calendar slot be offered?

No. Offer only slots tied to the right service area, skill, equipment, duration, travel buffer, and business rule.

What should happen before a reminder?

Recheck booking status, assigned resource, material change, customer consent, and active complaint. Suppress or correct when state changed.

What to do after completion

Limits. This is not diagnostic, trade, safety, emergency, pricing, or legal advice. It claims no booking, response, service, or revenue benchmark, integration, or Easy AI capability.

Use the lead-response guide for response ownership, the appointment reminder template for a reconciled booking, and the AI-to-human handoff guide for exception context.