Banks · Playbook
The banking playbook. Built in the builder, decided by your core.
Ten journeys, each drawn below as it runs. The decision comes from your systems or criteria you set; the journey carries it. Aims are targets to agree in the pilot, not results.
PLAYBOOKS · 01Illustrative journey
Offer the card upgrade the month the salary rises.
A salary credit greater than the previous month asks your core whether the customer qualifies, then sends one WhatsApp with Upgrade or Not now; a tap goes to your system to process.
- Decides
- your eligibility rules.
- Aim
- upgrades without a call.
Built in the journey builder
Offer the upgrade the month the salary risesBANKSYour core answers before anyone is offered anything.
Campaign Start · APISalary credit greater than the previous month (from your core)
API CallEligible? Ask your core
Eligible, not held
Not eligible
WhatsApp FlowWhatsApp: Upgrade / Not now
Upgrade
Not now
No reply
API CallYour system processes the upgrade
Message · WhatsAppConfirmation
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
- upgrades without a call.
- Trigger
- salary credit greater than the previous month
- Events and identifiers
- salary credit greater than the previous month. 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
- eligible? (your core) · your system processes. 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 until the next cycle. 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
- upgrades without a call. 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
Offer the deposit when the balance sits idle.
A balance idle for sixty days asks your core whether the amount is free and the product is not held, then sends one WhatsApp with Open a deposit or Not now; a tap goes to your system to open it.
- Decides
- your product rules and the balance your core holds.
- Aim
- deposits without a branch visit.
Built in the journey builder
Offer the deposit when the balance sits idleBANKSYour core confirms the amount is free and the product is not held before anything is offered.
Campaign Start · APIBalance idle for 60 days (from your core)
API CallAmount free? Product held? Ask your core
Free, not held
Held, or not free
WhatsApp FlowWhatsApp: Open a deposit / Not now
Open a deposit
Not now
No reply
API CallYour system opens it
Message · WhatsAppConfirmation
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
- deposits without a branch visit.
- Trigger
- balance idle 60 days (your core)
- Events and identifiers
- balance idle 60 days (your core). 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
- amount free? product held? (your core) · your system opens it. 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
- deposits without a branch visit. 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
Catch the salary that stopped arriving.
A customer with a salary credit for three months and none in thirty-five days enters a segment and gets one message from the bank; a reply becomes a task for a relationship manager.
- Decides
- your segment definition.
- Aim
- the leaving customer reached before the account closes.
Built in the journey builder
Catch the salary that stopped arrivingBANKSOne message from the bank, not an offer; a reply reaches a person.
Segment EntrySalary seen for three months, none in 35 days
Message · InboxOne message from the bank, not an offer
Reply
No reply
API CallTask to the relationship manager (your system)
End
Wait TimeWait 30 days
Segment EntryRFM At Risk
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
- the leaving customer reached before the account closes.
- Trigger
- segment entry: salary missing
- Events and identifiers
- segment entry: salary missing · RFM At Risk. 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
- yes: task to the relationship manager. 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 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
- the leaving customer reached before the account 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
Win back the money going to another bank.
A third transfer to the same external bank in ninety days checks what the customer holds with you, then sends one Story about the matching product you offer that they do not yet hold, and an offer if they read it. The transfer is a signal to ask, not proof of what they hold elsewhere.
- Decides
- your product rules.
- Aim
- share of wallet recovered.
Built in the journey builder
Win back the money going to another bankBANKSA check of what they hold with you, then one Story, then an offer only if they read it.
Campaign Start · APIThird transfer to the same bank (from your core)
API CallWhat do they hold? Ask your core
StoryStory on the product they buy elsewhere
Event CheckRead?
Yes
No
Message · WhatsAppOffer on their channel
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
- share of wallet recovered.
- Trigger
- third transfer to the same bank
- Events and identifiers
- third transfer to the same bank. 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
- what do they hold? (your core). 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
- 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
- share of wallet recovered. 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
Turn a loan calculator into an application.
A session with the calculator used and no application sends the figure your core pre-approves with a tap to apply, reminds once if the upload stalls, and stops when the application completes.
- Decides
- your credit rules.
- Aim
- more completed applications.
Built in the journey builder
Turn a loan calculator into an applicationBANKSA session rule, a consent check, the figure your core pre-approves, one reminder if the upload stalls.
Campaign StartCalculator used, no application (session rule)
Check Channel ConsentCheck consent
API CallPre-approved figure from your core
WhatsApp FlowWhatsApp with a tap to apply
Tapped
No reply
Event CheckStopped at upload?
Yes
Completed
Message · WhatsAppOne reminder
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
- more completed applications.
- Trigger
- session rule: calculator used, no application
- Events and identifiers
- session rule: calculator used, no application. 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
- pre-approved figure (your core). 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
- stop when complete. 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 completed applications. 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
Activate the card that is sitting in a drawer.
A card-issued event starts a Story with the steps, waits, checks your core, and reminds once on the customer's channel if the card is still inactive.
- Decides
- your core system's card status.
- Aim
- more cards activated in the first week.
Built in the journey builder
Activate the card that is sitting in a drawerBANKSA Story with the steps, a wait, a check with your core, one reminder, then a call.
Campaign Start · APICard issued (from your core)
StoryStory with the steps, in the app
Wait TimeWait three days
API CallActive? Ask your core
Yes
No
End
Message · WhatsAppOne reminder on their channel
IVR CallStill inactive: call
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 cards activated in the first week.
- Trigger
- card issued
- Events and identifiers
- card issued. 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? (your core). 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
- yes: 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 cards activated in the first week. 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
Turn a declined card abroad into a one-tap fix.
A decline from your core system sends a WhatsApp with one button, and a tap switches international use on and confirms.
- Decides
- your core system, then the customer.
- Aim
- fewer contact-centre calls, recovered international spend.
Built in the journey builder
Turn a declined card abroad into a one-tap fixBANKSOne WhatsApp button; a tap switches international use on and writes the outcome back.
Campaign Start · APICard declined abroad (from your core)
WhatsApp FlowWhatsApp: Enable international use?
Tapped
No tap
API CallSwitch international use on (your core)
Message · WhatsAppConfirmation
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
- fewer contact-centre calls, recovered international spend.
- Trigger
- declined abroad
- Events and identifiers
- declined abroad. 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
- your core system. 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 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
- fewer contact-centre calls, recovered international spend. 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 · 08Gated proofIllustrative journey
Verify a transaction without a human dialling.
A large transaction triggers a call with a keypad answer, escalating to WhatsApp then SMS if unanswered, with the result written back.
- Decides
- your fraud rules; the customer.
- Aim
- faster verification, fewer manual checks.
Built in the journey builder
Verify a transactionBANKINGA call, a keypad answer, and an escalation if no one picks up.
Campaign StartTransaction made
IVR CallCall the customer
DTMF ResponseKeypad reply
1It was me
2Not me
No answer
Delivery StatusConfirmed
End
API CallAlert fraud system
End
WhatsApp FlowWhatsApp
Message · SMSSMS
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
- faster verification, fewer manual checks.
- Trigger
- transaction
- Events and identifiers
- transaction. 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
- result to your system. 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 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
- faster verification, fewer manual checks. 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
Move transaction alerts off SMS with every attempt on the record.
Alerts go by push and Inbox to app users over our own network and fall back to SMS on the carrier's signal; every message keeps its record.
- Decides
- your channel order, per message type.
- Aim
- lower alert cost, the same evidence.
Built in the journey builder
Move transaction alerts off SMS with every attempt on the recordBANKSPush and Inbox over our own network for app users; SMS on the carrier's signal; one record per message.
Campaign Start · APITransaction alert (from your core)
ConditionApp user?
Yes
No
Push + InboxPush and Inbox over our own network
Delivery StatusDelivered?
Yes
No
End
Message · SMSSMS on the carrier's signal
End
Message · SMSSMS
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
- lower alert cost, the same evidence.
- Trigger
- transaction alert
- Events and identifiers
- transaction alert. 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
- one record per message. 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 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
- lower alert cost, the same evidence. 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
Remind on the due date, then escalate.
The journey waits until the date your system holds, sends Pay now, stops when paid, and escalates by channel if not.
- Decides
- your due dates and risk tiers.
- Aim
- higher recovery, lower cost to collect.
Built in the journey builder
Remind on the due date, then escalateBANKSWaits until the date your system holds, stops when paid, escalates by channel if not.
Campaign Start · APIDue date (from your system)
Wait Until DateWait until the due date
Message · WhatsAppPay now
Event CheckPaid?
Yes
No
End
Message · WhatsAppWhatsApp
Message · SMSSMS
IVR CallCall
API CallOutcome to your system
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
- higher recovery, lower cost to collect.
- Trigger
- due date
- Events and identifiers
- due date. 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
- outcome to your system. 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
- higher recovery, lower cost to collect. 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 model.