Appointment Booking Playbook: Create One Verified Booking

A shared calendar link does not guarantee one reliable booking. A request can be unsuitable, a slot can change, a write can time out, or an old reminder can survive a cancellation. Use the five-step booking card below to check the request, offer verified choices, create one booking, maintain it, and record the final outcome.

Completion standard

• Start state: a permitted appointment request has an assigned intake owner.
• End state: one verified booking is reconciled as changed, cancelled, completed, or unknown—or the request exits with a visible alternative.
• Evidence: eligibility result, booking ID/version, source confirmation, message receipts, change log, accepted handoffs, final outcome.
• Time horizon: from intake through the team's post-appointment reconciliation window.

Roles and prerequisites

Role	Owns	Approves	Receives handoff
Intake owner	Type, constraints, buyer communication	Eligibility exception	New request
Scheduling owner	Availability and atomic write	Conflict resolution	Selected slot
Meeting owner	Commitment and attendance state	Specialist promise	Confirmed booking
Operations	Reminders, delivery, reconciliation	Workflow expansion	System incident

Before launch, define eligible appointment types, current scheduling source, timezone policy, idempotency key, partial-write recovery, change/version rules, delivery fallback, backup owners, baseline, and pause thresholds.

In a small team, one coordinator may combine intake, scheduling, reminders, and reconciliation. The meeting owner still approves suitability and commitments outside the coordinator's authority. First action: copy the five phase headings and fill the appointment type, requester, meeting owner, timezone, and approved scheduling source.

See the card in a completed run

Fictional requester Linh asks for an onboarding session with two attendees in different timezones. Intake owner Hoa confirms the session type and routes a language requirement to meeting owner Alex before offering slots from the approved fictional scheduling source, training calendar TC-4. Linh selects 09:00 ICT (UTC+7) on 25 August 2026. Scheduling owner Ben creates booking B-219 for that slot with one idempotency key. A calendar-write timeout leaves an uncertain result, so confirmation is suppressed; Ben reconciles TC-4, finds the single booking, and then sends the verified date, time, timezone, and owner. A later cancellation invalidates both reminder jobs. Operations records cancelled; the run ends without duplicate meetings or stale messages.

Phase 1: qualify the booking job

• Owner: intake owner.
• Inputs: request, identity, permission, appointment catalog.
• Actions: confirm type, participants, location/channel, minimum constraints, and exclusions.
• Output: eligible request or visible alternative.
• Exit gate: type and accountable meeting owner are known.
• Escalation/rollback: sensitive, urgent, unsuitable, or unsupported requests route to a person; no slot is offered.

Phase 2: offer verified choices

• Owner: scheduling owner.
• Inputs: eligible request and live scheduling source.
• Actions: read duration, buffer, location, host, timezone, and current availability; offer a small set without claiming a hold unless one exists.
• Output: versioned slot choices.
• Exit gate: choices are current and buyer selects one or exits.
• Escalation/rollback: invalidate stale options after source change; offer a human callback when availability is unavailable.

Phase 3: confirm atomically

• Owner: scheduling owner.
• Inputs: chosen slot, request identity, idempotency key.
• Actions: recheck the slot, create exactly one booking, store ID/version, then return exact date, time, offset, owner, location, and change routes.
• Output: confirmed booking or failed write with no confirmation.
• Exit gate: source and customer record agree on one booking ID.
• Escalation/rollback: on partial write, suppress confirmation, reconcile by idempotency key, remove duplicates, and alert operations.

Zalo OA documents a vendor booking utility spanning intake, confirmation, management, and reminders. It illustrates a workflow, not an Easy AI integration or attendance result. Review the source.

Phase 4: maintain one current state

• Owner: operations; meeting owner handles buyer exceptions.
• Inputs: booking version, reminder queue, delivery and change events.
• Actions: invalidate old reminders on change; reconcile before send; route delivery failure and unsupported requests.
• Output: current communication state and accepted exception.
• Exit gate: no obsolete reminder remains and any failure has an owner.
• Escalation/rollback: pause messages on version mismatch; cancel queued copies and resend only from verified state.

Phase 5: reconcile the outcome

• Owner: meeting owner; operations records evidence.
• Inputs: booking source, attendance/meeting record, changes and exceptions.
• Actions: classify changed, cancelled, completed, or unknown; resolve conflicts; close tasks.
• Output: reconciled outcome and review record.
• Exit gate: disagreement is resolved or explicitly unknown, with no queued task.
• Escalation/rollback: operations preserves source events and routes unresolved conflicts to the scheduling owner.

Use this booking handoff card

Trigger	Severity	Owner	Required context
Partial/duplicate write	High	Scheduling owner	Idempotency key, event IDs, source state
Delivery failure	Medium	Operations	Booking version, channel receipt
Unsupported commitment	High	Meeting owner	Original request and appointment type
Owner timeout	Medium	Operations lead	Handoff packet and backup

Trigger	Respond by	If unresolved
Partial/duplicate write	Before confirmation	Suppress and reconcile
Delivery failure	Before next reminder	Alert meeting owner
Unsupported commitment	Before booking	Human callback
Owner timeout	Team target	Reassign backup

QA checks: eligible type; current slot; explicit timezone; one ID; atomic-write recovery tested; old reminders cancelled; failure accepted; final outcome reconciled.

Metric	Definition	Baseline	Decision threshold
Valid booking rate	Bookings with one verified source ID and complete facts / booking attempts	Pilot	Set before expansion
Change integrity	Changes with all obsolete messages cancelled / booking changes	Pilot	Pause threshold pre-set
Reconciled outcome rate	Appointments with verified final state / appointments due for reconciliation	Pre-pilot audit	Set before launch

Metric	Review owner	Cadence
Valid booking rate	Scheduling owner	Weekly
Change integrity	Operations	Weekly
Reconciled outcome rate	Meeting owner	Weekly

Failure signals include conflicts, duplicates, version mismatches, unaccepted exceptions, stale reminders, and rising unknown outcomes. Pause the affected route, reconcile source state, and retest recovery before resuming.

What to do after completion

Use the appointment-booking use case for prioritization, implement communication with the appointment reminder template, or connect retention through the beauty/spa industry playbook where relevant.

Evidence and limitations

No availability, attendance uplift, legal or medical suitability, integration, or Easy AI capability is claimed.