FMCG · Playbook
The FMCG playbook. Built in the builder, decided by your distributor system.
Ten journeys, five for consumers and five for the trade, 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 second flavour the week the pack is scanned twice.
A second scan of the same pack this month asks your distributor system whether the second flavour is stocked nearby, then sends one WhatsApp with Send the code or Not now; a tap sends the code and the redemption comes back from your promotion system.
- Decides
- your stock and listing data.
- Aim
- second SKUs tried without a blanket discount.
Built in the journey builder
Offer the second flavour the week the pack is scanned twiceFMCGYour distributor system confirms the shelf before anyone is offered anything.
Campaign StartSecond scan of the same pack this month
API CallStocked nearby? Ask your distributor system
Stocked, not tried
Not stocked
WhatsApp FlowWhatsApp: Send the code / Not now
Send the code
Not now
No reply
Message · WhatsAppCode sent, one event written
Event CheckRedeemed? From your promo system
Yes
No, 14 days
End
Message · WhatsAppOne reminder before expiry
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
- second SKUs tried without a blanket discount.
- Trigger
- second scan of the same pack this month
- Events and identifiers
- second scan of the same pack this 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
- stocked nearby? (your distributor 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 tap: silence until the next scan. 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
- second SKUs tried without a blanket discount. 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
Reach the scheme tier with one case, not a rep visit.
An order that lands one case short of the tier checks the count with your distributor system, then sends the retailer one WhatsApp with Add a case or Not this week; a tap adds it to the order and confirms the scheme reached.
- Decides
- your scheme rules and the count your system holds.
- Aim
- more retailers reaching the tier without a call.
Built in the journey builder
Reach the scheme tier with one case, not a rep visitFMCGYour distributor system confirms the count before the retailer is asked for anything.
Campaign Start · APIOrder placed, one case short of the tier
API CallTier count from your distributor system
One case short
Tier already reached
WhatsApp FlowWhatsApp: Add a case / Not this week
Add a case
Not this week
No reply
API CallYour system adds it to the order
Message · WhatsAppConfirmation: scheme reached
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
- more retailers reaching the tier without a call.
- Trigger
- order placed, one case short of the tier
- Events and identifiers
- order placed, one case short of the tier. 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
- tier count (your distributor system) · your system adds 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: nothing until the next order. 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 retailers reaching the tier 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 · 03Illustrative journey
Catch the retailer whose weekly order did not come.
An order day that passes with no order in your distributor system sends the retailer one WhatsApp with Reorder last week or Send a rep; a reorder is placed by your system, a rep request becomes a task, and silence across two cycles moves the outlet into RFM At Risk.
- Decides
- your order calendar and your distributor system.
- Aim
- missed orders recovered before the shelf empties.
Built in the journey builder
Catch the retailer whose weekly order did not comeFMCGYour distributor system reports the gap; one WhatsApp, a repeat order or a rep, and RFM if silence holds.
Campaign Start · APIOrder day passed, no order (your system)
WhatsApp FlowWhatsApp: Reorder last week / Send a rep
Reorder
Send a rep
No reply
API CallYour system places the repeat order
Message · WhatsAppConfirmation
End
API CallTask to the rep (your system)
End
Message · SMSSMS: reply 1 to reorder
Wait TimeWait two order cycles
Segment EntryRFM At Risk, retailers
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
- missed orders recovered before the shelf empties.
- Trigger
- order day passed, no order (your system)
- Events and identifiers
- order day passed, no order (your system) · RFM 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
- reorder: your system places it · rep: task to the rep. 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
- missed orders recovered before the shelf empties. 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
Bring back the consumer who stopped scanning.
A consumer who enters RFM At Risk on your scan windows gets one recipe Story from the brand, not a discount; a read puts them in the segment for the next recipe, silence for thirty days moves them to Lost and the journey stops.
- Decides
- your RFM windows.
- Aim
- the drifting consumer reached before the brand is forgotten.
Built in the journey builder
Bring back the consumer who stopped scanningFMCGOne Story from the brand, not a discount; a read keeps them, silence lets them go.
Segment EntryRFM At Risk on scans, your windows
Check Channel ConsentCheck WhatsApp consent
StoryRecipe Story from the brand, not a discount
Event CheckRead?
Yes
No
Segment EntryNext recipe segment
End
Wait TimeWait 30 days
Segment EntryRFM Lost, 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
- the drifting consumer reached before the brand is forgotten.
- Trigger
- segment entry: RFM At Risk on scans
- Events and identifiers
- segment entry: RFM At Risk on scans · yes: next recipe segment. 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
- RFM Lost, 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 drifting consumer reached before the brand is forgotten. 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 the promotion entry into a redemption.
A promotion form completed inside a Story sends the code by WhatsApp after a consent check, waits for the redemption from your promotion system, thanks the redeemer with the second SKU offer, and reminds the rest once before the code expires.
- Decides
- your promotion system.
- Aim
- more codes redeemed at the till.
Built in the journey builder
Turn the promotion entry into a redemptionFMCGThe code is an event the moment it is sent; the redemption comes back from your promotion system.
Campaign StartPromotion form completed (Story)
Check Channel ConsentCheck WhatsApp consent
Message · WhatsAppCode by WhatsApp, one event written
Event CheckRedeemed? From your promo system
Yes
No, 3 days to expiry
Message · WhatsAppThank you, then the second SKU offer
End
Message · WhatsAppOne reminder before expiry
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 codes redeemed at the till.
- Trigger
- promotion form completed (Story)
- Events and identifiers
- promotion form completed (Story). 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
- 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 codes redeemed at the till. 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
Turn a built cart into a placed order.
A retailer app session that ends with a cart and no order checks consent and stock, sends the cart back on WhatsApp with a Place the order button, falls back to SMS if there is no tap, and stops when the order lands.
- Decides
- your stock, then the retailer.
- Aim
- orders placed without waiting for the rep.
Built in the journey builder
Turn a built cart into a placed orderFMCGA session rule, a consent check, the stock your system confirms, and the cart back on WhatsApp.
Campaign StartCart built, no order (session rule)
Check Channel ConsentCheck consent
API CallStock for the cart? Ask your system
WhatsApp FlowWhatsApp with the cart: Place the order
Tapped
No reply
API CallYour system places the order
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
- orders placed without waiting for the rep.
- Trigger
- session rule: cart built, no order
- Events and identifiers
- session rule: cart built, 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
- stock for the cart? (your system) · your system places 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
- stop when placed. 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 placed without waiting for the rep. 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
Capture the sampling name and sell the first pack.
A QR on the sampling stall opens a Story with a contact form; a completed form checks consent, fetches the nearest stockists from your system, and sends one WhatsApp with where to buy and a code for the first pack.
- Decides
- the form; your stockist list.
- Aim
- names from the stall turned into first packs.
Built in the journey builder
Capture the sampling name and sell the first packFMCGA form inside the Story, a consent check, the nearest stockists from your system, one message.
Campaign StartStall QR scanned
StoryStory with a contact form
Event CheckForm completed?
Yes
No
Check Channel ConsentCheck consent
API CallNearest stockists from your system
Message · WhatsAppWhere to buy, with a first-pack code
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
- names from the stall turned into first packs.
- Trigger
- stall QR scanned
- Events and identifiers
- stall QR scanned. 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
- nearest stockists (your 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
- no form: 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
- names from the stall turned into first packs. 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
Confirm the distributor's order by reply.
An order due from your distributor system sends one WhatsApp with Confirm or Change quantity; a confirmation is written back, a new quantity updates your system, and no reply becomes a call.
- Decides
- your distributor system; the distributor.
- Aim
- orders confirmed without a call.
Built in the journey builder
Confirm the distributor's order by replyFMCGOne WhatsApp, and the answer is written back to the system that owns the order.
Campaign Start · APIOrder due (from your distributor system)
WhatsApp FlowWhatsApp: Confirm / Change quantity (form)
Confirm
Change quantity
No reply
API CallWritten back to your system
End
API CallYour system updates the quantity
Message · WhatsAppConfirmation
End
IVR CallCall the distributor
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 confirmed without a call.
- Trigger
- order due (your distributor system)
- Events and identifiers
- order due (your distributor 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 · new quantity: your system updated. 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
- orders confirmed 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 · 09Illustrative journey
Run the trade promotion with a hand on the brake.
A retailer list goes out as a bulk send you can pause or stop mid-run; an Interested tap opens the scheme Story and becomes a lead for the rep in your system, and no reply ends the journey.
- Decides
- the reply.
- Aim
- reach with a brake, and the interested followed up.
Built in the journey builder
Run the trade promotion with a hand on the brakeFMCGA bulk send you can stop mid-run; the interested tap becomes a lead for the rep.
Campaign StartRetailer list uploaded
Message · WhatsAppBulk send, pause or stop mid-run
Button ClickedInterested?
Interested
No reply
StoryScheme details, page by page
API CallLead to the rep (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
- reach with a brake, and the interested followed up.
- Trigger
- retailer list uploaded
- Events and identifiers
- retailer list uploaded. 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
- lead to the rep (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 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
- reach with a brake, and the interested followed up. 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
Offer the family pack to the consumer who scans every month.
A consumer who has scanned the same pack three months running asks your distributor system whether the family pack is listed in their region, then gets one WhatsApp with Send the code or Not now; the redemption comes back from your promotion system.
- Decides
- your listing data and your promotion system.
- Aim
- pack size moved up without a shelf-wide discount.
Built in the journey builder
Offer the family pack to the consumer who scans every monthFMCGYour distributor system confirms the listing before the consumer is offered anything.
Segment EntrySame pack scanned three months running
API CallFamily pack listed nearby? Ask your system
Listed
Not listed
WhatsApp FlowWhatsApp: Send the code / Not now
Send the code
Not now
No reply
Message · WhatsAppCode sent, one event written
Event CheckRedeemed? From your promo system
Yes
No, silence
End
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
- pack size moved up without a shelf-wide discount.
- Trigger
- segment entry: same pack, three months running
- Events and identifiers
- segment entry: same pack, three months running. 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
- family pack listed nearby? (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 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
- pack size moved up without a shelf-wide discount. 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.