E-commerce · Playbook
The e-commerce playbook. Built in the builder, decided by your order system.
Ten journeys, each drawn below as it runs. The decision comes from your order system or criteria you set; the journey carries it. Aims are targets to agree in the pilot, not results.
PLAYBOOKS · 01Illustrative journey
Confirm the cash order before the courier is booked.
A cash-on-delivery order not confirmed within your window sends one WhatsApp with Confirm or Cancel; a tap books the courier or releases the stock in your order system, and silence escalates to SMS, then a call with a keypad answer.
- Decides
- your confirmation window and your order system.
- Aim
- fewer parcels sent to a doorstep that will refuse them.
Built in the journey builder
Confirm the cash order before the courier is bookedE-COMMERCEOne WhatsApp with two buttons; the courier is booked only on a Confirm.
Campaign Start · APICOD order placed, unconfirmed (your orders)
WhatsApp FlowWhatsApp: Confirm / Cancel
Confirm
Cancel
No reply
API CallBook the courier (your order system)
Message · WhatsAppDispatch confirmation
End
API CallRelease the stock (your order system)
End
Message · SMSSMS with the same two options
IVR CallCall: press 1 to confirm, 2 to cancel
API CallOutcome to your order 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
- fewer parcels sent to a doorstep that will refuse them.
- Trigger
- COD order placed, not confirmed
- Events and identifiers
- COD order placed, not confirmed. 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: your system books the courier · cancel: stock released · outcome to your order 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 parcels sent to a doorstep that will refuse them. 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 checkout that stalled, once.
A session that reaches checkout and ends unpaid starts a consent-checked journey that waits an hour, checks for a purchase first, sends one WhatsApp with a Finish order button, and falls back to one SMS.
- Decides
- a session rule you set, and your cap per shopper.
- Aim
- recovered checkouts, once per shopper.
Built in the journey builder
Recover a stalled checkoutRETAILStarts when the visit ends, stops itself if they already bought.
Campaign StartReached checkout, never paid
Check Channel ConsentCheck WhatsApp consent
Wait TimeWait 1 hour
Event CheckDid they buy?
Yes
No
End
WhatsApp FlowWhatsApp reminder, Finish order button
Tapped
No reply
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
- recovered checkouts, once per shopper.
- Trigger
- checkout, not paid (session rule)
- Events and identifiers
- checkout, not paid (session rule). 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
- 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
- bought? 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
- recovered checkouts, once per shopper. 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
Ask for prepayment after the second refusal.
A shopper who refused cash on delivery twice in ninety days enters a segment; your order system is set to prepaid-only for them, one message says so with a payment link, and a prepaid order within thirty days restores the option.
- Decides
- your refusal window and your payment policy.
- Aim
- the return-to-origin bill cut without losing the honest shopper.
Built in the journey builder
Ask for prepayment after the second refusalE-COMMERCEA segment on your rule, a flag in your order system, one message, and the option restored when they pay.
Segment EntryRefused COD twice in 90 days (your rule)
API CallSet prepaid-only (your order system)
Message · WhatsAppNext order prepaid, with a payment link
Event CheckPrepaid order within 30 days?
Yes
No
API CallRestore cash on delivery (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
- the return-to-origin bill cut without losing the honest shopper.
- Trigger
- segment entry: refused COD twice
- Events and identifiers
- segment entry: refused COD twice. 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
- prepaid-only flag (your order system) · yes: restore cash on delivery. 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: stays prepaid. 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 return-to-origin bill cut without losing the honest shopper. 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
Offer the reorder the week the pack runs out.
A thirty-day pack delivered starts a wait until the run-out date your order holds; your system confirms stock and that they have not reordered, then one WhatsApp asks Reorder or Not now, and a tap places the order.
- Decides
- the run-out date your order holds and your stock.
- Aim
- repeat orders before the shopper searches elsewhere.
Built in the journey builder
Offer the reorder the week the pack runs outE-COMMERCEWaits until the date your order holds; your system confirms stock before anyone is asked.
Campaign Start · APIThirty-day pack delivered (your orders)
Wait Until DateWait until run-out, minus four days
API CallIn stock? Reordered? Ask your system
In stock, not reordered
Reordered, or out of stock
WhatsApp FlowWhatsApp: Reorder / Not now
Reorder
Not now
No reply
API CallYour system places the order
Message · WhatsAppOrder confirmation
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
- repeat orders before the shopper searches elsewhere.
- Trigger
- thirty-day pack delivered
- Events and identifiers
- thirty-day pack delivered. 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? reordered? (your system) · your system places the order. 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
- repeat orders before the shopper searches elsewhere. 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
Sell the bundle after the delivery, not with the ad.
Ten days after running shoes are delivered, your system confirms the bundle is in stock and not already bought, and one WhatsApp offers it with a tap that creates the order.
- Decides
- your product pairs and your stock.
- Aim
- a higher order value from shoppers who already trust the delivery.
Built in the journey builder
Sell the bundle after the delivery, not with the adE-COMMERCEA delivered order, a wait, a stock check with your system, one offer, one tap to order.
Campaign Start · APIRunning shoes delivered (your orders)
Wait TimeWait 10 days
API CallBundle in stock? Bought? Ask your system
In stock, not bought
Bought, or out of stock
WhatsApp FlowWhatsApp: Add the bundle / Not now
Add the bundle
Not now
No reply
API CallYour system creates the order
Message · WhatsAppOrder confirmation
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 higher order value from shoppers who already trust the delivery.
- Trigger
- running shoes delivered
- Events and identifiers
- running shoes delivered. 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
- bundle in stock? bought? (your system) · your system creates the order. 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 journey ends. 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 higher order value from shoppers who already trust the delivery. 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
Open the category they browse and never buy.
A shopper who browses a category every week and has never ordered from it gets one Story on it, on your domain or in the app, and one offer only if they read it to the end.
- Decides
- your segment definition.
- Aim
- a second category per customer.
Built in the journey builder
Open the category they browse and never buyE-COMMERCEA consent check, one Story, then an offer only if they read it to the end.
Segment EntryBrowsed the category weekly, never bought
Check Channel ConsentCheck consent
StoryStory on the category, on your domain
Event CheckRead to the end?
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 second category per customer.
- Trigger
- segment entry: browsed weekly, never bought
- Events and identifiers
- segment entry: browsed weekly, never bought. 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
- not read: 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 category per customer. 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 the third monthly order into a subscription.
A third order of the same item in ninety days asks your system whether a subscription is already in place, then sends one WhatsApp with Subscribe monthly or Not now; a tap creates the subscription in your system.
- Decides
- your subscription rules.
- Aim
- predictable repeat revenue without a monthly reminder.
Built in the journey builder
Turn the third monthly order into a subscriptionE-COMMERCEYour system says whether a subscription already exists before anyone is offered one.
Campaign Start · APIThird order of the same item in 90 days
API CallAlready subscribed? Ask your system
Not yet, eligible
Already subscribed
WhatsApp FlowWhatsApp: Subscribe monthly / Not now
Subscribe monthly
Not now
No reply
API CallYour system creates the subscription
Message · WhatsAppConfirmation with the first delivery 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
- predictable repeat revenue without a monthly reminder.
- Trigger
- third order of the same item in 90 days
- Events and identifiers
- third order of the same item in 90 days. 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 subscribed? (your system) · your system creates the subscription. 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
- predictable repeat revenue without a monthly reminder. 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
Turn the return into an exchange.
A return started for size asks your system whether the next size is in stock, then offers Exchange or Refund on WhatsApp; a tap books the exchange pickup and delivery, or processes the refund.
- Decides
- your stock and your returns policy.
- Aim
- returns kept as sales.
Built in the journey builder
Turn the return into an exchangeE-COMMERCEYour system checks the next size before the exchange is offered; the refund stays one tap away.
Campaign Start · APIReturn started, reason: size (your orders)
API CallNext size in stock? Ask your system
In stock
Not in stock: refund as usual
WhatsApp FlowWhatsApp: Exchange / Refund
Exchange
Refund
No reply
API CallYour system books the exchange
Message · WhatsAppPickup and delivery confirmed
End
API CallYour system processes the refund
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
- returns kept as sales.
- Trigger
- return started, reason: size
- Events and identifiers
- return started, reason: size. 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
- next size in stock? (your system) · exchange: your system books it · refund: your system processes 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
- 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
- returns kept as sales. 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
Nudge the product viewed three times, once the stock is checked.
A session rule for the same product viewed three times with nothing added to the cart checks consent and stock, checks they have not added it since, and sends one WhatsApp with a link back to the product. No second nudge.
- Decides
- a session rule you set and your stock.
- Aim
- browse to buy, without a coupon.
Built in the journey builder
Nudge the product viewed three times, once the stock is checkedE-COMMERCEConsent, then stock from your system, then a check they have not added it since. One message.
Campaign StartViewed 3 times, no add to cart (session)
Check Channel ConsentCheck consent
API CallIn stock in their size? Ask your system
In stock
Out of stock
Event CheckAdded to cart since?
Yes
No
End
WhatsApp FlowWhatsApp with a link to the product
Tapped
No reply
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
- browse to buy, without a coupon.
- Trigger
- session rule: viewed 3 times, no add to cart
- Events and identifiers
- session rule: viewed 3 times, no add to cart. 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 in their size? (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 tap: silence · added since? 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
- browse to buy, without a coupon. 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
Reach the customer who stopped ordering, before they are Lost.
Two orders and none in sixty days moves the shopper to At Risk on your RFM windows; one message from the store, not a discount, goes on the channel they answer; a reply reaches your support desk, and silence waits and checks again.
- Decides
- your RFM windows and your win-back rule.
- Aim
- the third order that did not come, caught before the customer is gone.
Built in the journey builder
Reach the customer who stopped ordering, before they are LostE-COMMERCEOne message from the store, not a discount; a reply reaches a person, silence is checked again.
Segment EntryRFM At Risk: two orders, none in 60 days
Check Channel ConsentCheck consent
WhatsApp FlowOne message from the store, no discount
Reply or tap
No reply
API CallReply to your support desk (your system)
End
Wait TimeWait 30 days
Event CheckOrdered since?
Yes
No
End
Segment EntryRFM Lost: your win-back rule
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 third order that did not come, caught before the customer is gone.
- Trigger
- RFM At Risk: two orders, none in 60 days
- Events and identifiers
- RFM At Risk: two orders, none in 60 days · RFM Lost: your win-back rule. 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: to your support desk. 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
- ordered since? 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 third order that did not come, caught before the customer is gone. 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.