Non-profits · Playbook
The non-profit playbook. Built in the builder, decided by your donor system.
Ten journeys, each drawn below as it runs. The decision comes from your donor CRM, your payment gateway, your programme system or criteria you set; the journey carries it. Aims are targets to agree in the pilot, not results.
PLAYBOOKS · 01Illustrative journey
Ask for the monthly gift after the third one-off.
A third one-off gift in twelve months asks your donor system whether the donor is already monthly, then sends one WhatsApp with Make it monthly or Not now; a tap goes to your payment system to set it up.
- Decides
- your donor system and the count you set.
- Aim
- monthly givers without a phone campaign.
Built in the journey builder
Ask for the monthly gift after the third one-offNON-PROFITSYour donor system answers before anyone is asked for anything.
Campaign Start · APIThird one-off gift in twelve months (your donor system)
API CallAlready monthly? Last three amounts? Your donor system
One-off giver
Already monthly
WhatsApp FlowWhatsApp: Make it monthly / Not now
Make it monthly
Not now
No reply
API CallYour payment system sets up the monthly gift
Message · WhatsAppThank you, with the first collection date
End
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- monthly givers without a phone campaign.
- Trigger
- third one-off gift in 12 months (your donor system)
- Events and identifiers
- third one-off gift in 12 months (your donor system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- already monthly? (your donor system) · your payment system sets it up. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- no tap: silence. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- monthly givers without a phone campaign. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 02Illustrative journey
Recover the monthly gift that failed.
A failed collection reported by your gateway sends one WhatsApp with the update-card link, waits for the retry from your system, stops when it collects, and escalates to SMS and then a call if it does not.
- Decides
- your gateway's failure reason and retry.
- Aim
- monthly gifts kept when the card changes.
Built in the journey builder
Recover the monthly gift that failedNON-PROFITSOne link to update the card, the retry from your system, then SMS and a call if it still fails.
Campaign Start · APICollection failed (from your gateway)
ConditionCard expired?
Yes
Other reason
Message · WhatsAppWhatsApp with the update-card link
Wait TimeWait 3 days
Event CheckCollected? Ask your gateway
Yes
No
End
Message · SMSSMS with the same link
IVR CallStill failing: call
End
API CallRetry from your system
API CallStill failing: task to donor care
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- monthly gifts kept when the card changes.
- Trigger
- collection failed (your gateway)
- Events and identifiers
- collection failed (your gateway). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- collected? (your gateway). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- collected: stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- monthly gifts kept when the card changes. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 03Illustrative journey
Finish the donation that stopped at the amount step.
A session with the amount step opened and no payment sends one WhatsApp with a link back to the step and the closing date from your appeal, reminds once before it closes, and stops when they give.
- Decides
- a rule you set, and the closing date your system holds.
- Aim
- more gifts finished before the appeal closes.
Built in the journey builder
Finish the donation that stopped at the amount stepNON-PROFITSA session rule, a consent check, the closing date from your system, one reminder, then silence.
Campaign StartAmount step opened, no payment (session rule)
Check Channel ConsentCheck consent
API CallClosing date from your appeal system
WhatsApp FlowWhatsApp with a link back to the step
Tapped
No reply
Event CheckGift received?
Yes
No
End
Message · WhatsAppOne reminder before the appeal closes
End
Message · SMSSMS with the same link
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- more gifts finished before the appeal closes.
- Trigger
- session rule: amount step opened, no payment
- Events and identifiers
- session rule: amount step opened, no payment. Captured by the SDK or web tracker as the session runs, tied to the identified contact. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- closing date (your appeal system). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- still nothing: silence · gift received? stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- more gifts finished before the appeal closes. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 04Illustrative journey
Ask for the second gift before the first is forgotten.
A donor with a first gift and no second in ninety days enters a segment, gets a Story of what the first gift did, and one ask on their channel when they finish it; silence for thirty days ends the journey without a second message.
- Decides
- your segment definition and the window you set.
- Aim
- more first-time donors giving a second time.
Built in the journey builder
Ask for the second gift before the first is forgottenNON-PROFITSThe Story first, page by page; the ask only after it is read, and only once.
Segment EntryFirst gift, no second gift in 90 days
Check Channel ConsentCheck consent
StoryStory: what your gift did
Event CheckStory completed?
Yes
No
Message · WhatsAppOne ask on their channel
Event CheckGift received?
Yes
No
End
End
Wait TimeWait 30 days, then stop
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- more first-time donors giving a second time.
- Trigger
- segment entry: first gift, no second in 90 days
- Events and identifiers
- segment entry: first gift, no second in 90 days. Segment membership is recomputed from the contact's own events on the window you set; the identifier is the contact record. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- None beyond the platform's own records: the contact, its consent, and the delivery record.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- no: wait 30 days, then stop · gift? stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- more first-time donors giving a second time. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 05Illustrative journey
Bring back last Ramadan's donor before this Ramadan.
A donor who gave in last year's window and not since waits until the date on your calendar, then gets one WhatsApp at a sensible hour in their own time zone with the Zakat calculator and a tap to give; a gift stops the journey, and silence gets one reminder in the last ten nights.
- Decides
- your calendar and the segment you define.
- Aim
- last year's donors back before the window closes.
Built in the journey builder
Bring back last Ramadan's donor before this RamadanNON-PROFITSWaits for the date on your calendar, sends once in the donor's own time zone, reminds once.
Segment EntryGave last Ramadan, nothing since
Wait Until DateWait until the date on your calendar
Check Channel ConsentCheck consent
Message · WhatsAppLocal time: the calculator and Give
Event CheckGift received?
Yes
No
End
Wait Until DateWait until the last ten nights
Message · WhatsAppOne reminder
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- last year's donors back before the window closes.
- Trigger
- segment entry: gave last Ramadan, nothing since
- Events and identifiers
- segment entry: gave last Ramadan, nothing since. Segment membership is recomputed from the contact's own events on the window you set; the identifier is the contact record. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- None beyond the platform's own records: the contact, its consent, and the delivery record.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- gift? stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- last year's donors back before the window closes. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 06Illustrative journey
Collect the pledge from the dinner.
A pledge recorded at the event waits thirty days from the date your CRM holds, sends the pay link by WhatsApp, stops when your CRM says paid, and escalates to SMS and then a call from a person, with the outcome written back.
- Decides
- your CRM's pledge date and paid status.
- Aim
- pledges collected without a chasing list.
Built in the journey builder
Collect the pledge from the dinnerNON-PROFITSWaits thirty days from the date your CRM holds, stops when paid, escalates by channel if not.
Campaign Start · APIPledge recorded (from your CRM)
Wait TimeWait 30 days
API CallPaid? Ask your CRM
Paid
Unpaid
End
Message · WhatsAppWhatsApp with the pay link
Event CheckPaid within 7 days?
Yes
No
End
Message · SMSSMS with the same link
API CallTask to a person, outcome to your CRM
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- pledges collected without a chasing list.
- Trigger
- pledge recorded (your CRM)
- Events and identifiers
- pledge recorded (your CRM). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- paid? (your CRM) · still unpaid: task to a person · outcome to your CRM. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- paid? stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- pledges collected without a chasing list. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 07Illustrative journey
Renew the sponsorship in month eleven.
A sponsorship entering its eleventh month asks your donor system whether it is active and renewal is open, sends a Story of the year, then one WhatsApp with Renew or Not now; a tap goes to your payment system to renew for a second year.
- Decides
- your donor system's sponsorship record.
- Aim
- sponsorships renewed before they lapse.
Built in the journey builder
Renew the sponsorship in month elevenNON-PROFITSYour donor system confirms the sponsorship, the Story shows the year, the ask comes last.
Campaign Start · APISponsorship month 11 (from your donor system)
API CallActive? Renewal open? Your donor system
Open
Not open
StoryStory: the year in pictures
WhatsApp FlowWhatsApp: Renew / Not now
Renew
Not now
No reply
API CallYour payment system renews
Message · WhatsAppConfirmation
End
End
End
Message · EmailStandard renewal notice
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- sponsorships renewed before they lapse.
- Trigger
- sponsorship month 11 (your donor system)
- Events and identifiers
- sponsorship month 11 (your donor system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- active? renewal open? (your donor system) · your payment system renews. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- no tap: the standard notice, by email. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- sponsorships renewed before they lapse. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 08Illustrative journey
Fill tomorrow's volunteer shift.
A shift booked for tomorrow sends one WhatsApp with Confirm or Cannot make it; a confirmation is written back, a cancellation offers the slot to the waitlist the same hour, and silence gets one SMS at the hour you set.
- Decides
- your volunteer system's roster and waitlist.
- Aim
- fewer empty shifts on the day.
Built in the journey builder
Fill tomorrow's volunteer shiftNON-PROFITSThe volunteer answers with a tap; a cancellation reaches the waitlist the same hour.
Campaign Start · APIShift tomorrow (from your volunteer system)
WhatsApp FlowWhatsApp: Confirm / Cannot make it
Confirm
Cannot make it
No reply
API CallConfirmation written back
End
API CallSlot to the waitlist (your system)
Message · WhatsAppWaitlist: first tap takes it
Button ClickedSlot taken, written back
End
Message · SMSSMS at the hour you set
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- fewer empty shifts on the day.
- Trigger
- shift tomorrow (your volunteer system)
- Events and identifiers
- shift tomorrow (your volunteer system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- confirm: written back · cannot: slot to the waitlist. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- The message is delivered on the first channel that reports delivery, or the fallback order is exhausted and the failure is recorded.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; when the last channel in the order has reported failure, the message is recorded as failed with the reason. Delivery callbacks that arrive late update the record when they arrive.
- Success metric
- fewer empty shifts on the day. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 09Illustrative journey
Tell the beneficiary the grant is ready, and confirm the pickup.
A grant marked ready in your programme system sends one SMS with the collection point and a code, calls with the same code if the SMS is not delivered, and writes the pickup back when the code is checked at the point.
- Decides
- your programme system; the code is checked at the point.
- Aim
- grants collected by the person they were meant for, with the code checked at the point.
Built in the journey builder
Tell the beneficiary the grant is ready, and confirm the pickupNON-PROFITSSMS first for the feature phone, a call if it does not land, the code checked at the point.
Campaign Start · APIGrant ready (from your programme system)
Check Channel ConsentCheck consent
Message · SMSSMS: collection point and code
Delivery StatusDelivered?
Yes
No
API CallCode checked at the point
API CallPickup written back
End
IVR CallCall, code read out
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- grants collected by the person they were meant for, with the code checked at the point.
- Trigger
- grant ready (your programme system)
- Events and identifiers
- grant ready (your programme system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- code checked at the point · pickup written back. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- grants collected by the person they were meant for, with the code checked at the point. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 10Illustrative journey
Report the appeal with a Story, and learn what to fund next.
An appeal closed in your system sends every donor to it a Story of what it funded, page by page, with a poll on what the next appeal should fund; completion and the poll answer go on the record, and the answer builds the segment for the next appeal.
- Decides
- the event, and the poll answer.
- Aim
- an impact report that is read, and the next appeal aimed by the donors themselves.
Built in the journey builder
Report the appeal with a Story, and learn what to fund nextNON-PROFITSA Story tracked page by page, a poll answer on the record, and the next appeal's segment built from it.
Campaign Start · APIAppeal closed (from your system)
Check Channel ConsentCheck consent
StoryStory: what the appeal funded, with a poll
Event CheckStory completed?
Yes
No
Event CheckPoll answer on the record
Segment EntrySegment: next appeal, by answer
End
Message · EmailOne email with the report
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- an impact report that is read, and the next appeal aimed by the donors themselves.
- Trigger
- appeal closed (your system)
- Events and identifiers
- appeal closed (your system) · poll answer on the record · segment: next appeal, by answer. The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- None beyond the platform's own records: the contact, its consent, and the delivery record.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- an impact report that is read, and the next appeal aimed by the donors themselves. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
Where a step says your system decides, the journey calls your system and branches on its answer. xNotify carries the journey; it does not become the donor database.