Offer Booking and Reconcile Changes

What you will complete

A booking-state map and test adapter for one appointment type.

Make the operating decision

Define which reviewed leads may receive an appointment option, which appointment type applies, required duration and owner, service-area rule, availability source, and pre-appointment information. If eligibility or availability is uncertain, create a callback rather than inventing a slot.

Use a stable booking or event key and preserve provider identifiers and timestamps. Distinguish offered, requested, scheduled, rescheduled, cancelled, completed, no-show, failed, and unknown. A retry should return the existing booking when the logical request already succeeded. Lost acknowledgements require state reconciliation before another write.

Update lead state only after the scheduler result is verified. Cancellation can create a human-owned rebook path; no-show status needs an observed rule rather than a guess. Provider APIs, webhooks, calendar sync, and entitlements change, so the course uses a fixture adapter and requires current official verification before implementation.

Worked fictional example: Harbourlight Roofing

Harbourlight offers one fictional inspection type after human review. A successful fixture returns a booking ID and confirmed time. A duplicate request returns the existing record. Cancellation creates a rebook task; a scheduler timeout leaves booking status unknown until reconciled.

Harbourlight Roofing, its staff, customers, enquiries, service rules, and results are fictional. The course does not claim a live deployment, faster response, more bookings, or revenue improvement.

Complete workbook section 5

Use the evidence available for your own bounded job. Write unknown when the evidence is missing, and record the person or action that can resolve it.

1. Define booking eligibility and required scheduler fields.
2. Map every booking lifecycle state.
3. Choose logical request and provider identifiers.
4. Write reconciliation and rebook rules.

Open the course workbook PDF or read the workbook details.

Critical gate before continuing

• A link click is not reported as a booking.
• Duplicate requests do not create duplicate appointments.
• Unknown scheduler outcomes remain unknown.
• Cancellation and no-show paths have owners.

If a gate fails, repair the current section, narrow the scope, leave the route manual, or record a blocked or stop decision. Continuing is not the only successful learner action.

Common failure modes

• Expanding beyond a booking-state map and test adapter for one appointment type. before the current artifact can be graded.
• Turning a missing value, unavailable source, or blocked integration into a confident conclusion.
• Treating a prompt instruction as proof that the effective tool or permission boundary works.
• Marking a manual, simulated, or untested route as live.

Check your application