CS-12 // Dossier
Deposit-gated booking architecture
Rebuilt a clinic’s booking model so a slot is reserved on booking but only ever marked confirmed once the deposit is paid — spanning a Cloudflare booking worker, the CRM calendar, and four workflows that had all been using "confirmed" to mean different things.
Exhibit // CS-12
R-02 · interface redrawn from the live build — zero client pixels
- Client
- R-01SEALED UNDER NDA. SPECIFICS WALK THROUGH LIVE. → BOOK
- Industry
- Aesthetics clinic · single-treatment programme, via agency
- System
- Deposit-gated booking architecture
- Stack
- GoHighLevel · Cloudflare Workers · Conversation AI · Stripe
- Trigger
- A diary full of confirmed bookings nobody had paid for
- Metrics
- System scope
01 // The problem
A patient booking through the landing page appeared in the diary as Confirmed with no deposit paid. The cause was three faults, not one: the booking worker wrote confirmed on create, the calendar auto-confirmed every arriving booking, and four workflows keyed their triggers on confirmed as a proxy for "a booking exists".
02 // The system
Redrawn — no client data
The system
03 // The delta
Before and after go-live
Before
- Diary showed Confirmed with no deposit paid
- Three systems used "confirmed" to mean three different things
- Releasing a held slot dropped patients into cancellation copy
- No staff alert when a deposit actually landed
With the system
- A slot holds unconfirmed for 24 hours; confirmed means paid
- One state model across worker, calendar and workflows
- Unpaid holds delete cleanly — no misfired recovery copy
- Deposit-paid raises the alert it never had
04 // What got done
6 entries
- B-01Redefined the states: a slot is written the instant the patient books but as unconfirmed; confirmed thereafter means only that the deposit is paid, with a 24-hour hold
- B-02Added two keyed, idempotent endpoints to the booking worker — one that marks the slot paid and confirmed, one that frees an unpaid hold — and wired them into the deposit workflows
- B-03Repointed four workflow triggers in one cutover, leaving nothing keyed on the confirmed state that could re-enrol a patient
- B-04Made the unpaid release delete rather than cancel, so freeing a held slot can never fire cancellation-recovery copy at someone who didn’t cancel
- B-05Recompressed the deposit chase from four touches over 72 hours to five over 24, re-measuring every SMS against the single-segment limit
- B-06Audited the account’s alerting, found the deposit-paid rail had no staff alert at all, and built one
05 // Outcome
System scope — capability metrics, honestly labeled
- → Scope
independent causes behind one phantom confirmation - 0
- → Scope
workflows scanned in one live inventory pass - 0
- → Scope
touches in the rebuilt 24-hour deposit chase - 0
06 // The result
From the build log
- Reservation, repeat-confirm no-op, and paid-release refusal all proven live — not inferred
- The owner handbook shipped as a self-contained page plus a 16-page PDF, screenshots PII-blurred before capture
- The deposit-paid rail got the staff alert it never had
Want a system like this one?
Free · 30 min · leave with a rough scope either way