Skip to content

Work · Audit & diagnostic · Aesthetics clinic · via agency

Live launch & fault triage

The build was called done, and nothing had ever been proven

Took a clinic’s already-"finished" lead-response system live for a paid campaign — and found and fixed five faults that had each been silently costing bookings. Validated against real conversations, a real same-day booking and a real cancellation on launch day, not a simulation.

  • GoHighLevel
  • Conversation AI
  • SMS
  • Email
  • Role · sole designer & builder
  • 6 min
silent faults found & fixed before launch
5Scope
workflows live, verified against the account
17Scope
12-day chase built for silent leads
9 msgScope
System size
System flow · 9 stages · 45 components reconstructed from the build record

The situation

An aesthetics clinic had an automation build behind it, delivered through an agency and marked finished. Seventeen workflows, an AI receptionist, a booking calendar and a landing page sat in the account. Nobody had watched a lead travel through it.

The workflows looked correct in the builder and saved cleanly. Whether they did anything at runtime was a different question nobody had asked.

I went in to verify the system before it could meet a patient. Its only designed acquisition trigger read INACTIVE, because no ad account was connected, so everything downstream was exercised by drive-testing the live account with real conversations and real runtime logs.

What was broken

  • Every native wait in the intake and booking-started ladders carried a send window, and the platform honours one by holding rather than skipping. A message due at 23:40 waited until 09:00, and because the run halts at the gate, the stage write that would make the lead visible never happened either.
  • The account had no pipeline cards at all, and every workflow opened by looking for one. A lead could book an appointment and receive no confirmation, no reminder, no alert and no card.
  • A cancelled patient sat under a booked label permanently: no No Show stage, no cancelled stage, and often no card to move.
  • The AI receptionist could only send a booking link, and three stacked sleep settings meant a patient who had just booked got no reply for a day.
  • Two of the seventeen workflows failed to publish. An add-to-workflow step pointing at an unpublished workflow skips with invalid data, breaking outcome re-anchoring on every reschedule.

Constraints

  • The build was inherited, so workflows had to be corrected in place. Four workflows hold removal references to the intake workflow's live id, and rebuilding it mints a new id and breaks all four.
  • Six named workflows can never be rebuilt from the platform's intermediate representation, which cannot express a reply-wait node: the edit path compiles it linearly, discards both branches and returns success.
  • Patient-facing channels are WhatsApp and email. SMS exists here only for internal staff alerts.
  • Domain attachment sat with the build owner, so the sending work stopped at what could be read-only verified.
  • The AI's capabilities are set at the action rather than in its instructions, limiting what a prompt can prevent.

FIG 01 · System Flow

How the system actually runs

Every component below is reconstructed from the project’s own build records. Nothing is added to make it look bigger.

components
45
components
stages
9
stages
decisions & guards
14
decisions & guards
AI
2
AI
human handoffs
3
human handoffs
platforms
5
platforms
  1. Stage 1, Lead entry: Every surface a patient can arrive through — including the one that was not switched on yet.
    1. Ad instant lead form (Source, Paid social). The approved acquisition surface — a higher-intent instant form capturing name, mobile and email, and the intake workflow’s only designed trigger. Connects to Lead intake + chase when form submitted.
    2. Landing page + worker (Source, Web + Cloudflare Workers). A no-index page whose hero is a live calendar widget, served by an edge worker that reads real free slots and creates the appointment on submit, upserting the contact. Connects to Booked + reminders when appointment created by the worker; Web chat widget when visitor opens chat.
    3. Web chat widget (Source, Web). Attached at funnel level with the pre-chat contact form forced on, so a contact record exists before the agent’s field writes can run. Connects to AI receptionist when contact form captured first; Reply to engaged when reply trigger fires on chat too.
    4. Other entry points (Source, CRM). A page name-and-email form on the booking-started workflow, a missed inbound call guarded by a cooldown tag, and an unfiltered reply trigger on any channel. Connects to Reply to engaged when any inbound reply, no filters; Booking started + relay when page name + email capture.
  2. Stage 2, Instant reply: The card, the staff alert, the first two messages, and the wait gate that swallowed them.
    1. Lead intake + chase (Workflow, CRM). Mints the pipeline card, stamps the campaign tag on new cards only, copies the agent’s staged treatment interest onto the card, raises the new-lead alert, sends the first two messages, writes the stage, then runs the ladder to a terminal exhausted tag. Connects to One-card-per-cycle guard when first step, always.
    2. One-card-per-cycle guard (Guard, CRM). Every workflow opens by finding the card filtered on pipeline only, sorted latest, never stage-filtered, then branches found/not-found and again on the current stage. Connects to 13-stage pipeline when create at New Lead, or no-op per the stage table; One-card-per-cycle guard when Lost → new card, cycle index incremented; New-lead staff alert when raised before the gate.
    3. 13-stage pipeline (CRM record, CRM). The board every workflow writes to, from New Lead through booking, reminders, no-show, cancellation and treatment to a follow-up tail, with forward-only stage writes unless a backward move is deliberately flagged.
    4. New-lead staff alert (Staff alert, CRM). An internal notification carrying name, phone, email and treatment interest, plus an audit note written onto the contact record. Connects to 09:00–19:00 send window when before every patient-facing send.
    5. 09:00–19:00 send window (Wait, CRM). A window carried on every native wait step in the intake and booking-started ladders — a property of the wait action rather than an account toggle. Connects to Instant WhatsApp + email when inside the window; 09:00–19:00 send window when outside → holds until 09:00, nothing downstream runs.
    6. Instant WhatsApp + email (Message, WhatsApp + email). At T+0 a WhatsApp acknowledging the enquiry and asserting there is consultation availability, and an email carrying the same in writing with a fixed compliance footer. Connects to 13-stage pipeline when stage write, sited after the gate; 10 touches, 21 days when no reply.
  3. Stage 3, Silent-lead chase: A deliberately back-loaded ladder where each message answers a different hesitation.
    1. 10 touches, 21 days (Message, WhatsApp + email). Ten deliberately back-loaded touches — six WhatsApp, four email — each answering a distinct hesitation rather than repeating the nudge. Connects to Exits and interlocks when reply, booking, or opt-out.
    2. Copy standard (Guard, Design rule). A written rule set every message is held to: one easy question per message, a first-name merge field with a default value, permission-lowering language, anti-sell framing, a takeaway close, and the opt-out line only on the terminal message. Connects to 10 touches, 21 days when one question, one hesitation each.
    3. Exits and interlocks (Decision, CRM). Stop-on-response halts the ladder on any inbound; the reply, booking-started and booked workflows each remove the contact; a do-not-disturb guard sits at every send. Connects to Reply to engaged when reply on any channel; Review, decay, tail when exhausted → decay watch; Booked + reminders when booked directly, no reply.
  4. Stage 4, Reply handling: The silent workflow that moves the card, mints one if missing, and wakes the agent.
    1. Reply to engaged (Workflow, CRM). Sixteen steps and no waits at all: find the card, branch on whether this is the first reply, write the replied then qualified stages, clear any stale exhausted tag, raise the reply alert, remove the contact from the ladder. Connects to Find-or-create the card when no card found; Lead intake + chase when removes the running ladder; 13-stage pipeline when replied → qualified, forward-only; Push, email, SMS, note when reply alert; the patient is told nothing; AI receptionist when wakes the agent to answer; Reply-then-quiet track when ownership transfers.
    2. Find-or-create the card (Data store, CRM). A create-card step on the not-found branch, added to the entry-point workflows only — the reply workflow at New Lead and the booked workflow at Appointment Booked. Connects to 13-stage pipeline when card created at New Lead.
    3. Reply-then-quiet track (Wait, CRM + AI). After a reply, nothing automated chases again inside the intake ladder — ownership transfers to the agent under its message cap, and the later net is the decay watch. Connects to Review, decay, tail when decay watch is the only later net.
    4. Booking started + relay (Workflow, CRM). A relay workflow reads the agent’s booking-intent field and writes the availability-shown tag; that tag triggers a short friction-removing chase at +2h, +1 day and +3 days for a patient shown times who did not book.
  5. Stage 5, AI receptionist: Real calendar actions, the rules that bind them, and the settings that silenced them.
    1. AI receptionist (AI, CRM Conversation AI). An auto-pilot agent with a short pause before replying and a twelve-message auto-pilot cap, whose job is to help patients understand the treatment and book a complimentary consultation. Connects to Prompt hard rules when every reply; Five agent actions; Tag-as-contract escalation when medical, distress, complaint.
    2. Knowledge base (Data store, CRM). One knowledge base on an always-retrieve trigger covering opening hours, location, treatment areas, session count and spacing, practitioner, pricing, payment plans, aftercare and reschedule notice. Connects to AI receptionist when answers only from here.
    3. Prompt hard rules (Guard, AI prompt). Never state whether a patient is suitable, never promise a result or a timeframe, never quote a price outside the knowledge base, never name the software — and hand over without delay on any medical condition, medication, allergy, pregnancy, post-treatment symptom, distress or complaint.
    4. Five agent actions (AI, CRM). Capture treatment interest into a staging contact field a workflow copies onto the card; the booking action; capture booking intent as a literal picklist value the relay watches; capture a conversation summary before every handover; and human handover. Connects to Real calendar actions when booking action, all three capabilities; Booking started + relay when writes the booking-intent field.
    5. Real calendar actions (Calendar, CRM). The upgrade from link-sending is one flag — send-link-only set false — turning the agent into a live booker with reschedule and cancel enabled on the same action. Connects to Three stacked sleep settings when booking triggers the stacked settings; Booked + reminders when appointment confirmed.
    6. Flag beats prompt (Guard, Design rule). A capability flag overrides instruction text: with cancelling enabled the agent genuinely cancels appointments no matter what its prompt says. Connects to Real calendar actions when capability decided at the action.
    7. Three stacked sleep settings (Guard, CRM). A patient who booked got no reply for the next 24 hours, so they could not reschedule, cancel or ask anything — caused by three separate sleep settings that stack. Connects to AI receptionist when all three changed together, re-verified.
    8. Tag-as-contract escalation (Staff alert, CRM). The handover tag string is the contract, not the agent: the escalation workflow binds to the tag, silences the agent, hands a named human the thread with the agent’s own summary, and removes the contact from every running ladder. Connects to Lead intake + chase when removes every running ladder; Push, email, SMS, note when named human, with the agent’s summary.
  6. Stage 6, Booking & reminders: Confirmation, the day-before ask, and the guard that stops a passed anchor firing everything at once.
    1. Booked + reminders (Workflow, CRM). Triggered on a confirmed appointment: six stage-origin branches each write the booked stage and jump into one shared ladder, with a seventh that writes nothing and exits. Connects to 13-stage pipeline when six stage origins → booked; Exits and interlocks when kill switch: stop every pre-booking chase; Past-anchor guard when immediately after the confirmation; Reschedule handler when appointment moved; Cancellation recovery when appointment cancelled; Outcome chaser + no-show when time-anchored, two hours after the start.
    2. Past-anchor guard (Decision, CRM). Every appointment-anchored wait carries a branch on whether the anchor is already past, because a wait whose moment has passed fires immediately and everything downstream runs at once. Connects to Marketplace reply-wait when both paths converge on the same ask.
    3. Marketplace reply-wait (Wait, CRM marketplace app). The day-before yes/no ask uses a reply-wait node with two fixed branches, responded and timeout; on timeout after six hours an internal alert fires to the shared inbox and by SMS to the owner. Connects to Push, email, SMS, note when timeout leg, no reply after six hours.
    4. Reschedule handler (Workflow, CRM). The platform has no native rescheduled trigger, so the only way to catch one is an appointment trigger with no status filter plus a rescheduled condition — now runtime-proven on this account. Connects to Booked + reminders when releases the old reminder on a reschedule; Outcome chaser + no-show when re-enrols against the new time.
  7. Stage 7, Recovery & tail: No-show, cancellation, the rebook move, and the long tail after the ladder is exhausted.
    1. Cancellation recovery (Workflow, CRM). A stage gate first so a treated card is never dragged backwards, then the alert, the cancelled-stage write, removal from the reminder ladder, and a two-rung win-back with a stage-gated second rung. Connects to Cancelled kept booked label when stage → cancelled; Booked + reminders when removes the reminder ladder; Rebook: guarded backward move when rebook rung, backward move with the flag set.
    2. Cancelled kept booked label (Guard, CRM). Two compounding causes: there was no stage to move a cancelled card to, and for non-campaign leads there was no card at all — so a cancelled patient sat under a booked label permanently. Connects to Find-or-create the card when the stage write needs a card to exist.
    3. Rebook: guarded backward move (CRM record, CRM). There is no stage named Rebook: the rebook rung is the booking rung, reached by a deliberate backward move with the backward flag set and handed to the booking-started chase. Connects to Booking started + relay when hand-off to the friction chase.
    4. Outcome chaser + no-show (Workflow, CRM). A time-anchored chaser waits until two hours after the appointment start, reads the status at that moment and branches three ways; the no-show branch runs a two-message recovery with reply-waits and a needs-disposition tag. Connects to Rebook: guarded backward move when no-show hand-off; Review, decay, tail when showed → review request; 13-stage pipeline when writes completed or no-show.
    5. Review, decay, tail (Workflow, CRM). A review request after a showed outcome, a 14-day decay watch giving a stalled card one re-engagement touch branched per stage bucket, and a tail workflow that closes the file after a set window.
  8. Stage 8, Staff alerting: Who is told, on which channel, from which sending domain — rebuilt from a single-recipient estate.
    1. Push, email, SMS, note (Staff alert, CRM). Alerts are steps inside their owning workflow, never a standalone notification workflow, delivered on three channels — in-app, internal email, internal SMS — plus a note written onto the contact record. Connects to Authenticated sending domain when eight alerts consolidated onto email.
    2. Live alert inventory (Report, CRM (read-only)). A read-only sweep of every notification step across all seventeen workflows, ending at thirteen internal-notification steps — eight email to the shared inbox, three SMS to the owner, two in-app. Connects to Push, email, SMS, note when one recipient, none on booking → new alert built.
    3. Five-phase recipient arc (Guard, CRM). Recipients moved through five phases — a fill token with every alert disabled, then hardcoded to the owner, then a two-recipient spec, then an assigned-user investigation, then everything to one shared inbox. Connects to Push, email, SMS, note when token → owner → two → assign → shared inbox.
    4. Authenticated sending domain (Guard, Email). Before, no email service was configured on the location at all and every email step carried sender fields resolving to nothing — so the first email had been set to send from a blank address. Connects to Live alert inventory when warmup throttling would silence staff, with no telemetry.
  9. Stage 9, Launch verification: Drive-testing a published system to find writes that return success and do nothing.
    1. Scripted drive tests (Report, Live account). Two scripted live conversations against the live widget with storage cleared between them — a full appointment lifecycle, and an escalation probe on a medication-safety question — run alongside per-workflow runtime logs. Connects to Handover applied no tag when escalation left no tag; Live KB was unfilled when opening-hours probe deflected; Field write never landed when availability tag never appeared; No cards anywhere when find-card dead-ends everywhere; Three stacked sleep settings when silent after booking; Real calendar actions when book, reschedule and cancel all proven.
    2. No cards anywhere (Guard, CRM). A chat lead booked an appointment and got an appointment and nothing else — no confirmation, no reminders, no alert, no pipeline card. There were zero opportunities in the entire account. Connects to Find-or-create the card when find-or-create, entry points only; The recurring signature when a write that succeeds and does nothing.
    3. Handover applied no tag (Guard, CRM). A live conversation escalated a clinical question and the contact’s tags stayed empty from creation through a poll fifteen minutes later. Connects to Tag-as-contract escalation when rewired to write the tag.
    4. Live KB was unfilled (Guard, CRM). Asked where the clinic is and what its opening hours are, the agent gave a partial answer and offered to confirm later — correct behaviour on a bad input, not a retrieval failure. Connects to Knowledge base when real values loaded live.
    5. Field write never landed (Guard, CRM). The availability-shown tag never appeared, so the booking-started chase never triggered and nobody shown times who did not book was ever chased. Connects to Booking started + relay when literal picklist value specified; The recurring signature when out-of-enum value, no error surfaced.
    6. The recurring signature (Report, Delivery practice). A write that returns success, reads back clean, and does nothing — an out-of-enum value, a wrong-typed field, an unaddressed recipient, a discarded branch, an inferred trigger operator that renders empty. Connects to Live pre-launch audit when ordered by what hurts a patient first.
    7. Live pre-launch audit (Report, Deliverable). A short, sharp document separate from the build checklist: what is actually unsafe or unclean on the account right now, verified live, ordered by what hurts a patient first. Connects to Ad instant lead form when nothing is switched on until the audit clears.
0/14

A patient fills in the ad form just before midnight, asking about a treatment she has been reading about for weeks.

Read this system as text

  1. Stage 01

    Lead entry

    Every surface a patient can arrive through — including the one that was not switched on yet.

    • Ad instant lead form · Source · Paid social — The approved acquisition surface — a higher-intent instant form capturing name, mobile and email, and the intake workflow’s only designed trigger. → Lead intake + chase (form submitted)
    • Landing page + worker · Source · Web + Cloudflare Workers — A no-index page whose hero is a live calendar widget, served by an edge worker that reads real free slots and creates the appointment on submit, upserting the contact. → Booked + reminders (appointment created by the worker), Web chat widget (visitor opens chat)
    • Web chat widget · Source · Web — Attached at funnel level with the pre-chat contact form forced on, so a contact record exists before the agent’s field writes can run. → AI receptionist (contact form captured first), Reply to engaged (reply trigger fires on chat too)
    • Other entry points · Source · CRM — A page name-and-email form on the booking-started workflow, a missed inbound call guarded by a cooldown tag, and an unfiltered reply trigger on any channel. → Reply to engaged (any inbound reply, no filters), Booking started + relay (page name + email capture)

  2. Stage 02

    Instant reply

    The card, the staff alert, the first two messages, and the wait gate that swallowed them.

    • Lead intake + chase · Workflow · CRM — Mints the pipeline card, stamps the campaign tag on new cards only, copies the agent’s staged treatment interest onto the card, raises the new-lead alert, sends the first two messages, writes the stage, then runs the ladder to a terminal exhausted tag. → One-card-per-cycle guard (first step, always)
    • One-card-per-cycle guard · Guard · CRM — Every workflow opens by finding the card filtered on pipeline only, sorted latest, never stage-filtered, then branches found/not-found and again on the current stage. → 13-stage pipeline (create at New Lead, or no-op per the stage table), One-card-per-cycle guard (Lost → new card, cycle index incremented), New-lead staff alert (raised before the gate)
    • 13-stage pipeline · CRM record · CRM — The board every workflow writes to, from New Lead through booking, reminders, no-show, cancellation and treatment to a follow-up tail, with forward-only stage writes unless a backward move is deliberately flagged.
    • New-lead staff alert · Staff alert · CRM — An internal notification carrying name, phone, email and treatment interest, plus an audit note written onto the contact record. → 09:00–19:00 send window (before every patient-facing send)
    • 09:00–19:00 send window · Wait · CRM — A window carried on every native wait step in the intake and booking-started ladders — a property of the wait action rather than an account toggle. → Instant WhatsApp + email (inside the window), 09:00–19:00 send window (outside → holds until 09:00, nothing downstream runs)
    • Instant WhatsApp + email · Message · WhatsApp + email — At T+0 a WhatsApp acknowledging the enquiry and asserting there is consultation availability, and an email carrying the same in writing with a fixed compliance footer. → 13-stage pipeline (stage write, sited after the gate), 10 touches, 21 days (no reply)

  3. Stage 03

    Silent-lead chase

    A deliberately back-loaded ladder where each message answers a different hesitation.

    • 10 touches, 21 days · Message · WhatsApp + email — Ten deliberately back-loaded touches — six WhatsApp, four email — each answering a distinct hesitation rather than repeating the nudge. → Exits and interlocks (reply, booking, or opt-out)
    • Copy standard · Guard · Design rule — A written rule set every message is held to: one easy question per message, a first-name merge field with a default value, permission-lowering language, anti-sell framing, a takeaway close, and the opt-out line only on the terminal message. → 10 touches, 21 days (one question, one hesitation each)
    • Exits and interlocks · Decision · CRM — Stop-on-response halts the ladder on any inbound; the reply, booking-started and booked workflows each remove the contact; a do-not-disturb guard sits at every send. → Reply to engaged (reply on any channel), Review, decay, tail (exhausted → decay watch), Booked + reminders (booked directly, no reply)

  4. Stage 04

    Reply handling

    The silent workflow that moves the card, mints one if missing, and wakes the agent.

    • Reply to engaged · Workflow · CRM — Sixteen steps and no waits at all: find the card, branch on whether this is the first reply, write the replied then qualified stages, clear any stale exhausted tag, raise the reply alert, remove the contact from the ladder. → Find-or-create the card (no card found), Lead intake + chase (removes the running ladder), 13-stage pipeline (replied → qualified, forward-only), Push, email, SMS, note (reply alert; the patient is told nothing), AI receptionist (wakes the agent to answer), Reply-then-quiet track (ownership transfers)
    • Find-or-create the card · Data store · CRM — A create-card step on the not-found branch, added to the entry-point workflows only — the reply workflow at New Lead and the booked workflow at Appointment Booked. → 13-stage pipeline (card created at New Lead)
    • Reply-then-quiet track · Wait · CRM + AI — After a reply, nothing automated chases again inside the intake ladder — ownership transfers to the agent under its message cap, and the later net is the decay watch. → Review, decay, tail (decay watch is the only later net)
    • Booking started + relay · Workflow · CRM — A relay workflow reads the agent’s booking-intent field and writes the availability-shown tag; that tag triggers a short friction-removing chase at +2h, +1 day and +3 days for a patient shown times who did not book.

  5. Stage 05

    AI receptionist

    Real calendar actions, the rules that bind them, and the settings that silenced them.

    • AI receptionist · AI · CRM Conversation AI — An auto-pilot agent with a short pause before replying and a twelve-message auto-pilot cap, whose job is to help patients understand the treatment and book a complimentary consultation. → Prompt hard rules (every reply), Five agent actions, Tag-as-contract escalation (medical, distress, complaint)
    • Knowledge base · Data store · CRM — One knowledge base on an always-retrieve trigger covering opening hours, location, treatment areas, session count and spacing, practitioner, pricing, payment plans, aftercare and reschedule notice. → AI receptionist (answers only from here)
    • Prompt hard rules · Guard · AI prompt — Never state whether a patient is suitable, never promise a result or a timeframe, never quote a price outside the knowledge base, never name the software — and hand over without delay on any medical condition, medication, allergy, pregnancy, post-treatment symptom, distress or complaint.
    • Five agent actions · AI · CRM — Capture treatment interest into a staging contact field a workflow copies onto the card; the booking action; capture booking intent as a literal picklist value the relay watches; capture a conversation summary before every handover; and human handover. → Real calendar actions (booking action, all three capabilities), Booking started + relay (writes the booking-intent field)
    • Real calendar actions · Calendar · CRM — The upgrade from link-sending is one flag — send-link-only set false — turning the agent into a live booker with reschedule and cancel enabled on the same action. → Three stacked sleep settings (booking triggers the stacked settings), Booked + reminders (appointment confirmed)
    • Flag beats prompt · Guard · Design rule — A capability flag overrides instruction text: with cancelling enabled the agent genuinely cancels appointments no matter what its prompt says. → Real calendar actions (capability decided at the action)
    • Three stacked sleep settings · Guard · CRM — A patient who booked got no reply for the next 24 hours, so they could not reschedule, cancel or ask anything — caused by three separate sleep settings that stack. → AI receptionist (all three changed together, re-verified)
    • Tag-as-contract escalation · Staff alert · CRM — The handover tag string is the contract, not the agent: the escalation workflow binds to the tag, silences the agent, hands a named human the thread with the agent’s own summary, and removes the contact from every running ladder. → Lead intake + chase (removes every running ladder), Push, email, SMS, note (named human, with the agent’s summary)

  6. Stage 06

    Booking & reminders

    Confirmation, the day-before ask, and the guard that stops a passed anchor firing everything at once.

    • Booked + reminders · Workflow · CRM — Triggered on a confirmed appointment: six stage-origin branches each write the booked stage and jump into one shared ladder, with a seventh that writes nothing and exits. → 13-stage pipeline (six stage origins → booked), Exits and interlocks (kill switch: stop every pre-booking chase), Past-anchor guard (immediately after the confirmation), Reschedule handler (appointment moved), Cancellation recovery (appointment cancelled), Outcome chaser + no-show (time-anchored, two hours after the start)
    • Past-anchor guard · Decision · CRM — Every appointment-anchored wait carries a branch on whether the anchor is already past, because a wait whose moment has passed fires immediately and everything downstream runs at once. → Marketplace reply-wait (both paths converge on the same ask)
    • Marketplace reply-wait · Wait · CRM marketplace app — The day-before yes/no ask uses a reply-wait node with two fixed branches, responded and timeout; on timeout after six hours an internal alert fires to the shared inbox and by SMS to the owner. → Push, email, SMS, note (timeout leg, no reply after six hours)
    • Reschedule handler · Workflow · CRM — The platform has no native rescheduled trigger, so the only way to catch one is an appointment trigger with no status filter plus a rescheduled condition — now runtime-proven on this account. → Booked + reminders (releases the old reminder on a reschedule), Outcome chaser + no-show (re-enrols against the new time)

  7. Stage 07

    Recovery & tail

    No-show, cancellation, the rebook move, and the long tail after the ladder is exhausted.

    • Cancellation recovery · Workflow · CRM — A stage gate first so a treated card is never dragged backwards, then the alert, the cancelled-stage write, removal from the reminder ladder, and a two-rung win-back with a stage-gated second rung. → Cancelled kept booked label (stage → cancelled), Booked + reminders (removes the reminder ladder), Rebook: guarded backward move (rebook rung, backward move with the flag set)
    • Cancelled kept booked label · Guard · CRM — Two compounding causes: there was no stage to move a cancelled card to, and for non-campaign leads there was no card at all — so a cancelled patient sat under a booked label permanently. → Find-or-create the card (the stage write needs a card to exist)
    • Rebook: guarded backward move · CRM record · CRM — There is no stage named Rebook: the rebook rung is the booking rung, reached by a deliberate backward move with the backward flag set and handed to the booking-started chase. → Booking started + relay (hand-off to the friction chase)
    • Outcome chaser + no-show · Workflow · CRM — A time-anchored chaser waits until two hours after the appointment start, reads the status at that moment and branches three ways; the no-show branch runs a two-message recovery with reply-waits and a needs-disposition tag. → Rebook: guarded backward move (no-show hand-off), Review, decay, tail (showed → review request), 13-stage pipeline (writes completed or no-show)
    • Review, decay, tail · Workflow · CRM — A review request after a showed outcome, a 14-day decay watch giving a stalled card one re-engagement touch branched per stage bucket, and a tail workflow that closes the file after a set window.

  8. Stage 08

    Staff alerting

    Who is told, on which channel, from which sending domain — rebuilt from a single-recipient estate.

    • Push, email, SMS, note · Staff alert · CRM — Alerts are steps inside their owning workflow, never a standalone notification workflow, delivered on three channels — in-app, internal email, internal SMS — plus a note written onto the contact record. → Authenticated sending domain (eight alerts consolidated onto email)
    • Live alert inventory · Report · CRM (read-only) — A read-only sweep of every notification step across all seventeen workflows, ending at thirteen internal-notification steps — eight email to the shared inbox, three SMS to the owner, two in-app. → Push, email, SMS, note (one recipient, none on booking → new alert built)
    • Five-phase recipient arc · Guard · CRM — Recipients moved through five phases — a fill token with every alert disabled, then hardcoded to the owner, then a two-recipient spec, then an assigned-user investigation, then everything to one shared inbox. → Push, email, SMS, note (token → owner → two → assign → shared inbox)
    • Authenticated sending domain · Guard · Email — Before, no email service was configured on the location at all and every email step carried sender fields resolving to nothing — so the first email had been set to send from a blank address. → Live alert inventory (warmup throttling would silence staff, with no telemetry)

  9. Stage 09

    Launch verification

    Drive-testing a published system to find writes that return success and do nothing.

    • Scripted drive tests · Report · Live account — Two scripted live conversations against the live widget with storage cleared between them — a full appointment lifecycle, and an escalation probe on a medication-safety question — run alongside per-workflow runtime logs. → Handover applied no tag (escalation left no tag), Live KB was unfilled (opening-hours probe deflected), Field write never landed (availability tag never appeared), No cards anywhere (find-card dead-ends everywhere), Three stacked sleep settings (silent after booking), Real calendar actions (book, reschedule and cancel all proven)
    • No cards anywhere · Guard · CRM — A chat lead booked an appointment and got an appointment and nothing else — no confirmation, no reminders, no alert, no pipeline card. There were zero opportunities in the entire account. → Find-or-create the card (find-or-create, entry points only), The recurring signature (a write that succeeds and does nothing)
    • Handover applied no tag · Guard · CRM — A live conversation escalated a clinical question and the contact’s tags stayed empty from creation through a poll fifteen minutes later. → Tag-as-contract escalation (rewired to write the tag)
    • Live KB was unfilled · Guard · CRM — Asked where the clinic is and what its opening hours are, the agent gave a partial answer and offered to confirm later — correct behaviour on a bad input, not a retrieval failure. → Knowledge base (real values loaded live)
    • Field write never landed · Guard · CRM — The availability-shown tag never appeared, so the booking-started chase never triggered and nobody shown times who did not book was ever chased. → Booking started + relay (literal picklist value specified), The recurring signature (out-of-enum value, no error surfaced)
    • The recurring signature · Report · Delivery practice — A write that returns success, reads back clean, and does nothing — an out-of-enum value, a wrong-typed field, an unaddressed recipient, a discarded branch, an inferred trigger operator that renders empty. → Live pre-launch audit (ordered by what hurts a patient first)
    • Live pre-launch audit · Report · Deliverable — A short, sharp document separate from the build checklist: what is actually unsafe or unclean on the account right now, verified live, ordered by what hurts a patient first. → Ad instant lead form (nothing is switched on until the audit clears)

Platforms · GoHighLevel · Conversation AI · WhatsApp · Email · Cloudflare Workers

What I found and fixed

The window that held instead of skipping

The window existed for a real reason: live sends had been observed across the estate at 23:22, 02:55 and 03:20. The error was applying it uniformly without carving out the first-contact message. I removed the pre-first-message hold from the intake workflow, so an out-of-hours enquiry now gets its WhatsApp and email on arrival. The cost went into the record in the same breath: a 3am enquiry now gets a 3am WhatsApp, contradicting the registry's own quiet-hours rule, with an action to reconcile the two. At the last capture every other wait in both ladders still carried the window.

Cards, and the finder that could not find them

Every workflow now opens by finding the card filtered on pipeline only, sorted latest, never stage-filtered, then branching found or not-found. A stage-filtered finder returns Not Found for a card at any other stage and the workflow falls through silently. A create step sits on the not-found branch of the entry-point workflows only, deliberately not everywhere, because the platform has no locking and three workflows enrol within two seconds of one booking. Two stages were added to the board.

A back-loaded chase instead of a burst

The audit complaint was clustering, not volume: two dozen messages front-loaded, then nothing. The replacement is ten back-loaded touches over 21 days, six WhatsApp and four email, each answering a distinct hesitation rather than repeating the nudge. Every message ends in one easy question, because the goal is a reply and the agent owns everything after the answer.

An AI front desk that acts

One flag turned the agent from a link dispenser into a live booker with reschedule and cancel on the same action. Drive-tested on one contact, it booked, rescheduled, confirmed back to the patient and then cancelled, at eight to twenty seconds per turn. The three stacked sleep settings were turned off together and re-verified, while the general timer and sleep-on-manual-message were kept, because when a human replies the bot should stand down.

Alerting and sending

Alerts were rebuilt from a single-recipient estate onto four channels: in-app push, internal email, internal SMS, and an audit note on the contact. The new-lead alert sits before the wait gate, because an internal notification is never window-gated. Per-step sender fields were removed so emails inherit the account header from a clinic-branded subdomain of the agency's domain, behind a warmup gate and a send test.

The faults, one by one

  • A capability flag overrides instruction text. With cancelling enabled the agent cancelled an appointment its own instructions told it to escalate. It did ask first in that run, but that was model improvisation rather than configuration, so the corrected policy turns the capability off at the action instead of trusting the prompt.
  • Fixing one of three stacked sleep settings only relocates the silence, since the booking confirmation itself puts the agent to sleep. That was written down before the fix, so nobody would conclude it had failed.
  • An appointment-anchored wait whose moment has passed fires immediately and runs everything downstream at once. A past-anchor branch sits above every such wait, and the two paths converge on one ask.
  • The same-day case is a residual, not a fix. Relative-date conditions bottom out at days, so a booking made for today also takes the run-it-now branch, and a minimum scheduling notice blocks that through the widget but not through the API, staff, or a reschedule.
  • A respelt handover tag disconnects escalation silently and nothing errors, so the tag string is the contract. A backward stage write silently no-ops unless the backward flag is set, which is why the rebook rung is a deliberately flagged move.

How I verified it

Nothing was accepted from the builder view. The fault class this pass exists to catch is a write that returns 200, reads back clean, and does nothing.

The cancellation path was proven end to end in a five-second runtime log: confirmation tag removed, card found, cancelled stage written, alert fired, audit note written. The booked workflow self-cleaned on the same event, so a cancelled patient will not receive the day-before reminder. The reschedule handler, which the platform gives no native trigger for, is now runtime-proven. The intake workflow was read back after its patch at 45 steps with zero dangling edges.

Roughly thirty distinct faults are documented, at least half silent at write or run time. The pre-launch audit carries a section headed unproven, do not claim these work, and a footer stating that every item was read from the account rather than a design document.

What changed

An out-of-hours enquiry to the intake ladder is answered on arrival rather than held until 09:00. A cancellation moves the card to a real stage, clears the confirmation tag, alerts the clinic and hands the patient back to follow-up. Silent leads meet ten touches over 21 days instead of one message and one email. The AI front desk books, reschedules and cancels against the live calendar, proven in drive tests rather than inferred from configuration.

Seventeen workflows were inventoried and verified against the account, and what remained unproven was published as unproven. The owner holds a sign-off pack whose footer says what is still in draft and that no message has reached a patient.

Before / after

  • Before
  • ✕ An 11pm lead got no text, no email, no alert — record never moved
  • ✕ Cancelled leads kept a "booked" label forever, excluded from follow-up
  • ✕ Non-repliers: one text, one email, then silence
  • ✕ A reminder texting "your consultation is tomorrow" seconds after a same-day booking
  • After
  • ✓ Overnight enquiries answered on arrival
  • ✓ Cancellations return to follow-up via a rebook stage — proven live in 90 seconds
  • ✓ Nine messages over twelve days for the silent, each answering a different hesitation
  • ✓ AI books, reschedules and cancels against the real calendar

ScopeFigures on this page describe what was built, covered or verified — not a measured lift.

Related systems

Have something close to this? Book a call. I’ll tell you if I’ve already built it.

One Manila business day to reply. All client work is under NDA; what you see here is redrawn architecture with real metrics.

Book