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

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.

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

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

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.