Back to the build library
Any industry
Starter

Database Reactivation Campaign

Turn a dormant contact list into booked appointments with throttled conversational waves, AI reply routing and a hard compliance floor.

Industry
Any industry
Build effort
Starter
Typical time to launch
4–7 days
On this page
The problemWhat gets builtHow it runsAutomations in detailWhat changesBefore you start
Want this built for you?

Bring your stack to a call and we will scope it against how your business actually runs.

Book a call
01

The problem

Almost every established business is sitting on a list it has written off. Old inquiries that never booked. Customers who came once in 2023 and never came back. Leads from a campaign that ran before the current system existed. Quote requests that went quiet. In a business a few years old this is routinely thousands of records, and the standard operating assumption about all of them is that they are dead, which is a convenient belief, because it means nobody has to do anything about them.

They are mostly not dead. They are unfinished. The vast majority never said no; they said nothing, which is a very different thing. People got busy, the timing was wrong, they went with someone else for that one job, or they simply forgot. The reason the list looks dead is that the last touch was a marketing email asking them to buy, sent to an address they never read, from a sender they do not recognize. Nothing in that sequence invites a reply, so no reply happens, and the silence is then taken as proof of death.

The leak here is not a leak so much as a stranded asset. These contacts have already been paid for. In ad spend, in referral effort, in the time someone spent on the phone with them two years ago. The acquisition cost is sunk and irrecoverable, so the marginal cost of one more conversation is close to nothing. Meanwhile the business keeps buying new clicks at full price. The second failure is risk management: the one time most businesses do touch the old list, they blast all 4,000 records in a single afternoon, which burns the sending reputation, trips carrier filtering, generates a wave of complaints, and converts a recoverable asset into a permanently poisoned one. This build exists to do the opposite. Small throttled waves, one human question at a time, with every reply routed, and a compliance floor that is not negotiable.

02

What gets built

Pipelines and stages

A Reactivation pipeline, separate from your live inbound pipeline so your real conversion reporting is not contaminated by a campaign:

  1. Queued: eligible, assigned to a wave, not yet contacted.
  2. Message Sent: first touch delivered, no reply.
  3. Replied: Interested: a positive or curious reply. The only stage that matters today.
  4. Replied: Not Now: a real person saying later. Goes to long nurture, not to the bin.
  5. Replied: Negative: not interested, wrong person, already handled elsewhere.
  6. Appointment Booked
  7. Showed
  8. Won
  9. No Response: the wave’s touches ran out. Re-eligible after a long cooldown.
  10. Excluded: opted out, bad data, or suppressed. Terminal.

Segments to build before anything sends

Never treat the database as one list. Build these as saved segments and run them as separate waves with different copy:

  • Unconverted inquiries, 90–365 days: the warmest group and where you start. They asked once and never got an answer that landed.
  • Unconverted inquiries, 1–2 years: still viable, needs more context in the message.
  • Past customers, no activity 6–18 months: the highest-value group, because they have already bought once and the barrier is near zero.
  • Past customers, no activity over 18 months: viable but expect a lower reply rate and more “who is this”.
  • Partial bookings and abandoned forms: small, very warm, run first as your pilot.
  • Excluded by default: anyone with an opt-out, a complaint, an unresolved dispute, a hard email bounce, an unverified or landline-only number, or no consent record at all.

Custom fields

  • reactivation_wave (text): e.g. “W1-past-customers-6to18”. Every record gets exactly one.
  • reactivation_batch (number). The daily send batch inside the wave. This is your throttle.
  • reactivation_sent_at (date/time): first touch timestamp.
  • reactivation_touch_count (number): hard cap of 3.
  • last_activity_at (date/time). The field the segments are built on. Get this right or everything downstream is wrong.
  • original_source (text), where they came from originally, so the message can reference it truthfully.
  • previous_service (text). What they bought or asked about. The single biggest driver of reply rate.
  • reply_sentiment (dropdown): Interested, Not Now, Negative, Wrong Person, Unclear.
  • reply_classified_at (date/time).
  • recontact_after (date): set by the Not Now path. Nothing may contact them before this date.
  • consent_basis (dropdown): Express written, Existing relationship, None. “None” means excluded, permanently.
  • consent_captured_at (date/time) and consent_source (text): your audit trail for every record in the wave.
  • reactivation_excluded_reason (text).
  • number_type (dropdown): Mobile, Landline, Unknown. Only Mobile gets SMS.

Tags

reactivation-eligible, reactivation-wave-1 (and so on per wave), reactivation-sent, reactivation-interested, reactivation-not-now, reactivation-negative, reactivation-booked, reactivation-no-response, reactivation-excluded, sms-stop, do-not-contact.

Calendars and pages

  • Reactivation Consult: a dedicated calendar, 20–30 minutes, with deliberately generous availability. A reactivated lead has low commitment; a sparse calendar loses them.
  • A single-purpose landing page: one offer, one booking widget, no navigation. Used only for the email track and for anyone who asks for details in writing. It states what the offer is and does not state a price; pricing is scoped per build and belongs on the call.
  • A short re-opt-in page for anyone whose consent basis is weak but who is reachable by email. The compliant way to bring a stale record back into SMS rather than assuming.

The AI assistant

BO does the heaviest lifting in this build, because a wave of 150 messages can produce 30 replies in an hour and no human can triage that live.

  • Role one: classification. Read each inbound reply and write reply_sentiment. Five buckets only. Anything ambiguous goes to Unclear and straight to a human; a wrong classification here is expensive, so the assistant should be biased toward Unclear.
  • Role two: conversation. For Interested replies, answer the obvious follow-up, confirm what they need, and get a time booked. Short messages, one question at a time, never a paragraph.
  • Guardrails. Never quote a price, fee, discount or figure of any kind. The offer is a conversation, and pricing is scoped per build. Never invent history: it may reference only what is actually in previous_service and original_source, and if those are empty it must speak generally. Never claim the person is an existing customer if they are not. Never pressure, never use false scarcity, never imply a deadline that does not exist. Never message outside quiet hours. Maximum two outbound messages without a reply, then stop. Hand off immediately on: any pricing question, any complaint or reference to a past bad experience, any mention of legal action, any confusion about who the business is that survives one clarification, any distress, and anything classified Unclear.

Channels and throttling

  • The same business number used for everything else, so replies land where your team already works and the thread looks like a continuation rather than a cold approach.
  • A hard daily send cap. Start at 50 messages a day per number for the first three days, then step up only if delivery and opt-out rates stay healthy. Never exceed a few hundred a day on a single local number; if you need more volume, you need more numbers and more registration, not a bigger batch.
  • Email as a parallel, lower-risk track for records with weak SMS consent or a landline, warmed slowly on an authenticated domain.
  • A send window of 10:00–17:00 local, weekdays only, for the first wave. Reactivation messages sent on a Sunday evening read exactly like spam.
03

How it runs, step by step

One dormant record, end to end

  1. Day 0, preparation. A past customer last seen 14 months ago is pulled into the Past customers, 6–18 months segment. The eligibility workflow checks consent basis, number type, bounce history and suppression tags. She passes: express written consent captured at her original booking, a verified mobile, no complaints. She is tagged reactivation-wave-1, assigned reactivation_batch = 3, and placed in Queued.
  2. Day 3, 10:15am. Batch 3 sends: 48 records, inside the window, inside the cap. Her message is one line and a question, references the service she actually had, and asks nothing more than whether she wants to come back in. reactivation_sent_at is stamped, reactivation_touch_count = 1, record moves to Message Sent.
  3. Day 3, 10:41am. She replies: “Oh hi! Yes I’ve been meaning to sort that out actually.”
  4. Within seconds. BO classifies the reply as Interested, writes reply_sentiment and reply_classified_at, moves the record to Replied: Interested, cancels the remaining two touches, and applies reactivation-interested. The team channel gets a notification with her name, her previous service, and the thread.
  5. Day 3, 10:41am. BO replies in one short message, confirms what she had before, and offers two concrete times from the Reactivation Consult calendar.
  6. Day 3, 10:44am. She asks what it costs now. BO does not answer with a figure. It says it depends on what she actually needs, that the call is where that gets worked out, and re-offers the time. Because pricing was asked, the thread is also flagged for a human to watch.
  7. Day 3, 10:52am. She books Friday at 2pm. The record moves to Appointment Booked, picks up reactivation-booked, and drops out of every reactivation workflow. Confirmation and the standard reminder ladder take over.
  8. Day 5, 2:00pm. She attends. Record moves to Showed, then Won when she purchases, and: importantly: last_activity_at is rewritten so she can never be pulled into a future reactivation wave as a dormant record.
  9. The Not Now branch. Had she replied “not right now, maybe after the summer”, BO would have classified Not Now, asked one question to pin down a month, written recontact_after to the first of that month, moved the record to Replied, Not Now, and stopped. She would then receive nothing at all until that date, at which point a single gentle check-in fires. This path is worth more than it looks: a dated “later” is a real pipeline entry, and it converts far better than a cold re-approach.
  10. The Negative branch. A “no thanks” would have moved her to Replied: Negative, applied suppression so no future wave can touch her, and sent one brief, graceful acknowledgement. No rebuttal, no offer, no second attempt.
  11. The silent branch. With no reply at all, two further touches would have gone out (one at 3 days, one at 7) then stopped permanently. Record to No Response, recontact_after set 12 months out.
04

Automations in detail

WF-D1 · Eligibility, Segmentation and Batch Assignment

Trigger: Run manually per wave, or on a schedule once the first wave has proven itself.

Exclude before you include. Build the exclusion list first and apply it as the entry condition. A record is excluded, with reactivation_excluded_reason written, if any of these is true:

  • consent_basis = None, or consent_captured_at is empty
  • tag sms-stop, do-not-contact, or reactivation-excluded
  • number_type ≠ Mobile (for the SMS track)
  • a hard email bounce, or two or more soft bounces (for the email track)
  • an open dispute, complaint, refund, or unresolved service issue
  • recontact_after is in the future
  • any activity in the last 90 days. They are not dormant, and treating a live contact as dormant is the most embarrassing failure mode of this build
  • an open opportunity anywhere in any pipeline
  • duplicate of a record already in this wave

Actions, in order:

  1. Apply the segment definition: one segment per wave, never combined.
  2. Write reactivation_wave, add the wave tag and reactivation-eligible.
  3. Create an opportunity in Reactivation → Queued.
  4. Assign reactivation_batch by dividing the wave into daily batches at or below the send cap: start at 50 per day. Sort the batches so the warmest records go first: a bad first batch tells you the copy is wrong while it is still cheap to fix.
  5. Hold the whole wave for a human review gate. Export the first batch and have someone read 20 records and the exact message they will receive. Launch nothing until that is signed off. This step prevents every expensive mistake in this build.

Pilot rule: the first batch is 25 records, not 50, and nothing else sends until you have looked at delivery, replies and opt-outs from those 25.

WF-D2 · Wave Send

Trigger: reactivation_batch equals today’s batch number and the record is in Queued.

Conditions: inside the send window (10:00–17:00 local, weekdays); no exclusion tag acquired since assignment; daily cap not yet reached.

Actions:

  1. Re-run the exclusion check. Days may have passed since assignment and someone may have opted out, complained, or become an active customer in between. Never trust a stale queue.
  2. Branch on previous_service. If populated, send the specific variant. If empty, send the general variant, and never fabricate a history.
  3. Send SMS, specific variant: “Hi {{first_name}}: it’s {{sender_first_name}} at {{business_name}}. You came to us for {{previous_service}} a while back and I was going through our books. Are you still looking after that, or would it help to get back in?”
  4. General variant: “Hi {{first_name}}, {{sender_first_name}} here from {{business_name}}. We spoke a while ago about {{original_source_topic}} and I never heard how you got on. Did you get it sorted in the end?”
  5. Stamp reactivation_sent_at; set reactivation_touch_count = 1; add reactivation-sent; move to Message Sent.

Why the copy looks like this: it is one short message, from a named person, with exactly one question, and the question is about them rather than about buying. It contains no offer, no link, no emoji, no capitals and no price. Links in a first cold-ish touch depress deliverability and raise complaint rates; earn the link with a reply. The question “did you get it sorted?” is the highest-performing shape in this build because it is answerable in two words and genuinely curious.

Follow-up touches, same workflow:

  1. Wait 3 days. Condition: no reply, no exclusion. Send: “No worries if the timing’s off, {{first_name}}, just didn’t want to leave it hanging. Want me to send over a couple of times, or shall I leave it with you?” Increment reactivation_touch_count to 2.
  2. Wait 4 days. Condition: still no reply. Send: “Last one from me: I’ll leave you be. If anything changes, this number reaches me directly. All the best, {{sender_first_name}}.” Increment to 3.
  3. Wait 2 days. Add reactivation-no-response; move to No Response; set recontact_after = today + 12 months.

Hard cap: three touches. Ever. No exceptions, no fourth “just checking” message. The third message deliberately releases them, which is both decent and the reason the opt-out rate on this build stays low.

Exit conditions: any inbound reply on any channel; any opt-out; appointment booked; an opportunity created elsewhere; exclusion tag applied.

WF-D3 · Reply Router

Trigger: Inbound SMS or email from a contact tagged with any reactivation wave tag.

  1. Cancel every pending touch in WF-D2 immediately.
  2. First branch: opt-out language. STOP, UNSUBSCRIBE, REMOVE, CANCEL, END, QUIT, OPT OUT, “take me off”, “don’t contact me”, “how did you get my number” → route to WF-D7 and stop. Treat “how did you get my number” as an opt-out, not a question; answer it once, politely, then suppress.
  3. Second branch: escalation language. Legal, attorney, lawyer, complaint, report, regulator, ombudsman, ICO, scam, fraud, harassment → no automated reply at all. Notify the owner directly by push and SMS. Suppress the contact from all waves. A human handles it personally.
  4. Third branch: classification by BO into exactly one of: Interested, Not Now, Negative, Wrong Person, Unclear. Write reply_sentiment and reply_classified_at. Bias toward Unclear. A misread “no” treated as a “yes” is the worst outcome available here.
  5. Route on classification:
    • Interested → tag reactivation-interested, stage Replied: Interested, continue to WF-D4. Notify the team channel.
    • Not Now → tag reactivation-not-now, stage Replied, Not Now, continue to WF-D5.
    • Negative → tag reactivation-negative, stage Replied: Negative, send one line (“Understood, thanks for letting me know) I won’t chase you again.”, then suppress from all future waves. No rebuttal. No offer. Nothing.
    • Wrong Person → correct the record, clear the phone or email, set consent_basis = None, stage Excluded.
    • Unclear → no automated reply. Create a task for a human, due in 1 hour, with the message text. Notify the on-duty owner.
  6. Dead-thread guard: if any inbound message sits unanswered for 15 minutes, escalate to a human regardless of classification. A dormant contact who finally replied and then got silence is worse off than one you never messaged.

WF-D4 · Interested → Booking

Trigger: Tag reactivation-interested added.

  1. BO replies within seconds. One short message: acknowledge, confirm what they need in one question, offer two specific times. “Great: good to hear from you. Is it {{previous_service}} again, or something different this time?”
  2. On their answer, send the booking link with two named slots: “I’ve got Thursday 2pm or Friday 10am, either work? Or pick whatever suits here: {{booking_link}}”
  3. Wait 2 hours. Condition: no booking, no reply. One nudge only: “No rush. Here’s the link whenever you’re ready: {{booking_link}}”
  4. Wait 1 day. Condition: still no booking. Create a call task for the on-duty owner. An interested reply that did not book is a phone call, not another text.
  5. Wait 2 days. Condition: still no booking. Final text: “Still happy to find you a time if you want one. Just say the word.” Then stop and leave the record in Replied: Interested for human follow-up. Never return an interested reply to the automated ladder.
  6. On booking: move to Appointment Booked, tag reactivation-booked, remove all reactivation workflows, hand to the standard confirmation and reminder sequence.
  7. Escalate to a human immediately on any pricing question, any reference to a past bad experience, or any message BO cannot answer from previous_service and the service list.

WF-D5 · Not Now → Dated Nurture

Trigger: Tag reactivation-not-now added.

  1. BO asks exactly one question: “Totally fine: roughly when would be better? I’ll make a note and get out of your way.”
  2. Parse the answer into recontact_after. A month name becomes the 1st of that month; “a few months” becomes today + 90 days; “next year” becomes 1 January; no answer becomes today + 120 days.
  3. Confirm and close: “Noted: I’ll check back around then. Nothing from me in the meantime.” Then nothing is sent until that date. Honouring this is what makes the later check-in work.
  4. Wait until recontact_after. Re-run the full exclusion check, then send one message: “Hi {{first_name}}, {{sender_first_name}} at {{business_name}}. You mentioned {{recontact_month}} might suit better for {{previous_service}}. Still useful, or shall I close it off?”
  5. Route the reply back through WF-D3. A record may go round this loop at most twice; on the third “not now”, move to Excluded and stop asking.

WF-D6 · Parallel Email Track

Trigger: Record is in the wave with a valid email, and either no mobile or no SMS consent.

  1. Warm the domain first. Day 1: 50 emails. Day 2: 100. Day 3: 200. Only step up while bounce rate stays under 2% and complaint rate under 0.1%. A reactivation blast is the fastest way to destroy a sending domain, and the damage reaches your transactional mail too.
  2. Email 1, day 0. Plain text, from a named person’s address, no images, no template, no footer graphics. Subject: “Did you get this sorted?” Body: three sentences and one question. A single unsubscribe link, clearly visible.
  3. Wait 4 days. Condition: no reply, no click. Email 2, subject “One quick thing”. One short paragraph and the landing page link.
  4. Wait 6 days. Condition: still nothing. Email 3, subject “Closing your file”. Two lines, releases them, link to the re-opt-in page if they want to stay.
  5. Any open or click → tag as engaged. Any reply → route through WF-D3.
  6. No engagement after three emails → move to No Response and remove the address from all future campaign sends. Continuing to mail a non-responder is how a list gets worse, not better.

WF-D7 · Opt-Out and Suppression

Trigger: Opt-out language on any channel, a carrier opt-out, an email unsubscribe, or a complaint.

  1. Set messaging do-not-disturb; set consent_basis = None; add sms-stop and do-not-contact and reactivation-excluded.
  2. Remove from every active workflow across the whole account, not just this campaign.
  3. Send one confirmation and nothing further: “Done. You won’t hear from us again. Sorry for the interruption.”
  4. Move the opportunity to Excluded, reason “opted out”.
  5. Log it permanently. No import, bulk edit, or future wave may ever clear this. Only an explicit new opt-in from the contact reverses it, and that writes a fresh consent_captured_at and consent_source.

WF-D8 · Wave Monitoring and Circuit Breaker

Trigger: Runs hourly during an active wave.

  1. Compute, for the current wave: delivery rate, reply rate, opt-out rate, negative-classification share, and complaint count.
  2. Circuit breaker: pause the entire wave automatically if any of these trips: opt-out rate above 2% of messages delivered; delivery rate below 90%; more than two complaints; negative replies exceeding 25% of all replies. Notify the owner with the numbers.
  3. A paused wave requires a human to review the copy, the segment, and the consent basis before it can resume. Do not simply restart it.
  4. Produce a daily wave summary: sent, delivered, replied, classified by sentiment, booked, opted out, and the same figures cumulatively for the wave.

This workflow is the reason this build is safe to run. Without it, a bad segment or a misjudged message keeps sending for three days before anyone notices, and by then the number and the domain are both damaged.

05

What changes

What is different afterwards

  • A written-off list becomes a measurable channel. You stop guessing whether the database is worth anything and get an actual reply rate, booking rate and cost per booked appointment for each segment: against an acquisition cost that is already sunk.
  • “Later” becomes a dated pipeline entry. The Not Now path converts vague deferral into a calendar date with a record attached, which is the quietly highest-yield part of the build over a six-month horizon.
  • Replies get answered in seconds, at volume. A 48-record batch producing a dozen replies in twenty minutes used to be unmanageable; classification and first response now happen without a human in the loop, with humans reserved for the conversations that need them.
  • Your list gets cleaner as a by-product. Wrong numbers, dead addresses, bad data and genuine refusals all get identified and marked, which improves everything else you ever send.
  • The downside risk is bounded. Throttling, the three-touch cap, the pilot batch and the circuit breaker mean the worst realistic outcome is a paused wave and a rewritten message, not a burned number, a blacklisted domain, or a regulatory complaint.

Metrics to watch

  • Reply rate per segment. The only number that tells you where the value actually is. Expect it to differ by several multiples between past customers and two-year-old inquiries, which is exactly why you never merge the segments.
  • Reply-to-booking conversion. If replies are strong and bookings are weak, the problem is the booking step or the calendar, not the campaign.
  • Sentiment mix: Interested / Not Now / Negative / Wrong Person / Unclear as shares of replies. A high Unclear share means the copy is ambiguous; a high Wrong Person share means the data is older than you thought.
  • Opt-out rate per 1,000 delivered, tracked per batch rather than per wave so you see a problem on batch two instead of batch eight. This is your primary safety metric.
  • Delivery and undelivered rates, watched per batch. A sudden drop means filtering has started and you should pause before the cap does it for you.
  • Complaint count: any complaint at all warrants reading the message again.
  • Cost per booked appointment for the wave, compared against your paid acquisition cost for the same outcome. This is the comparison that justifies running the next wave.
  • Show rate for reactivated bookings, versus bookings from fresh inbound. Reactivated leads reliably no-show more; if the gap is large, the reminder sequence needs strengthening rather than the campaign expanding.
  • Recontact-date conversion: of the Not Now records, the share that book when their date arrives. Measure this a quarter later; it is usually the best-performing cohort in the whole build.
  • Share of the database still untouched, so you know how much asset is left and do not accidentally re-run a wave over the same people.
06

Before you start

Prerequisites

  • An honest audit of consent, record by record. This is the gate for the entire build. For every record you intend to message, you need to know on what basis you may contact it, when that basis was established, and where it came from. If you cannot answer those three questions for a record, it does not go in the wave. A large list with no consent provenance is not an asset. It is a liability, and no copy or throttle makes it safe.
  • A reliable last_activity_at on every record. If this field is wrong, you will message active customers as though they had vanished, which is the most damaging error available here.
  • Deduplication and data cleaning before segmentation. Merge duplicates, validate number formats, and identify landlines: texting a landline wastes a send and flags your traffic.
  • A named sender. Messages go out as a real person at the business, and that person must exist and be prepared to be replied to.
  • Human capacity for the reply spike. Model it: a 50-record batch at a 15% reply rate is around eight conversations, several needing a person. If nobody is available between 10:00 and 17:00 on send days, reduce the batch size rather than hoping.
  • A decision that no price appears anywhere: not in the message, not on the landing page, not from the assistant. Pricing is scoped per build and belongs in the conversation the campaign exists to start.

Integrations and provisioning

  • Use an established number with sending history if you have one. A brand-new number sending its first-ever traffic as a reactivation wave is the worst possible start; warm it on transactional messaging for a couple of weeks first.
  • Run number lookup across the list to populate number_type and drop landlines and disconnected numbers before they cost you deliverability.
  • Authenticate the email domain (SPF, DKIM, DMARC) and seriously consider a subdomain for campaign mail so a problem cannot contaminate your transactional and appointment email.
  • Validate the email list for hard bounces and spam traps before the first send.
  • Branded link shortener for anything you do send a link to. Generic shorteners are heavily filtered by carriers.
  • Calendar with genuinely open availability, synced both ways, plus the reminder sequence already live, reactivated bookings no-show more, so the reminders matter more here than anywhere else.
  • Reporting set up before you send, not after. The circuit-breaker metrics must be visible on day one or the breaker cannot work.

Consent, registration and the compliance floor

  • A2P 10DLC brand and campaign registration must be complete before a single message sends. Register the campaign honestly. If it is marketing or promotional in nature, register it as that, not as customer care. Submit sample messages that match what WF-D2 actually sends. A mismatched registration gets throttled or shut down mid-wave.
  • Prior express written consent is the standard for promotional messaging in many jurisdictions, and age is not a substitute for it. A record from three years ago with a ticked marketing box is defensible; a record with no documented consent is not, no matter how warm it feels. When in doubt, use the email track and the re-opt-in page to rebuild consent properly rather than assuming it.
  • Check whether your jurisdiction imposes a time limit on the existing-relationship basis. Several do, and a two-year-old customer may be outside it. This genuinely varies: confirm it rather than assuming your list is fair game.
  • Screen against do-not-call registries where they apply to your messaging and your industry.
  • Quiet hours: 10:00–17:00 local, weekdays only, for the first wave. This is far tighter than the legal minimum, deliberately. A reactivation message at 8pm on a Saturday generates complaints that a 10am Tuesday message does not.
  • Identify yourself in the first message: the business name and a real person. Never send an anonymous or ambiguous first touch.
  • Include opt-out instructions on the first message of each wave, and honor every opt-out mechanically and account-wide. Make “how did you get my number” behave as an opt-out.
  • Keep the audit trail. For every message sent, you should be able to show who, when, on what consent basis, captured where and when. If a complaint arrives, that record is your entire defense.
  • Do not buy, rent, scrape, or import a third-party list into this build. It is a different activity with a different legal character, and it will destroy the sending assets this build depends on.

Where regulated data is involved

  • In healthcare or any setting handling protected health information, a signed business associate agreement must cover the platform before any patient data enters it, and marketing to patients carries its own authorization requirements that are stricter than general marketing rules. In many cases a past treatment relationship alone does not permit promotional contact.
  • Never reference a condition, treatment, medication, result, or department in a reactivation message. “You came to us for {{previous_service}}” is safe only when the service name itself discloses nothing clinical. If it does, use the general variant, or do not message that segment at all. The message may be read by someone other than the recipient, and the disclosure is the harm.
  • Do not build segments from clinical criteria (diagnosis, medication, test result, or treatment type) for a promotional campaign. Segment on recency and service category only.
  • Keep the AI assistant away from all clinical content. Any symptom, result or treatment question ends the automated thread and routes to a clinician or a person.
  • Restrict access to the wave lists and reply content by role, log access, and set a defensible retention period for campaign data.
  • None of this is legal advice. Given that this build messages people who have not contacted you recently, have your own counsel review the consent basis, the segment definitions, and the message copy before the first wave sends. This is the one build where that review is genuinely load-bearing.

Build it with us.

Every build on this page is something we configure, test and hand over with the SOPs your team needs to run it.

Book a call