Skip to content

Work · Reactivation / win-back · Local service business with a cold lead list

Dead-Lead Reactivation Engine

Hundreds of old leads sitting dead in the CRM, never worked

A 30-day reactivation system that works a cold lead list automatically — 15 sequenced touches, AI intent detection, and hot replies handed straight to the booking bot — then cleanly sunsets the rest.

  • GoHighLevel
  • Conversation AI
  • SMS
  • Email
  • Role · sole designer & builder
  • 6 min
of list worked automatically
100%Scope
over 30 days
15 touchesScope
cross-campaign collisions
0Scope
System size
System flow · 8 stages · 35 components reconstructed from the build record

The situation

A local service business had hundreds of old leads sitting in its CRM. They had enquired once, gone quiet, and never been worked again. Everyone agreed some were still buyers.

Reactivation was on the list every month and never happened. Working a cold list by hand is slow, unrewarding, and the first thing dropped when live leads come in. So the list aged.

There was a real reason for the hesitation too. The business had live pipelines running in the same account, and nobody could say that re-messaging an old lead would not fire the workflows behind them.

What was broken

  • Hundreds of old, unworked leads sat dead in the CRM, with no process pointed at them.
  • Manual reactivation was planned repeatedly and never executed.
  • There was no safe way to re-message the old list without colliding with the live pipelines.
  • A lead who replied with real interest had nowhere to go except a person noticing in time.
  • Non-responders had no defined end state, so the list would have been abandoned again.

Constraints

  • Dead leads often do not remember opting in, and carriers flag cold-contact messages far more aggressively. A registered number, an approved carrier registration and a delivered test message are all required before launch.
  • A standing client rule bans tag triggers for downstream automation, so stage moves are the only triggers on this account.
  • The campaign shares its account with other live pipelines, an existing confirmation stack, and an inbound auto-responder.
  • Everything is built and saved as draft. Written client sign-off on the copy, the offer, the cleaned list count, the send window and the pipeline rules is what turns it on.

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
35
components
stages
8
stages
decisions & guards
11
decisions & guards
AI
2
AI
human handoffs
3
human handoffs
platforms
4
platforms
  1. Stage 1, List preparation: Define what "dead" means, clean the list, and clear the compliance gate before anything can send.
    1. Dead-lead definition (Human, Delivery process). A written definition agreed with the client before any list is pulled — enquired months ago, never enrolled, never an active member, not opted out, and a valid phone or email on file. Connects to Clean & exclude when definition agreed in writing.
    2. Clean & exclude (Guard, Spreadsheet + CRM). Confirm the source, map headers, normalise every phone to a single international format, validate emails, note the row count before any cleaning — then run the exclusions. Connects to Sender-registration gate when exclusions applied, counts logged.
    3. Sender-registration gate (Guard, Messaging compliance). A hard stop: the campaign may not launch on an unregistered sender. A registered number, an approved carrier registration and a delivered test message are all required first. Connects to CSV import runbook when sender registered, test message delivered; Dead-lead definition when sender unregistered → do not launch.
    4. Staged enrolment (Scheduled job, CRM). Batch sizing by list size — a small list in one batch, a medium one split across two days, a large one staged over several — weekday mornings only, with the first hour of sends monitored for rejections. Connects to CSV import runbook when batch sizing by list size.
  2. Stage 2, Import & enrolment: Bulk-create contacts and cards, stamp the entry source, and place them so the drip fires.
    1. CSV import runbook (Source, CRM). Five required columns and a fixed four-option entry-source value; bulk-import the contacts, bulk-create one card per contact at the entry stage with the source set, then verify in the execution logs that the drip entered for every contact within minutes. Connects to 3-stage campaign pipeline when one card per contact at the entry stage; Import-field helper when entry-source field did not stick.
    2. 3-stage campaign pipeline (CRM record, CRM). A dedicated pipeline with an entry stage, a revived stage written by the reply handler, and a terminal booked stage kept as a permanent win record. Connects to Stage-change entry when card lands at the entry stage.
    3. Stage-change entry (Trigger, CRM). The drip is triggered by a pipeline-stage-changed event into the entry stage, not by a tag. Stage moves are the only triggers used for downstream automation on this account. Connects to The 30-day drip when stage-changed event.
    4. Import-field helper (Workflow, CRM). A fallback for a documented platform inconsistency: bulk add-to-pipeline reliably sets the stage but sets card custom fields inconsistently across platform versions. Connects to Tag taxonomy & fields when writes the source, then self-disables.
    5. Tag taxonomy & fields (Data store, CRM). Eight canonical tags each with a declared owner and lifecycle, plus three card-level fields — entry source set at import, last-contact date stamped by the drip, and an intent timestamp stamped by the reply handler.
  3. Stage 3, 30-day drip: Fifteen paced touches, quiet-hours bounded, with every exit living outside the workflow.
    1. The 30-day drip (Workflow, CRM). Thirty-five steps with re-entry off: apply the active tag, stamp the last-contact date, run the touches, then a buffer carrying the contact to day 30 and an explicit final step that fires the cleanup. Connects to Tag taxonomy & fields when active tag, last-contact date; 15 touches, 30 days when fifteen paced sends; Day-30 cleanup when final step fires the cleanup; Three drip exits when every exit lives outside the workflow.
    2. 15 touches, 30 days (Message, SMS + email). Two named phases. The first week is pure pulse-finding — no calls to action, no offer name, no links. Everything after introduces the trial, one angle at a time. Connects to Quiet hours when every send; Reply handler when the lead replies; Booking exit when self-books via the fallback link; Three drip exits when booking, intent keyword, or opt-out.
    3. Quiet hours (Guard, CRM). A workflow-level daytime window in the contact’s own timezone on both the drip and the reply handler, with a documented fallback to the business timezone — deliberately narrower than the legal floor.
    4. Three drip exits (Decision, CRM). The booking handler removes the contact on any booking; the reply handler removes them on an intent keyword; a texted stop engages native opt-out, so the drip keeps running but produces no messages. Connects to The 30-day drip when booking, intent keyword, or opt-out.
  4. Stage 4, Reply & intent: Detect a reply that reads as interest, pull the lead out of the drip, and hand the thread over.
    1. Reply handler (Workflow, CRM). Triggered by an inbound message on either channel — upgraded from one channel because the concierge answers on both — with three filters that must all match: the campaign pipeline, the entry stage, and a body match. Connects to 15-keyword intent filter when pipeline + entry stage + body match.
    2. 15-keyword intent filter (Decision, CRM). At the workflow boundary this is not a model — it is a flat, case-insensitive contains-any-of list of fifteen keywords. The AI classifies conversationally only after it has been handed the contact. Connects to Pull, move, hand off when body contains an intent keyword; 15 touches, 30 days when no match → stays in the drip.
    3. 8-category intent routing (AI, AI charter). Four categories where the AI takes over — explicit positive keywords, a question about the trial or venue (questions ARE positive intent), ambiguous-but-leaning-positive, and off-topic-but-engaged, which gets exactly one turn to acknowledge and redirect. Connects to AI booking concierge when positive, question, ambiguous, or engaged off-topic; 15 touches, 30 days when soft negative or bare emoji → stay in the drip, tagged; Two terminal states when hard negative → stop compliance, no AI message.
    4. Pull, move, hand off (Workflow, CRM). Six ordered steps and then the workflow ends: remove from the drip FIRST, apply the intent tag, stamp the timestamp, move the existing card to the revived stage, send one human-feeling acknowledgement, and enable the concierge on this contact. Connects to 8-category intent routing when the AI classifies only once it holds the contact; The 30-day drip when step one removes them from the drip first; 3-stage campaign pipeline when existing card moved to revived.
  5. Stage 5, AI booking concierge: Answer from the knowledge base, route by age, book in-thread, and know exactly when to fetch a human.
    1. AI booking concierge (AI, CRM Conversation AI). An auto-pilot agent set as the account’s primary bot — required for inbound email auto-reply at all — on messaging and email only, with a short delay before replying so it does not answer at machine speed. Connects to 5-calendar age routing when booking path; Human handoff bridge when any of the ten mandatory conditions; Context-aware follow-up when the contact goes quiet.
    2. Locked persona (Guard, AI prompt). The bot speaks as the named human the whole campaign is built around, rather than as an assistant — a documented reversal of an earlier recommendation. Connects to AI booking concierge when speaks as the named human.
    3. 5-document knowledge base (Data store, CRM). Five chunked documents — the trial offer, the schedule, what to expect at a first session, a trial-only pricing FAQ, and venue basics — plus the objection set, with pricing scripts routed by retrieval trigger. Connects to AI booking concierge when answers grounded in five documents only.
    4. 5-calendar age routing (Calendar, CRM). Five age-segmented calendars with deterministic numeric routing, a locked tiebreaker at the boundary age, and no fallback calendar — every served age fits a programme. Connects to Booking exit when booked in-thread on one of five calendars.
    5. Context-aware follow-up (Wait, CRM native follow-up). Three scenarios with deliberately asymmetric depth — five sequences for someone who simply went silent, three for someone who said they were busy ending in a stated farewell, and two for someone who asked to be contacted at a named time. Connects to AI booking concierge when any inbound cancels the rest; Tag taxonomy & fields when ladder exhausted → stalled marker.
    6. Human handoff bridge (Human, CRM). Ten mandatory conditions fetch a person — a complaint, refunds or billing, abusive language, the same objection raised twice, a disclosed medical condition, legal questions, a group enquiry, a sincere "is this a real person", pricing pushed beyond the scripts, and an age outside the served programmes. Connects to Two terminal states when a person owns the thread from here.
    7. 12 hard rules (Guard, AI prompt). Never quote membership pricing beyond the two scripted answers, never promise a specific instructor or an outcome, never book outside the designated calendars, no medical or training advice, one reframe per objection then accept and soft-close, never invent a fact, never claim to be human, one link per message and always the same one, and never negotiate the offer. Connects to AI booking concierge when every composed reply.
  6. Stage 6, Booking exit: A booking on any calendar tags the win and closes the campaign for that lead.
    1. Booking exit (Workflow, CRM). Triggered by a booking on any of the five calendars, filtered to a card in the campaign pipeline at either the entry or the revived stage, because a contact can win from either. Connects to Pipeline-filtered win when pipeline + stage filter on the trigger; Tag taxonomy & fields when win tag applied, active tag removed; 3-stage campaign pipeline when card moved to the terminal booked stage; Two terminal states when enrolled into the existing confirmation campaign.
    2. Pipeline-filtered win (Guard, CRM). The pipeline-and-stage filter on the booking trigger.
    3. Reuse the live calendar (Guard, CRM). A deliberate ruling to book onto the existing trial calendars rather than create campaign-specific ones. Connects to Booking exit when bookings land on the live calendars.
  7. Stage 7, Day-30 sunset: Mark the non-bookers, strip the active flag, hand them onward, and keep the card as history.
    1. Day-30 cleanup (Workflow, CRM). Fired explicitly by the drip’s final step as the single source of truth, with a documented date-based fallback on the last-contact field for plan tiers that lack the run-workflow action. Connects to Two terminal states when win tag present → end immediately; Ongoing-track handoff when no booking → archive marker + handoff tag.
    2. Ongoing-track handoff (Outcome, CRM (out of scope)). The campaign is one-shot and does not self-rerun: cleanup ends the lifecycle and hands non-bookers to the client’s pre-existing ongoing reactivation workflow, which fires when that tag is added. Connects to Two terminal states when ownership passes out of the campaign.
    3. Two terminal states (Outcome, CRM). Every contact ends in exactly one of two states: booked and handed to the confirmation stack, or no-response holding the archive marker and the handoff tag with the active flag stripped.
  8. Stage 8, Isolation & test: Prove the campaign cannot collide with the live pipelines already running in the same account.
    1. Cross-pipeline isolation audit (Report, CRM (read-only)). A written pre-publish checklist of every existing workflow the campaign’s three new triggers could fire. Connects to Booking exit when filters verified before publish; Reply handler when existing auto-responders exclude the active tag; 15 touches, 30 days when broadcast workflows exclude the entry stage.
    2. Primary-bot collision check (Guard, CRM). Only one bot can be primary per sub-account, and primary is required for inbound email auto-reply. Connects to AI booking concierge when no other live agent displaced.
    3. Test suites (Report, Test plan). An eight-scenario end-to-end plan run with real test contacts on known-safe numbers, plus three further suites of bot, ladder and prompt cases. Connects to Client sign-off gate when every scenario and case passes.
    4. Client sign-off gate (Human, Delivery process). Written client approval on the copy, the offer and deadline, the final cleaned list count, the send window and the pipeline rules, saved for the audit trail before publish. Connects to The 30-day drip when publish.
    5. Catastrophic kill switch (Guard, CRM). A four-step documented abort: switch the bot off, pause the reply handler, reply by hand to every in-flight revived contact, and re-enable only after a fix plus a full re-run of the bot cases. Connects to AI booking concierge when bot off, handler paused, replies by hand.
0/10

A contact who enquired eight months ago and never came in replies to the message that plants curiosity.

Read this system as text

  1. Stage 01

    List preparation

    Define what "dead" means, clean the list, and clear the compliance gate before anything can send.

    • Dead-lead definition · Human · Delivery process — A written definition agreed with the client before any list is pulled — enquired months ago, never enrolled, never an active member, not opted out, and a valid phone or email on file. → Clean & exclude (definition agreed in writing)
    • Clean & exclude · Guard · Spreadsheet + CRM — Confirm the source, map headers, normalise every phone to a single international format, validate emails, note the row count before any cleaning — then run the exclusions. → Sender-registration gate (exclusions applied, counts logged)
    • Sender-registration gate · Guard · Messaging compliance — A hard stop: the campaign may not launch on an unregistered sender. A registered number, an approved carrier registration and a delivered test message are all required first. → CSV import runbook (sender registered, test message delivered), Dead-lead definition (sender unregistered → do not launch)
    • Staged enrolment · Scheduled job · CRM — Batch sizing by list size — a small list in one batch, a medium one split across two days, a large one staged over several — weekday mornings only, with the first hour of sends monitored for rejections. → CSV import runbook (batch sizing by list size)

  2. Stage 02

    Import & enrolment

    Bulk-create contacts and cards, stamp the entry source, and place them so the drip fires.

    • CSV import runbook · Source · CRM — Five required columns and a fixed four-option entry-source value; bulk-import the contacts, bulk-create one card per contact at the entry stage with the source set, then verify in the execution logs that the drip entered for every contact within minutes. → 3-stage campaign pipeline (one card per contact at the entry stage), Import-field helper (entry-source field did not stick)
    • 3-stage campaign pipeline · CRM record · CRM — A dedicated pipeline with an entry stage, a revived stage written by the reply handler, and a terminal booked stage kept as a permanent win record. → Stage-change entry (card lands at the entry stage)
    • Stage-change entry · Trigger · CRM — The drip is triggered by a pipeline-stage-changed event into the entry stage, not by a tag. Stage moves are the only triggers used for downstream automation on this account. → The 30-day drip (stage-changed event)
    • Import-field helper · Workflow · CRM — A fallback for a documented platform inconsistency: bulk add-to-pipeline reliably sets the stage but sets card custom fields inconsistently across platform versions. → Tag taxonomy & fields (writes the source, then self-disables)
    • Tag taxonomy & fields · Data store · CRM — Eight canonical tags each with a declared owner and lifecycle, plus three card-level fields — entry source set at import, last-contact date stamped by the drip, and an intent timestamp stamped by the reply handler.

  3. Stage 03

    30-day drip

    Fifteen paced touches, quiet-hours bounded, with every exit living outside the workflow.

    • The 30-day drip · Workflow · CRM — Thirty-five steps with re-entry off: apply the active tag, stamp the last-contact date, run the touches, then a buffer carrying the contact to day 30 and an explicit final step that fires the cleanup. → Tag taxonomy & fields (active tag, last-contact date), 15 touches, 30 days (fifteen paced sends), Day-30 cleanup (final step fires the cleanup), Three drip exits (every exit lives outside the workflow)
    • 15 touches, 30 days · Message · SMS + email — Two named phases. The first week is pure pulse-finding — no calls to action, no offer name, no links. Everything after introduces the trial, one angle at a time. → Quiet hours (every send), Reply handler (the lead replies), Booking exit (self-books via the fallback link), Three drip exits (booking, intent keyword, or opt-out)
    • Quiet hours · Guard · CRM — A workflow-level daytime window in the contact’s own timezone on both the drip and the reply handler, with a documented fallback to the business timezone — deliberately narrower than the legal floor.
    • Three drip exits · Decision · CRM — The booking handler removes the contact on any booking; the reply handler removes them on an intent keyword; a texted stop engages native opt-out, so the drip keeps running but produces no messages. → The 30-day drip (booking, intent keyword, or opt-out)

  4. Stage 04

    Reply & intent

    Detect a reply that reads as interest, pull the lead out of the drip, and hand the thread over.

    • Reply handler · Workflow · CRM — Triggered by an inbound message on either channel — upgraded from one channel because the concierge answers on both — with three filters that must all match: the campaign pipeline, the entry stage, and a body match. → 15-keyword intent filter (pipeline + entry stage + body match)
    • 15-keyword intent filter · Decision · CRM — At the workflow boundary this is not a model — it is a flat, case-insensitive contains-any-of list of fifteen keywords. The AI classifies conversationally only after it has been handed the contact. → Pull, move, hand off (body contains an intent keyword), 15 touches, 30 days (no match → stays in the drip)
    • 8-category intent routing · AI · AI charter — Four categories where the AI takes over — explicit positive keywords, a question about the trial or venue (questions ARE positive intent), ambiguous-but-leaning-positive, and off-topic-but-engaged, which gets exactly one turn to acknowledge and redirect. → AI booking concierge (positive, question, ambiguous, or engaged off-topic), 15 touches, 30 days (soft negative or bare emoji → stay in the drip, tagged), Two terminal states (hard negative → stop compliance, no AI message)
    • Pull, move, hand off · Workflow · CRM — Six ordered steps and then the workflow ends: remove from the drip FIRST, apply the intent tag, stamp the timestamp, move the existing card to the revived stage, send one human-feeling acknowledgement, and enable the concierge on this contact. → 8-category intent routing (the AI classifies only once it holds the contact), The 30-day drip (step one removes them from the drip first), 3-stage campaign pipeline (existing card moved to revived)

  5. Stage 05

    AI booking concierge

    Answer from the knowledge base, route by age, book in-thread, and know exactly when to fetch a human.

    • AI booking concierge · AI · CRM Conversation AI — An auto-pilot agent set as the account’s primary bot — required for inbound email auto-reply at all — on messaging and email only, with a short delay before replying so it does not answer at machine speed. → 5-calendar age routing (booking path), Human handoff bridge (any of the ten mandatory conditions), Context-aware follow-up (the contact goes quiet)
    • Locked persona · Guard · AI prompt — The bot speaks as the named human the whole campaign is built around, rather than as an assistant — a documented reversal of an earlier recommendation. → AI booking concierge (speaks as the named human)
    • 5-document knowledge base · Data store · CRM — Five chunked documents — the trial offer, the schedule, what to expect at a first session, a trial-only pricing FAQ, and venue basics — plus the objection set, with pricing scripts routed by retrieval trigger. → AI booking concierge (answers grounded in five documents only)
    • 5-calendar age routing · Calendar · CRM — Five age-segmented calendars with deterministic numeric routing, a locked tiebreaker at the boundary age, and no fallback calendar — every served age fits a programme. → Booking exit (booked in-thread on one of five calendars)
    • Context-aware follow-up · Wait · CRM native follow-up — Three scenarios with deliberately asymmetric depth — five sequences for someone who simply went silent, three for someone who said they were busy ending in a stated farewell, and two for someone who asked to be contacted at a named time. → AI booking concierge (any inbound cancels the rest), Tag taxonomy & fields (ladder exhausted → stalled marker)
    • Human handoff bridge · Human · CRM — Ten mandatory conditions fetch a person — a complaint, refunds or billing, abusive language, the same objection raised twice, a disclosed medical condition, legal questions, a group enquiry, a sincere "is this a real person", pricing pushed beyond the scripts, and an age outside the served programmes. → Two terminal states (a person owns the thread from here)
    • 12 hard rules · Guard · AI prompt — Never quote membership pricing beyond the two scripted answers, never promise a specific instructor or an outcome, never book outside the designated calendars, no medical or training advice, one reframe per objection then accept and soft-close, never invent a fact, never claim to be human, one link per message and always the same one, and never negotiate the offer. → AI booking concierge (every composed reply)

  6. Stage 06

    Booking exit

    A booking on any calendar tags the win and closes the campaign for that lead.

    • Booking exit · Workflow · CRM — Triggered by a booking on any of the five calendars, filtered to a card in the campaign pipeline at either the entry or the revived stage, because a contact can win from either. → Pipeline-filtered win (pipeline + stage filter on the trigger), Tag taxonomy & fields (win tag applied, active tag removed), 3-stage campaign pipeline (card moved to the terminal booked stage), Two terminal states (enrolled into the existing confirmation campaign)
    • Pipeline-filtered win · Guard · CRM — The pipeline-and-stage filter on the booking trigger.
    • Reuse the live calendar · Guard · CRM — A deliberate ruling to book onto the existing trial calendars rather than create campaign-specific ones. → Booking exit (bookings land on the live calendars)

  7. Stage 07

    Day-30 sunset

    Mark the non-bookers, strip the active flag, hand them onward, and keep the card as history.

    • Day-30 cleanup · Workflow · CRM — Fired explicitly by the drip’s final step as the single source of truth, with a documented date-based fallback on the last-contact field for plan tiers that lack the run-workflow action. → Two terminal states (win tag present → end immediately), Ongoing-track handoff (no booking → archive marker + handoff tag)
    • Ongoing-track handoff · Outcome · CRM (out of scope) — The campaign is one-shot and does not self-rerun: cleanup ends the lifecycle and hands non-bookers to the client’s pre-existing ongoing reactivation workflow, which fires when that tag is added. → Two terminal states (ownership passes out of the campaign)
    • Two terminal states · Outcome · CRM — Every contact ends in exactly one of two states: booked and handed to the confirmation stack, or no-response holding the archive marker and the handoff tag with the active flag stripped.

  8. Stage 08

    Isolation & test

    Prove the campaign cannot collide with the live pipelines already running in the same account.

    • Cross-pipeline isolation audit · Report · CRM (read-only) — A written pre-publish checklist of every existing workflow the campaign’s three new triggers could fire. → Booking exit (filters verified before publish), Reply handler (existing auto-responders exclude the active tag), 15 touches, 30 days (broadcast workflows exclude the entry stage)
    • Primary-bot collision check · Guard · CRM — Only one bot can be primary per sub-account, and primary is required for inbound email auto-reply. → AI booking concierge (no other live agent displaced)
    • Test suites · Report · Test plan — An eight-scenario end-to-end plan run with real test contacts on known-safe numbers, plus three further suites of bot, ladder and prompt cases. → Client sign-off gate (every scenario and case passes)
    • Client sign-off gate · Human · Delivery process — Written client approval on the copy, the offer and deadline, the final cleaned list count, the send window and the pipeline rules, saved for the audit trail before publish. → The 30-day drip (publish)
    • Catastrophic kill switch · Guard · CRM — A four-step documented abort: switch the bot off, pause the reply handler, reply by hand to every in-flight revived contact, and re-enable only after a fix plus a full re-run of the bot cases. → AI booking concierge (bot off, handler paused, replies by hand)

Platforms · GoHighLevel · Conversation AI · SMS · Email

What I built

A list, defined before it was pulled

Dead was defined in writing with the client first: enquired months ago, never enrolled, never an active member, not opted out, with a valid phone or email on file. The list is the campaign, so an undefined list is an undefined campaign. Cleaning normalises every phone, validates emails, and logs the row count after each exclusion so the audit trail shows what was removed and why. The exclusions strip anyone already booked, already mid-campaign, or sitting in another live pipeline, because those people are not dead.

Enrolment by stage, not by tag

Import creates one card per contact at the entry stage of a dedicated three-stage pipeline, and that stage change is what fires the drip. A tag trigger was rejected because anyone adding the tag by hand re-enrols the contact, and a bulk add-to-workflow leaves no audit trail. The winning reason is a reporting one: the count of cards at the entry stage is the remaining campaign volume, visible without asking anyone. Enrolment is staged by list size, weekday mornings only, with the first hour of sends watched for rejections.

A 30-day drip with every exit outside it

The drip is 35 steps with re-entry off and no internal branches at all. Fifteen touches, seven SMS and eight emails, run across 30 days, then a buffer carries the contact to day 30 and an explicit final step fires the cleanup. Keeping every exit external is what makes the exits auditable in one place rather than buried in a graph.

The first week is pure pulse-finding: no calls to action, no offer name, no links. Everything after introduces the offer one angle at a time, ending in an honest send-off that leaves the door open. Quiet hours run in the contact's own timezone, deliberately narrower than the legal floor.

A keyword gate in front of an expensive one

At the workflow boundary, intent detection is not a model. It is a flat, case-insensitive contains-any-of list of fifteen keywords, sitting in front of the AI as the cheapest possible gate. Only after handoff does the AI classify conversationally, into eight categories: four where it takes over, including a question about the offer, because a question is positive intent, and four where it does not. A hard negative gets immediate stop compliance and no AI message. A soft negative is tagged and deliberately left in the drip.

The reply handler runs six ordered steps and ends: remove from the drip first, tag the intent, stamp the timestamp, move the card to the revived stage, send one human-feeling acknowledgement, and enable the concierge. Removal comes first so a scheduled drip message cannot land while the bot is mid-conversation.

A concierge that books in-thread

The AI answers only from five chunked knowledge-base documents and the configured values; anything else uses a verbatim unknown-question fallback plus a handoff notification rather than improvising. It routes across five age-segmented calendars by deterministic numeric rules with no fallback calendar, and books in the thread rather than sending a link. Ten conditions fetch a human, among them a complaint, a disclosed medical condition, and the same objection raised twice.

A booking exit and a day-30 sunset

Any booking on any of the five calendars, filtered to a card in the campaign pipeline, removes the contact from the drip and the reply handler, tags the win, moves the card to the booked stage and enrols them into the client's existing confirmation campaign. Reusing the live calendars is a deliberate ruling: the point is to deliver a contact into the existing booking flow, and a campaign-specific calendar would orphan the booking.

At day 30 the cleanup ends immediately if the win tag is present, otherwise it marks no-response, strips the active flag, applies the handoff tag, and does nothing to the card. The card stays where it died, so the stage preserves the drop-off point.

Edge cases and failure handling

  • A politely negative reply can still satisfy the keyword gate, because several keywords are short enough to match inside a longer phrase and there is no negative-exclusion list. That is a known shape of the design, documented rather than papered over.
  • A positive reply arrives at 11pm. Quiet hours queue the response until morning, recorded as a decision rather than found later as a defect.
  • A contact texts stop. Native opt-out engages, the drip keeps running but sends no messages, and the day-30 cleanup still runs. Email is not suppressed by that stop, so the footer's unsubscribe link is the email-side opt-out, and that is documented as intended rather than assumed.
  • The campaign's triggers could fire workflows behind the live pipelines. A written pre-publish checklist covers every one: stage-changed workflows on other pipelines must carry explicit pipeline filters, no duplicate booking workflow may create a parallel card, any inbound auto-responder must exclude the campaign's active tag, and broadcast workflows must exclude contacts at the entry stage. The confirmation stack is the exception, because firing it for campaign bookings is the intended handoff rather than a collision.
  • The onward handoff hangs on one string match. If the receiving workflow's trigger tag differs by a character it fails silently, so a post-run check verifies the tag landed on every no-response contact.

How I verified it

The campaign is specified to be proven before it is published, and the test plan is part of the deliverable rather than an afterthought. Eight end-to-end scenarios run with real test contacts on known-safe numbers, covering a booking mid-drip, positive intent that never books, thirty days of silence, an opt-out, a booking followed by a cancellation, the onward handoff, and a contamination check that imports someone already in another live pipeline and proves nothing else re-fires.

Two checks are negatives, which is the point: prove a contact who booked early does not receive the onward handoff tag, and prove an inbound reply cancels the next scheduled follow-up rather than merely delaying it. Three further suites cover the bot, the ladders and the prompt. The bot suite must pass on three consecutive runs with different contacts, and the pricing-leak check says plainly that if any amount appears, kill it and rewrite the prompt.

Behind all of it sits a standing instruction: manually audit the first twenty bot conversations end to end before letting it run unsupervised.

What changed

The business has a campaign that works its cold list end to end with no manual effort: fifteen paced touches over 30 days, a keyword gate in front of an AI concierge that books in-thread across five calendars, an exit on any booking, and a day-30 sunset that hands non-responders to the ongoing reactivation track the account already had. Every contact ends in exactly one of two states: booked and handed to the confirmation stack, or no-response holding the archive marker with the card left where it died.

The isolation work is what unblocked the list. A written pre-publish checklist names every existing workflow the campaign's triggers could reach, and what each must exclude. The business owns the rest of it too: the dead-lead definition, a taxonomy of eight canonical tags with declared owners, a CSV import runbook, the eight-scenario plan and three further suites, and a kill switch that turns the bot off, pauses the reply handler and hands every in-flight contact back to a human.

Before / after

  • Before
  • ✕ Hundreds of old, unworked leads sat dead in the CRM
  • ✕ Manual reactivation never happened
  • ✕ No safe way to re-message without colliding with live campaigns
  • After
  • ✓ 100% of the dead list worked automatically, end to end
  • ✓ Hot replies routed straight to booking, no manual triage
  • ✓ Zero cross-campaign collisions, validated by an 8-scenario test plan

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