Referral Engine

Almost every owner will tell you that referrals are their best source of business. Almost none of them can tell you how many they got last month, who sent them, or what happened to the ones that came in. The referral channel is simultaneously the most valuable and the least managed thing in the business. Run entirely on goodwill, remembered in fragments, and credited to nobody. When it is working, nobody knows why. When it stops, nobody notices for a quarter.

The specific failure is a timing failure compounded by an attribution failure. Referral willingness is not a constant property of a customer; it is a spike. It peaks in the hours after a problem is solved, a result is delivered, or a job is finished well, and then it decays, quickly, back to indifference. Almost nobody asks inside that window, because asking inside that window means asking every single customer within hours of completion, including the ones who finished late on a Friday, and no human does that reliably. So the ask either never happens, or it happens weeks later in a newsletter where it reads as filler. Then, when a referral does arrive, the new person calls in and says "my neighbor recommended you" and the neighbor's name is never recorded against the record. The advocate is never thanked, never told what happened, and never asked again, which is how a customer who would happily have sent five people sends exactly one.

The money leaks quietly and in large amounts. Referred customers typically arrive with trust already established and need less convincing, which means the channel has the cheapest acquisition cost in the business and the least effort behind it. Meanwhile paid channels get budget, dashboards and weekly meetings, and are measured against a cost per lead that a referral program would beat without trying. The second leak is the unclosed loop: an advocate who sends someone and hears nothing back learns that referring is a dead end, and that silence costs you every referral they would have made afterwards. The fix is not an incentive scheme. It is a system that asks at the peak, makes sharing take one tap, records who sent whom as structured data, contacts the referred person in a way that is actually permissible, and tells the advocate what happened.

Pipelines and stages

Two pipelines, because an advocate and a referred lead are different objects with different clocks. Trying to run both in one pipeline is the most common reason referral builds collapse after a month.

Pipeline 1: Advocates

1. Eligible: a happy customer who meets the eligibility rules. Nothing sent yet.
2. Asked: the referral ask has gone out.
3. Enrolled: they engaged: opened the toolkit, copied their link, or said yes.
4. Active Advocate: has submitted at least one referral.
5. Repeat Advocate: two or more referrals. This group is small and matters enormously.
6. Reward Due: a referral converted and the thank-you has not been fulfilled.
7. Dormant: enrolled but nothing for 120 days. Re-ask candidate.
8. Declined: asked not to be asked. Terminal and permanently respected.

Pipeline 2: Referred Leads

1. Referral Submitted: a name exists. Entry point.
2. Awaiting Permission: the referred person has not yet contacted you or opted in. The stage that keeps this build legal.
3. Contact Made: a two-way conversation has started.
4. Qualified: they want what you do.
5. Booked: an appointment or job exists.
6. Converted: they bought. Triggers the reward and the loop-close.
7. Not Now: real but not yet. Goes to nurture, stays attributed.
8. Not Interested: closed, with the advocate thanked anyway.

Calendars

• Referred-lead booking calendar: the standard consultation or service calendar, but with its own link so bookings arriving through a referral link are attributable without anyone typing anything.
• Advocate thank-you calls: a short, optional calendar the owner uses for repeat advocates. A five-minute call to a person who has sent three customers is the highest-return meeting in the business.
• Partner review slots: for the professional-referrer track in WF-F9, a quarterly check-in calendar.

Custom fields: advocate side

• satisfaction_score (number, 1–10 or 1–5) and satisfaction_captured_at (date/time). The gate. Never ask an unhappy customer for a referral.
• service_completed_at (date/time). The clock the ask runs on.
• service_type (dropdown) and staff_member (text), so the ask can be specific and the credit can be shared.
• advocate_status (dropdown: Not asked, Asked, Enrolled, Active, Repeat, Dormant, Declined).
• referral_ask_count (number): hard cap of 3 per 12 months.
• last_referral_ask_at (date/time): enforces a 90-day minimum gap.
• referral_link_code (text). The advocate's unique code, generated once and never changed.
• referrals_submitted_count, referrals_booked_count, referrals_converted_count (number).
• first_referral_at and last_referral_at (date/time).
• reward_type (dropdown: Account credit, Gift, Charitable donation, Service upgrade, Thank-you only, Not eligible) and reward_status (dropdown: None due, Due, Approved, Fulfilled, Declined by advocate).
• reward_approved_by (user) and reward_fulfilled_at (date/time).
• advocate_tier (dropdown: Standard, Repeat, Partner): drives cadence and treatment, not reward size.
• suppress_referral_asks (checkbox). The override that beats every other rule.

Custom fields: referred-lead side

• referred_by_contact (contact reference or text holding the advocate's record id). The single most important field in the build. Without it there is no program, only hope.
• referred_by_name (text). The human-readable version, used in copy.
• referral_channel (dropdown: Advocate link, Advocate forwarded message, Named by referred person, Submitted by advocate, Partner, QR code in branch, Unknown).
• referral_submitted_at, referral_first_contact_at, referral_booked_at, referral_converted_at (date/time). The four timestamps the whole report runs on.
• referral_consent_basis (dropdown: Self-initiated contact, Opted in on landing page, Advocate-submitted (no consent, Partner with documented consent)) decides which channel may be used, and whether any outbound is permitted at all.
• referral_relationship (text): "neighbor", "sister", "works with me". One line that makes the first conversation ten times warmer.
• referral_outcome_notified_at (date/time): proof the loop was closed with the advocate.

Tags

advocate-eligible, advocate-asked, advocate-enrolled, advocate-active, advocate-repeat, advocate-dormant, advocate-declined, referral-in, referral-awaiting-permission, referral-contacted, referral-converted, reward-due, reward-fulfilled, partner-referrer, referral-ask-cap-hit.

Forms, surveys and pages

• One-tap satisfaction question: a single scored question sent after service completion. It does double duty: it gates the referral ask and feeds the review program.
• Advocate toolkit page: the advocate's personal page, reached from the ask. It holds their unique link, a prewritten message they can edit, one-tap share buttons for the channels they actually use, and a short "submit a name" form. Nothing else. Every extra element on this page costs you referrals.
• Prewritten share message: written in the customer's voice, not the brand's: "I used {{business_name}} for {{service_type}} and they were genuinely good. If you need the same thing, here's the link. They'll look after you: {{referral_link}}". Editable, because a message nobody edits is a message nobody sends.
• Referred-lead landing page: the page the referral link opens. It names the advocate: "{{referred_by_name}} thought we could help." It has one form, one booking button, and an explicit opt-in checkbox for contact. That checkbox is what converts an advocate-submitted name into a lead you are permitted to message.
• Advocate-submits-a-name form: name, contact detail, relationship, and a mandatory tick confirming the advocate has the person's permission to pass on their details. This tick is recorded with a timestamp.
• Partner referral form: for professional referrers: client name, reason, urgency, and a documented-consent confirmation.

BO's role and guardrails

• BO handles the inbound side: advocates replying "who do I send it to", referred people arriving in chat saying "my friend told me to call you", and the follow-up conversation that turns a name into a booking.
• When a referred person makes contact, BO's first job is to identify the referrer: "lovely, who sent you? I'll make sure they know", and write referred_by_name and referral_channel. A referral that arrives unattributed is a referral you cannot repeat.
• BO then qualifies lightly and books. It does not sell, discount, or compare.
• Guardrails. BO never discusses reward amounts, eligibility edge cases or payouts: those go to a human. BO never contacts a name whose referral_consent_basis is "Advocate-submitted. No consent"; that record is visible to BO only as read-only context. BO never implies the advocate shared anything private about the referred person. BO never reveals one customer's details to another.
• Escalation: any question about rewards, any complaint, any advocate asking to be removed, any request for a person. Hand off with the thread and create a task due in four hours.

Numbers and channels

• The existing business number for advocate asks, so the message lands in an existing thread from a name they recognize.
• Email for the toolkit, the progress updates and anything containing a policy explanation.
• Advocate share channels: the share buttons target WhatsApp, SMS, email and the clipboard. The advocate messages their own contact from their own device, which is both far more effective and the cleanest possible consent position.
• Trackable short links on a branded domain, one per advocate, so a click is attributed before any form is filled.
• QR codes carrying the same advocate codes for businesses with a physical counter or a van.
• Internal channel: Slack or Teams alert on every new referral, because a referred lead deserves a faster human response than a cold one.

One advocate and one referral, end to end

1. Friday, 4:10pm. A job is marked complete. service_completed_at is stamped, service_type and staff_member are written, and the contact enters the Advocates pipeline at Eligible: subject to the gate in step 3.
2. 5:10pm. One hour after completion, the one-tap satisfaction question goes out by text. He taps 9.
3. 5:10pm. The gate. A score of 9 clears the threshold, so the referral path unlocks. Had he scored 6 or below, no referral ask would ever have been sent; he would have gone to the service-recovery branch instead, and been excluded from referral asks for 90 days.
4. 5:14pm. Four minutes after the score, the ask arrives. Short, specific to the job, and asking for one person rather than "anyone you know". referral_ask_count becomes 1, last_referral_ask_at is stamped, the record moves to Asked.
5. 5:16pm. He taps through to the toolkit page. His referral_link_code is generated, his personal link appears, and the prewritten message is sitting there ready to edit. The record moves to Enrolled.
6. 5:18pm. He taps the WhatsApp share button, edits the message to add a sentence of his own, and sends it to his neighbor. Nothing has been sent by the business to the neighbor, which is exactly the point.
7. Saturday, 9:40am. The neighbor taps the link. The landing page opens with "Dave thought we could help." The click is attributed to Dave's code before she types a thing.
8. 9:43am. She fills the short form and ticks the contact opt-in. A record is created in Referred Leads at Referral Submitted, with referred_by_contact set to Dave, referral_channel = Advocate link, and referral_consent_basis = Opted in on landing page, which means outbound contact is permitted. Because she self-submitted, she skips Awaiting Permission entirely.
9. 9:44am. Two messages go out in parallel. To her: a warm acknowledgement naming Dave, with two booking times in the text. To the internal channel: a referral alert with Dave's name, her detail, and a 15-minute response target: referred leads get answered faster than cold ones, deliberately.
10. 9:51am. She replies with a time. BO confirms it against live availability and books. referral_booked_at is stamped; the record moves to Booked.
11. 9:52am. The loop closes for the first time. Dave gets a message: "Your neighbor just booked in: thank you, genuinely. We'll look after her." This message is the most important item in the build, because it is what produces a second referral.
12. Tuesday. She attends, buys, and referral_converted_at is stamped. Her record moves to Converted. Dave's referrals_converted_count becomes 1 and his record moves to Reward Due.
13. Tuesday, same day. The reward task is created and assigned for human approval. A person approves it (the system never fulfills a reward unapproved) and reward_status moves to Approved, then Fulfilled, with reward_fulfilled_at stamped.
14. Wednesday. Dave gets the thank-you, delivered as a thank-you rather than a transaction, and one gentle line: "If anyone else comes to mind, your link still works: {{referral_link}}". No new ask, no countdown, no pressure. referral_outcome_notified_at is stamped on the referred record.
15. Three weeks later. Dave sends a second person. His advocate_tier moves to Repeat, which changes nothing about his reward and everything about his treatment: he comes off the automated ask cadence entirely and onto the owner's short list for a personal call.
16. 120 days later, in the alternative ending. Had Dave enrolled and never shared, a single re-ask would have gone out at day 120, framed around a new service rather than repeating the first message, and if that produced nothing he would move to Dormant and be left alone until the annual review.

WF-F1 · Advocate Eligibility and the Satisfaction Gate

Why this exists: the fastest way to destroy a referral program is to ask the wrong people. One referral ask sent to a customer with an unresolved complaint costs more goodwill than ten successful asks earn. This workflow decides who is allowed to be asked, and it is the only route into the program.

Trigger: service completion event. Appointment marked complete, invoice marked paid, or opportunity moved to a closing stage. Pick exactly one and use it everywhere, or customers will be asked twice.

Entry conditions (all must be true):

• suppress_referral_asks = false and no advocate-declined tag.
• referral_ask_count is less than 3.
• last_referral_ask_at is empty or more than 90 days ago.
• No open complaint, dispute, unpaid overdue invoice, or recovery-open tag.
• A consented channel exists.
• This is not a first-ever appointment that has yet to be delivered. Ask after value, never before.

Actions, in order:

1. Stamp service_completed_at; write service_type and staff_member from the job record.
2. Wait 1 hour. Long enough that the service is genuinely finished, short enough that the feeling is intact.
3. Branch on quiet hours: outside 09:00–19:00 local, hold until 09:00 next day.
4. Send the one-tap satisfaction question: "Hi {{first_name}}, quick one: how did we do today, 0 to 10? {{score_link}}" Capture on tap.
5. Wait up to 48 hours for a response, with one reminder at 24 hours.
6. Branch on satisfaction_score:
   • 9–10 → add advocate-eligible, move to Eligible, continue to WF-F2 immediately.
   • 7–8 → eligible, but wait 7 days before asking and use the softer copy variant. These customers refer, just less readily, and a hard ask puts them off.
   • 0–6 → no referral ask, now or for 90 days. Set suppress_referral_asks = true, route to service recovery, and create a task for a human. Re-eligibility is a human decision, recorded in a note.
   • No response → eligible at the lower tier only if there is other positive evidence. A repeat purchase, a long tenure, a public review. Silence is not satisfaction.

Exit conditions: score below threshold; cap reached; opt-out; suppress_referral_asks set; open complaint detected at any point.

WF-F2 · The Ask, Timed to the Peak

Trigger: tag advocate-eligible added.

Conditions: all WF-F1 gates still true at send time. Re-check them, because a complaint can arrive in the intervening hour.

Actions, in order:

1. Wait 4 minutes after the score. Not an hour. Not the next day. The ask should feel like part of the same conversation as the compliment they just gave you.
2. Send the primary ask by SMS: "That's really good to hear, {{first_name}}, thank you. Can I ask one favor? Most of our work comes from people like you telling someone else. Is there one person who might need {{service_type}} right now? Here's a link you can send them, and a message you can use if it's easier: {{toolkit_link}}"
3. The copy rules that do the work. Ask for one person, not "anyone you know". A specific small request converts several times better than a vague large one. Name the service they actually had. Say why it matters to the business. Give them the words so they do not have to compose anything. Keep it under 320 characters.
4. Email variant for contacts without SMS consent. Subject "One favor, if you don't mind", four lines, the toolkit button, and the prewritten message visible in the body so it can be copied without clicking anything.
5. Increment referral_ask_count; stamp last_referral_ask_at; add advocate-asked; move to Asked.
6. Wait 3 days. Condition: toolkit not opened and no referral submitted. Send one nudge, and make it easier rather than louder: "No pressure at all {{first_name}}, if it's useful, here's the link again. Even one name helps more than you'd think: {{toolkit_link}}"
7. Wait 7 days. Condition: still nothing. Stop. Do not send a third message in this cycle. The next contact is the 120-day re-ask in WF-F8.
8. If they reply with words rather than tapping ("sure, who do I send it to", "my brother might") hand the thread to BO, which is the highest-converting path in the whole build.

Exit conditions: toolkit opened; referral submitted; any reply; opt-out; cap reached; two nudges sent.

WF-F3 · Enrollment and the Share Toolkit

Trigger: advocate toolkit page opened, or referral_link_code first generated.

Actions:

1. Generate referral_link_code if empty: short, human-readable, permanent. Never regenerate it; links live in people's message history for years.
2. Add advocate-enrolled; move to Enrolled; cancel the remaining nudges in WF-F2.
3. Wait 10 minutes. Condition: no share action and no submission. Send one message containing the link as text in the message body, not behind a button: "Here's your link if you'd rather just copy it: {{referral_link}}". A surprising share of advocates want to paste it into their own app rather than use a share button.
4. Wait 2 days. Condition: link opened but no click-throughs recorded on it. Send the single most useful nudge in the build: "If it helps, here's a message you can just forward: '{{prewritten_message}}'". The full text, ready to copy. The barrier is almost never willingness; it is composition.
5. Record every share action by channel so you learn which channel this audience actually uses, then reorder the buttons to match.
6. Wait 14 days. No referral activity → exit to WF-F8's dormancy watch.

Exit: referral submitted; link click recorded; opt-out.

WF-F4 · Referral Capture and Attribution

Why it matters more than the ask: an unattributed referral is indistinguishable from an inbound lead. Every path into the business has to be able to answer "who sent you", and the answer has to land in a field rather than a note.

Triggers (four separate paths, one shared outcome):

• Path A: Advocate link clicked and landing-page form submitted. Cleanest. The code carries the attribution automatically.
• Path B: Advocate submits a name on the toolkit form, with the permission tick.
• Path C: Referred person contacts you directly by phone, chat or form and names the referrer. BO or the receptionist asks the question.
• Path D: Partner or professional referrer submits through the partner form.

Actions, in order:

1. Create or match the referred contact. Deduplicate hard: if this person is already an existing customer or an open lead created before the referral, do not attribute. Log it as "already known" and tell the advocate honestly. Paying out on a lead you already had is how referral programs lose the owner's trust.
2. Write referred_by_contact, referred_by_name, referral_channel, referral_relationship and referral_submitted_at.
3. Set referral_consent_basis by path: this is the branch that keeps the build lawful:
   • Path A → Opted in on landing page. Outbound SMS and email permitted, within the consent captured.
   • Path B → Advocate-submitted: no consent. Move to Awaiting Permission. No automated outbound of any kind. Continue to WF-F5.
   • Path C → Self-initiated contact. Reply in the channel they used; capture consent for anything further.
   • Path D → Partner with documented consent, only where the partner has confirmed in writing that the person agreed to the introduction.
4. Increment the advocate's referrals_submitted_count; set first_referral_at if empty; stamp last_referral_at; move the advocate to Active Advocate, or Repeat Advocate at two or more.
5. Post to the internal channel: "Referral in: {{referred_name}} from {{referred_by_name}} ({{referral_relationship}}). Consent basis: {{referral_consent_basis}}. Respond within 15 minutes."
6. Create a task for the owner of referred leads, due in 15 minutes during business hours.
7. Send the advocate an immediate acknowledgement: on every path, including the ones that cannot be contacted: "Got it, {{first_name}}, thank you. I'll let you know how it goes." Then actually do that in WF-F6.

Exit: referred record created and attributed, or logged as duplicate and the advocate told.

WF-F5 · Referred-Lead Intake Without Consent (the permission path)

Why this workflow is non-negotiable: when an advocate hands over a friend's number, the friend has given you nothing. Texting them is unsolicited marketing to a person who never asked, it reads as a privacy breach to the recipient, and it is the fastest way to turn a goodwill program into a complaint. This workflow gets permission before it gets a lead.

Trigger: referred record enters Awaiting Permission.

Actions: and note what is absent:

1. No message is sent to the referred person. Not one. Every action in this workflow is directed at the advocate or at a human on your team.
2. Send the advocate the forwardable introduction: "Thanks for passing on {{referred_first_name}}'s details, {{first_name}}. Rather than cold-calling them, could you send them this? It's quicker and it'll come from someone they trust: '{{prewritten_message}}', or if you'd rather we reached out directly, just reply OK and confirm they're happy to hear from us."
3. Branch on the advocate's reply. If the advocate confirms the referred person is expecting contact, set referral_consent_basis = Advocate-confirmed permission, record the reply verbatim with its timestamp, and permit one personal outreach attempt. A phone call from a named human, not an automated sequence, and not SMS marketing. Whether that is sufficient under the rules in force is a question for the client's own counsel, and the answer differs by jurisdiction and by channel.
4. If the referred person clicks the forwarded link and opts in, they re-enter at Path A with a proper consent basis and the normal sequence runs.
5. Wait 7 days. No permission and no self-initiated contact → move to Not Now, keep the attribution, send nothing, and tell the advocate plainly: "I didn't want to contact {{referred_first_name}} out of the blue. If they'd like to reach us, your link is here whenever they're ready."
6. Never pass the referred person's details to another advocate, add them to a broadcast list, or include them in any campaign audience while they sit in Awaiting Permission. Exclude this stage explicitly from every bulk send in the account.

Exit: consent obtained; self-initiated contact made; 7 days elapsed.

WF-F6 · The Advocate Progress Loop

Why it is the most under-built workflow in referral programs: advocates refer again because they learn that referring produced something. Silence teaches the opposite, and it teaches it permanently. Three short messages here are worth more than any reward.

Trigger: any stage change on a referred record that has a referred_by_contact.

Actions, by referred-lead stage:

1. Contact Made → within 1 hour, message the advocate: "Just spoke to {{referred_first_name}}, thanks again for the introduction."
2. Booked → immediately: "{{referred_first_name}} is booked in for {{appointment_day}}. Genuinely appreciated, {{first_name}}."
3. Converted → immediately, and continue to WF-F7: "{{referred_first_name}} is all sorted and happy. That's the second time you've sent someone our way: thank you."
4. Not Interested or Not Now → wait 2 days (do not deliver bad news instantly) then: "We spoke to {{referred_first_name}}; it's not the right time for them. Thanks for thinking of us anyway, {{first_name}}, it still means a lot." Thank the advocate for the act, never for the outcome. An advocate who feels judged on conversion stops referring.
5. Stamp referral_outcome_notified_at on every path, so loop closure is auditable and a gap in it is visible in reporting.
6. Privacy limit on every message: name the person and the stage, nothing else. Never share what the referred person bought, what they paid, what they discussed, or anything they disclosed. If the referred person has asked that the referral not be acknowledged, suppress this entire workflow for that record: build that flag.

Exit: referred record reaches a terminal stage and the advocate has been told.

WF-F7 · Reward Trigger, Approval and Fulfillment

Trigger: referred record moves to Converted.

Conditions: attribution is clean and not a duplicate; the referred person is past any cooling-off or refund window; the advocate holds no reward-ineligible flag; the reward is permissible for this advocate: see the constraint below.

Actions, in order:

1. Increment referrals_converted_count; set reward_status = Due; move the advocate to Reward Due; add reward-due.
2. Create a human approval task. No reward is ever fulfilled automatically. The approver checks the attribution, the duplicate test and the eligibility rule, then approves or declines with a reason. Record reward_approved_by.
3. Wait for approval. On approval: fulfill according to reward_type: apply account credit, issue the gift, trigger the donation, or activate the upgrade, then stamp reward_fulfilled_at, set reward_status = Fulfilled, add reward-fulfilled.
4. Send the thank-you, and write it as a thank-you rather than a receipt: "{{first_name}}, {{referred_first_name}} is sorted and delighted. Your {{reward_type}} is on its way, but honestly, the recommendation mattered more. Thank you."
5. Wait 3 days. Send one light line that keeps the door open without asking again: "Your link's always live if anyone else comes to mind: {{referral_link}}". Then stop.
6. On decline: notify the approver's note to nobody but the internal channel, and still send the advocate a genuine thank-you. Never tell an advocate they are being refused a reward through an automation.
7. At 2 and 5 cumulative referrals: set advocate_tier and create a task for the owner to make personal contact. Remove repeat advocates from the automated ask cadence entirely. They have earned a human.

Constraints you must settle before building this workflow:

• Reward structure, value and form are commercial decisions for the business, and in several sectors they are regulated or prohibited. Paying for patient or client referrals is unlawful in parts of healthcare and restricted in finance, law and insurance in many jurisdictions. Confirm with the client's own counsel what may be offered, to whom, and with what disclosure: before a single reward is configured. Where cash-equivalent rewards are not permissible, the build still works: a thank-you, a named mention with permission, or a charitable donation path carries most of the effect.
• Never make the reward the headline of the ask. An ask led by a reward converts worse and attracts the wrong referrals.
• Never reward the referred person for being referred without checking the same rules apply to them.
• Disclose the arrangement where disclosure is required, in the advocate's share message itself.

Exit: reward fulfilled, declined, or the advocate opts out of rewards.

WF-F8 · Dormancy, Re-Ask and Natural Moments

Trigger: scheduled daily sweep, plus event-based entry on the natural moments listed below.

Conditions for any re-ask: referral_ask_count under 3; last_referral_ask_at more than 90 days ago; satisfaction still at or above threshold with no complaint since; not advocate-declined; suppress_referral_asks false.

Actions:

1. Dormancy sweep. Advocates enrolled with no referral activity for 120 days → move to Dormant, one re-ask built around something new rather than a repeat of the first message: "{{first_name}}, we've started doing {{new_service}}, if anyone you know needs it, your link still works: {{referral_link}}". No response in 14 days → leave alone for a year.
2. Natural moment: repeat purchase or return visit. Re-ask 1 hour after the second completion, where the gates allow. A returning customer is a stronger advocate than a first-timer.
3. Natural moment: public review posted. Somebody who just wrote a five-star review in public has demonstrated willingness. Wait 2 days, then ask once, referencing the review with thanks: never as leverage.
4. Natural moment: milestone. One year as a customer, a course completed, a contract renewed. One ask, tied to the milestone.
5. Natural moment: unprompted praise. BO detects a clear compliment in an inbound message, creates a task rather than sending anything, and a human decides whether to ask in that conversation. This is the highest-converting ask in the build and it should stay human.
6. The cap is absolute. Three asks per rolling 12 months across every path in this workflow, enforced by referral_ask_count, not by step counting in any single workflow. On the third, add referral-ask-cap-hit and exclude the contact from all referral asks for a year.

Exit: cap hit; declined; opted out; dormant for a year.

WF-F9 · Partner and Professional Referrer Track

Why it is separate: a neighbor who sends one person and a professional who sends four a month need completely different handling. Running a partner through the consumer ask sequence insults them; running a consumer through the partner process confuses them.

Trigger: contact tagged partner-referrer, or a submission through the partner form.

Actions:

1. Set advocate_tier = Partner. Exclude from WF-F2 and WF-F8 entirely: partners are never put on an automated ask cadence.
2. Issue a named partner link and a co-branded landing page carrying their name, so their client sees continuity rather than a handoff.
3. On each submission: acknowledge within 15 minutes, confirm receipt to the partner by their preferred channel, and create a task with a response SLA that is shorter than for any other lead source in the account.
4. Close the loop at every stage, in the partner's language: contacted, booked, outcome. A professional referrer's reputation is attached to the introduction, which makes feedback a professional courtesy rather than a nicety.
5. Monthly: send a volume and outcome summary. Counts and stages only, never clinical, financial or personal detail about the people referred.
6. Quarterly: create a task for the owner to book a partner review slot. Partner relationships decay on a quarterly clock, not an annual one.
7. Document the consent position once, in writing, covering what the partner may share, on what basis, and what the business may do with it. For regulated referrers this is a formal matter and belongs with counsel, not in a workflow description.

Exit: partnership ends, or the partner asks to stop.

WF-F10 · Weekly Referral Reporting and Attribution Hygiene

Trigger: scheduled, Monday 08:00.

Actions:

1. Email the owner one digest: asks sent, enrollment rate, referrals submitted by channel, referrals converted, loop-closure coverage, rewards due and unfulfilled, and the current list of repeat advocates.
2. Hygiene sweep: flag every referred record with no referred_by_contact, every referred record whose referral_outcome_notified_at is empty more than 48 hours after a stage change, and every reward sitting at Due for more than 5 days. These three leaks account for most referral program decay.
3. Flag any advocate whose referrals consistently fail to qualify, not to penalize them, but because it usually means the ask copy is attracting the wrong audience.
4. Flag any referred record that has sat in Awaiting Permission for more than 7 days, so it is closed properly rather than quietly contacted by someone who did not know the rule.

Exit: runs indefinitely.

What is different afterwards

• Every happy customer gets asked, once, at the right moment. The ask stops depending on whether anyone remembered. Referral volume becomes a function of how many customers you serve well rather than how motivated the owner felt that week.
• Unhappy customers never get asked. The satisfaction gate is as valuable as the ask itself. It is what makes the program safe to run at full volume.
• Sharing takes one tap and no composition. The prewritten message removes the real barrier, which was never willingness; it was not knowing what to say.
• Who sent whom becomes structured data. referred_by_contact turns "we get a lot of word of mouth" into a channel with a volume, a conversion rate and a named top-ten list you can actually act on.
• The loop closes. Advocates hear what happened to the person they sent, at every stage, including when the answer is no. This single habit is what produces second and third referrals.
• Referred leads get answered faster than anyone else. A 15-minute SLA on a warm introduction is both commercially obvious and the thing most businesses fail to do, because referrals arrive through informal channels nobody monitors.
• Nobody is pestered. Three asks per year, a 90-day gap, a hard cap enforced in a field, and a permanent decline flag. The program is aggressive about timing and conservative about frequency.
• Referred names are handled lawfully. The Awaiting Permission stage means a passed-on phone number does not become a cold text, which protects the advocate's relationship as much as your compliance position.

Metrics to watch

• Ask coverage: of eligible completed services, the share that produced a referral ask. This should be near total; anything less means the completion event is unreliable.
• Gate rejection rate: the share of customers excluded by satisfaction score. Watch the trend, not the level; a rising rate is a service problem the referral program is correctly refusing to paper over.
• Ask-to-enrollment rate: of asks, the share that open the toolkit. Driven by copy and timing. Test the timing first.
• Enrollment-to-share rate: of advocates who opened the toolkit, the share that actually sent something. If this is weak, the prewritten message is the thing to fix, not the reward.
• Referrals per active advocate, and the distribution. The shape matters: a program carried by five repeat advocates is fragile, however good the total looks.
• Referral-to-booked and booked-to-converted rates, compared against the same rates for cold leads. Referred leads should outperform noticeably; if they do not, your response time or your handling is wasting the warm start.
• Median time from referral_submitted_at to referral_first_contact_at. Target under 15 minutes in hours. This is the metric that most directly determines whether a referral converts.
• Loop-closure coverage: the share of referred records where referral_outcome_notified_at is populated. Treat anything short of total as a defect; it is the leading indicator of next quarter's referral volume.
• Attribution coverage: the share of new customers with any recorded source, and specifically the share of word-of-mouth arrivals with a named referred_by_contact.
• Reward cycle time: from Due to Fulfilled. A reward that takes three weeks to arrive teaches the advocate the program is not real.
• Repeat advocate count: contacts with two or more referrals. The single best health measure of the program, because it is the only one that cannot be faked by asking more people.
• Opt-out and decline rate on referral asks. If this climbs, the cap or the tone has drifted: check the copy before touching the cadence.
• Share of referred leads rejected as duplicates. High numbers mean the ask is reaching advocates whose network you have already sold to, which is a segmentation signal rather than a failure.

Prerequisites

• A reliable service-completion event. The ask hangs off knowing that value was delivered. Pick one event (appointment completed, invoice paid, or pipeline stage) and use only that one everywhere.
• A satisfaction measure you trust. If no scored question is in place today, build that first. An ungated referral program will eventually ask a furious customer for a favor.
• A decision on rewards, taken before building. What is offered, to whom, in what form, and whether it is permissible at all in this sector. If that decision cannot be made yet, launch the program on thanks and loop-closure alone. It works, and it can be upgraded later.
• A named owner for referred leads, with a response SLA shorter than for any other source. A referral answered in two days is worse than no referral, because it also costs you the advocate.
• An approver for rewards: one named person who checks attribution before anything is fulfilled.
• Deduplicated contacts. Attribution and duplicate detection both fail on a messy database, and the failure mode is paying for leads you already had.
• Agreed wording for the share message, written in a customer's voice rather than the brand's, and approved by the owner. This one paragraph does more work than any other asset in the build.

Integrations and provisioning

• Branded short-link domain, with one unique code per advocate. Generic shorteners get filtered by carriers and look untrustworthy in a forwarded message, which is exactly the context these links live in.
• The existing business number for advocate messaging, so asks arrive in a thread the customer recognizes.
• Authenticated email sending domain (SPF, DKIM, DMARC) before the first send.
• Calendar sync (Google Calendar, Microsoft 365 or Outlook) so referred leads can be booked immediately rather than put in a queue.
• Slack or Microsoft Teams for the new-referral alert. This is the one notification the team should never miss.
• Payments or store integration (Stripe, Square, Shopify, WooCommerce) only if rewards are delivered as credit or product, and only after the reward decision is settled.
• Accounting sync (QuickBooks or Xero) where rewards have a financial value that must appear in the books.
• QR assets carrying advocate codes for counters, vans, invoices and receipts, if the business has a physical touchpoint.
• Ad platform conversion import (Google Ads, Meta Ads) so referrals are visible as a distinct source and do not get silently credited to paid media.

SMS registration, consent and timing

• Complete A2P 10DLC brand and campaign registration before sending. Register the advocate-facing traffic honestly. A referral ask is marketing, not a transactional notification, and registering it as the latter is both inaccurate and a filtering risk. Submit samples matching what WF-F2 actually sends.
• Consent must predate the ask. Having bought from you is not consent to be texted a marketing request. Capture SMS consent at intake or booking with an unticked box naming the business, the message types, variable frequency, that rates may apply, and how to stop, and store the timestamp, source and exact wording.
• Never message a referred person on the strength of the advocate's word alone. This is the single most important rule in the build. An advocate-submitted name has no consent basis, so it goes to Awaiting Permission and receives nothing automated. Permission comes from the referred person, through the link, or not at all.
• Exclude Awaiting Permission from every bulk audience in the account, explicitly, and re-check that exclusion whenever a new campaign is built.
• Quiet hours: hold advocate messaging to 09:00–19:00 local. Keep referred-lead responses inside business hours too. A fast reply at 11pm reads as surveillance rather than service.
• Honor STOP mechanically and make an opt-out set suppress_referral_asks as well as stopping messages, so the person leaves this program rather than just this channel.
• Enforce the three-ask cap in the field, not in step counts, so natural-moment triggers cannot stack with the dormancy re-ask.

Data protection and sector rules

• Passing on a third party's contact details is a data-protection event. Decide and document your lawful basis for holding a referred person's details before you hold any, record the permission tick with its timestamp, and be able to delete the record on request, including on request from the referred person, who never dealt with you directly.
• Tell the referred person who referred them at first contact. Concealing it is both ineffective and the thing that generates complaints.
• Share nothing back to the advocate but name and stage. Never what was bought, discussed, paid or disclosed. Build a suppression flag for referred people who ask that the referral not be acknowledged.
• In healthcare, financial services, law and insurance, referral rewards are frequently restricted or prohibited. Paying for patient referrals is unlawful in parts of healthcare; disclosure obligations apply in others. Where protected health information is involved, get a signed business associate agreement in place covering the platform before real data enters it, keep referral messaging clinically silent, and never reveal that a referred person is a patient or client, including to the person who referred them.
• Disclose material connections in the advocate's share message where consumer-protection rules require it. The disclosure belongs in the message the advocate sends, not buried in a page.
• Set a retention period for referred records that never converted, and apply it automatically.
• None of the above is legal advice. Have the client's own counsel review the reward structure, the consent language, the referred-lead handling and any sector-specific referral and disclosure rules before launch.

Reward structure and scope are decided per account rather than off a price list. Book a call at bookings.appbo.io to work through what is permissible in your sector and what to launch first.