Retail · Playbook
The retail playbook. Built in the builder, decided by your tills and your loyalty system.
Ten journeys, each drawn below as it runs. The decision comes from your tills, your stock and loyalty systems or criteria you set; the journey carries it. Aims are targets to agree in the pilot, not results.
PLAYBOOKS · 01Illustrative journey
Offer the adjacent category the day the receipt shows a new one.
A receipt with a category the member has never bought asks your stock system whether the adjacent line is in their store, then sends one WhatsApp with Reserve or Not now; a tap goes to your system to hold it.
- Decides
- your stock system and your category map.
- Aim
- a second category bought in the first month.
Built in the journey builder
Offer the adjacent category the day the receipt shows a new oneRETAILYour stock system answers before anyone is offered anything.
Campaign Start · APIFirst-time category on a receipt (your tills)
API CallIn stock at their store? Ask your system
In stock
Not in stock
WhatsApp FlowWhatsApp: Reserve / Not now
Reserve
Not now
No reply
API CallYour system reserves it
Message · WhatsAppConfirmation: collect at your store
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
- a second category bought in the first month.
- Trigger
- first-time category on a receipt
- Events and identifiers
- first-time category on a receipt. 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
- in stock at their store? (your system) · your system reserves 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
- a second category bought in the first month. 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
Bring the member back before the lapse.
A member entering At Risk on your own recency gets one Story on what is new since their last visit, an offer on their channel if they read it, and silence if they do not.
- Decides
- your recency window and your offer rules.
- Aim
- a return visit inside the window, without a blast.
Built in the journey builder
Bring the member back before the lapseRETAILOne Story, an offer only if they read it, silence if they do not.
Segment EntryAt Risk on your recency (your RFM)
Check Channel ConsentCheck consent
StoryStory: new since your last visit
Event CheckRead?
Yes
No
Message · WhatsAppOne offer 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
- a return visit inside the window, without a blast.
- Trigger
- segment entry: At Risk (your RFM)
- Events and identifiers
- segment entry: At Risk (your RFM). 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: 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
- a return visit inside the window, without a blast. 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
Win back the lines that fell out of the basket.
A basket down three trips running asks your system which categories fell away, then sends one message with the private label in those lines at member price; if nothing is bought in two weeks the member moves to At Risk.
- Decides
- your tills and your private-label map.
- Aim
- the dropped lines back on the receipt.
Built in the journey builder
Win back the lines that fell out of the basketRETAILYour system names the categories that fell away; one offer on the private label in those lines.
Campaign Start · APIBasket down three trips running (your tills)
API CallWhich categories fell away? Ask your system
Message · WhatsAppPrivate label in those lines, member price
Event CheckBought within 14 days?
Yes
No
End
Segment EntryAt 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 dropped lines back on the receipt.
- Trigger
- basket down three trips (your tills)
- Events and identifiers
- basket down three trips (your tills) · no: At Risk. 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
- which categories fell away? (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
- 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
- the dropped lines back on the receipt. 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
Get the member over the tier line before the quarter ends.
A member a few points short of the next tier asks your loyalty system to confirm the gap and the date, then gets one Inbox message with what gets them over; a welcome follows when they cross, silence if they do not.
- Decides
- your loyalty system's tier rules and dates.
- Aim
- more members crossing a tier in the last month of the quarter.
Built in the journey builder
Get the member over the tier line before the quarter endsRETAILYour loyalty system confirms the gap and the date; one message, a welcome when they cross.
Campaign Start · APIPoints short of the next tier (your loyalty)
API CallGap and date? Ask your loyalty system
Confirmed
Already crossed
Message · InboxWhat gets them over, with the date
Event CheckCrossed the line?
Yes
No
Message · WhatsAppWelcome to the new tier
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 members crossing a tier in the last month of the quarter.
- Trigger
- points short of the next tier (your loyalty)
- Events and identifiers
- points short of the next tier (your loyalty). 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
- gap and date confirmed? (your loyalty 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
- no: 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
- more members crossing a tier in the last month of the quarter. 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 size picked into an order.
A session with a product page opened three times and a size picked but no order checks consent, asks your system whether that size is in their store, and sends one WhatsApp with Finish order or Reserve to try on.
- Decides
- your stock system, then the member.
- Aim
- orders and reservations from visits that ended empty.
Built in the journey builder
Turn a size picked into an orderRETAILA session rule, a consent check, stock from your system, one WhatsApp with two ways to say yes.
Campaign StartSize picked, no order (session rule)
Check Channel ConsentCheck consent
API CallIn stock at their store? Ask your system
In stock
Not in stock
WhatsApp FlowWhatsApp: Finish order / Reserve to try on
Finish order
Reserve
No reply
End
API CallYour system holds it
Message · WhatsAppConfirmation: ready to try on
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
- orders and reservations from visits that ended empty.
- Trigger
- session rule: size picked, no order
- Events and identifiers
- session rule: size picked, no order. 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
- in stock at their store? (your system) · reserve: your system holds it. 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
- no reply: 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
- orders and reservations from visits that ended empty. 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
Remind before the points expire, not after.
The journey waits until seven days before the date your loyalty system holds, sends one WhatsApp with the balance and what the member usually buys, stops when they redeem, and sends one SMS if not.
- Decides
- your loyalty system's expiry dates.
- Aim
- points redeemed in store instead of written off.
Built in the journey builder
Remind before the points expire, not afterRETAILWaits until the date your loyalty system holds, stops when redeemed, one SMS if not.
Campaign Start · APIPoints expire on a date (your loyalty)
Wait Until DateWait until seven days before
Message · WhatsAppPoints expiring, with what they buy
Event CheckRedeemed?
Yes
No
End
Message · SMSOne more, by SMS
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
- points redeemed in store instead of written off.
- Trigger
- points expire on a date (your loyalty)
- Events and identifiers
- points expire on a date (your loyalty). 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
- 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
- points redeemed in store instead of written off. 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
Fill the store event with the members who shop there.
The members of one store get a Story with the invitation and an RSVP poll; a yes is written to your system, and a reminder with the time goes out the day before.
- Decides
- your event calendar and your store segments.
- Aim
- a room full of the members who already shop there.
Built in the journey builder
Fill the store event with the members who shop thereRETAILA Story with an RSVP poll to one store's members; a yes is written back and reminded the day before.
Segment EntryMembers of that store
StoryInvitation with an RSVP poll
Event CheckRSVP answered yes?
Yes
No, or no answer
API CallRSVP to your system
Wait Until DateWait until the day before
Message · WhatsAppReminder with the time
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
- a room full of the members who already shop there.
- Trigger
- segment: members of that store
- Events and identifiers
- segment: members of that store. 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
- RSVP 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
- no: 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
- a room full of the members who already shop there. 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
Take the shopper from the shelf into the app.
A shelf QR opens the product in the app if installed and the store page if not; a week later the journey checks for the install and welcomes the new member with the product they scanned.
- Decides
- the device, then the install record.
- Aim
- in-store shoppers in the app, credited to the shelf.
Built in the journey builder
Take the shopper from the shelf into the appRETAILThe link opens the app or the store page; the install is credited, matched on Android, estimated on iOS.
Campaign StartShelf QR scanned (smart link)
ConditionApp installed?
Yes, opens in the app
No, store page
End
Wait TimeWait seven days
Event CheckInstalled?
Yes, credited to the shelf
No
Message · InboxWelcome, with the product they scanned
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
- in-store shoppers in the app, credited to the shelf.
- Trigger
- shelf QR scanned (smart link)
- Events and identifiers
- shelf QR scanned (smart link). 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
- Per-channel consent on the contact record is checked before any send.
- Stops when
- yes: opens in the app. 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
- in-store shoppers in the app, credited to the shelf. 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
Turn one private-label trial into a habit.
A receipt with the private label for the first time waits one buying cycle, checks the receipts for a repeat, and if there is none asks your system for stock and sends one offer at member price on the line they tried.
- Decides
- your buying cycle and your stock system.
- Aim
- a second private-label purchase within two cycles.
Built in the journey builder
Turn one private-label trial into a habitRETAILOne buying cycle, a check of the receipts, then one offer only if they did not come back for it.
Campaign Start · APIPrivate label on a receipt, first time
Wait TimeWait one buying cycle (21 days)
Event CheckBought it again?
Yes
No
End
API CallIn stock at their store? Ask your system
Message · WhatsAppMember price on the line they tried
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
- a second private-label purchase within two cycles.
- Trigger
- private label on a receipt, first time
- Events and identifiers
- private label on a receipt, first time. 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
- no: in stock at their store? (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
- 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
- a second private-label purchase within two cycles. 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
Ask after the visit and route the answer to the store.
A receipt scanned at the till waits a day, then asks the member how the visit was on WhatsApp; a Not good becomes a task for that store's manager in your system, a Good ends the journey.
- Decides
- the member, then your store operations system.
- Aim
- every poor visit reaching the store manager the next day.
Built in the journey builder
Ask after the visit and route the answer to the storeRETAILOne question a day after the receipt; a poor answer becomes a task in your system.
Campaign Start · APIReceipt scanned (your tills)
Wait TimeWait one day
WhatsApp FlowWhatsApp: How was your visit?
Good
Not good
No reply
End
API CallTask to the store manager (your system)
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
- every poor visit reaching the store manager the next day.
- Trigger
- receipt scanned (your tills)
- Events and identifiers
- receipt scanned (your tills). 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
- not good: task to the store 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
- no reply: 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
- every poor visit reaching the store manager the next 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
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.