Logistics · Playbook
The logistics playbook. Built in the builder, answered by your dispatch system.
Ten journeys, each drawn below as it runs. The decision comes from your dispatch, booking and order systems or criteria you set; the journey carries it. Aims are targets to agree in the pilot, not results.
PLAYBOOKS · 01Illustrative journey
Rescue the second failed attempt before the parcel comes back.
A second failed attempt at the same address takes the reason from your dispatch system; not home sends one WhatsApp with Pick a slot or Collect from hub, an unfound address asks for a shared location, and every answer is written back before the next run.
- Decides
- your dispatch system; the consignee.
- Aim
- fewer parcels returned to the shipper.
Built in the journey builder
Rescue the second failed attempt before the parcel comes backLOGISTICSYour dispatch system gives the reason; the consignee chooses; the answer is written back before the next run.
Campaign Start · APISecond attempt failed, same address
ConditionReason? From your dispatch
Not home
Address not found
WhatsApp FlowWhatsApp: Pick a slot / Collect from hub
Pick a slot
Collect from hub
No reply
API CallOpen slots from your dispatch
Button ClickedConsignee picks a slot
API CallSlot written back to your dispatch
Message · SMSConfirmation by SMS
End
API CallHold at the hub (your dispatch)
Message · WhatsAppHub address and opening hours
End
IVR CallCall with keypad options
End
Message · WhatsAppWhatsApp: Share your location
API CallPin written back, reattempt booked
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 returned to the shipper.
- Trigger
- second attempt failed, same address
- Events and identifiers
- second attempt failed, same address. 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
- reason? (your dispatch) · slot: open slots from your dispatch · written back. 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 returned to the shipper. 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
Confirm the cash-on-delivery order before it leaves the hub.
A cash-on-delivery order from a consignee who refused the last one triggers a call with a keypad answer, escalating to WhatsApp, then SMS, if unanswered; Confirm releases the dispatch, Cancel stops it, and the order is held until one arrives.
- Decides
- your order system; the consignee.
- Aim
- fewer refused parcels on the van.
Built in the journey builder
Confirm the cash-on-delivery order before it leaves the hubLOGISTICSA call, a keypad answer, an escalation if nobody picks up; the order is held until one arrives.
Campaign Start · APICOD order, consignee refused before
IVR CallCall: confirm the order
DTMF ResponseKeypad reply
1Confirm
2Cancel
No answer
API CallRelease for dispatch (your system)
End
API CallCancel before dispatch (your system)
End
WhatsApp FlowWhatsApp: Confirm / Cancel
Tapped
No reply
API CallOutcome to your system
End
Message · SMSSMS, order held at the hub
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 refused parcels on the van.
- Trigger
- COD order, consignee refused before
- Events and identifiers
- COD order, consignee refused before. 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: release for dispatch · cancel: stop before dispatch. 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
- cancel: stop before dispatch. The message is delivered on the first channel that reports delivery, or the fallback order is exhausted and the failure is recorded.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; when the last channel in the order has reported failure, the message is recorded as failed with the reason. Delivery callbacks that arrive late update the record when they arrive.
- Success metric
- fewer refused parcels on the van. 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 shipper whose bookings are thinning.
A shipper whose bookings have fallen three weeks running enters a segment and gets one message from the account owner; a reply becomes a task in your CRM, silence waits, checks your system again, and ends in a call.
- Decides
- your segment definition; your booking data.
- Aim
- the leaving shipper reached before the last lane goes quiet.
Built in the journey builder
Catch the shipper whose bookings are thinningLOGISTICSOne message from the account owner, not a rate card; a reply reaches a person.
Segment EntryBookings down, third week (RFM At Risk)
Message · WhatsAppOne message from the account owner
Reply
No reply
API CallTask to the account manager (your CRM)
End
Wait TimeWait 14 days
API CallBookings recovered? Ask your system
Yes
Still down
End
IVR CallCall from the account owner
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 shipper reached before the last lane goes quiet.
- Trigger
- segment entry: bookings down, third week
- Events and identifiers
- segment entry: bookings down, third week. 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 account manager (your CRM) · bookings recovered? (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
- the leaving shipper reached before the last lane goes quiet. 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
Turn the quote that was never booked into a booking.
A session with a quote calculated and no booking checks consent, asks your rating engine whether the rate still stands, and sends it once with a tap to book; the tap creates the booking in your system and confirms the pickup.
- Decides
- your rating engine; the shipper.
- Aim
- more quotes that become bookings.
Built in the journey builder
Turn the quote that was never booked into a bookingLOGISTICSA session rule, a consent check, the rate your engine confirms, one message with a tap to book.
Campaign StartQuote calculated, no booking (session rule)
Check Channel ConsentCheck WhatsApp consent
API CallRate still valid? Ask your rating engine
Valid
Expired
WhatsApp FlowWhatsApp: Book at this rate / Not now
Book
Not now
No reply
API CallYour system creates the booking
Message · WhatsAppPickup 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
- more quotes that become bookings.
- Trigger
- session rule: quote calculated, no booking
- Events and identifiers
- session rule: quote calculated, no booking. 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
- rate still valid? (your rating engine) · your system creates the booking. 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. 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 quotes that become bookings. 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
Add cover when the declared value deserves it.
A declared value above the standard cover asks your booking system whether cover is available for the lane and the value, then sends one WhatsApp with Add cover or Send as is; a tap adds it before the parcel leaves the hub.
- Decides
- your cover rules per lane.
- Aim
- cover sold without a call.
Built in the journey builder
Add cover when the declared value deserves itLOGISTICSYour booking system answers before anyone is offered anything.
Campaign Start · APIDeclared value above the standard cover
API CallCover for this lane? Ask your system
Available, not added
Not offered on this lane
WhatsApp FlowWhatsApp: Add cover / Send as is
Add cover
Send as is
No reply
API CallYour system adds the cover
Message · WhatsAppConfirmation with the cover amount
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
- cover sold without a call.
- Trigger
- declared value above the standard cover
- Events and identifiers
- declared value above the standard cover. 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
- cover available for this lane? (your booking system) · your system adds cover. 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: ships as booked. 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
- cover sold 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 · 06Illustrative journey
Turn three ad-hoc pickups into a subscription.
A third pickup booked in one week asks your system whether the shipper is already on a contract, then sends one WhatsApp with Daily pickup or Not now; a tap sets it up in your system and confirms the first collection.
- Decides
- your contract rules; the shipper.
- Aim
- ad-hoc volume moved onto a standing pickup.
Built in the journey builder
Turn three ad-hoc pickups into a subscriptionLOGISTICSYour system confirms the shipper is not on a contract before the offer goes.
Campaign Start · APIThird pickup booked this week
API CallOn a contract already? Ask your system
Not on contract
Already on contract
WhatsApp FlowWhatsApp: Daily pickup / Not now
Daily pickup
Not now
No reply
API CallYour system sets up the subscription
Message · WhatsAppFirst collection confirmed
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
- ad-hoc volume moved onto a standing pickup.
- Trigger
- third pickup booked this week
- Events and identifiers
- third pickup booked this week. 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
- on a contract already? (your system) · your system sets up 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 until next month. 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
- ad-hoc volume moved onto a standing pickup. 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 slipped delivery into a choice the consignee makes.
A delivery that slips in your dispatch system sends one WhatsApp with Deliver tomorrow or Pick a slot; tomorrow updates your system and confirms by SMS, a slot fetches the open options from your system, and silence becomes a call.
- Decides
- your dispatch system; the consignee.
- Aim
- fewer failed deliveries and fewer calls.
Built in the journey builder
Reschedule a deliveryLOGISTICSYour own system answers mid-journey.
Campaign Start · APIDelivery slipped (from your system)
WhatsApp FlowWhatsApp: Deliver tomorrow / Pick a slot
Tomorrow
Pick a slot
No reply
API CallUpdate your system
Message · SMSConfirm by SMS
End
API CallFetch open slots from your system
Button ClickedCustomer picks
End
IVR CallVoice 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
- fewer failed deliveries and fewer calls.
- Trigger
- delivery slipped (your dispatch)
- Events and identifiers
- delivery slipped (your dispatch). 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
- tomorrow: update your system, SMS confirm · slot: open slots from 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
- fewer failed deliveries and fewer calls. 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
Answer the tracking page before it becomes a call.
A session with the tracking page opened three times in an hour and no slot chosen fetches the rider's window from your dispatch system and sends it by push over our own network, with SMS if the push is not delivered.
- Decides
- your session rule; your dispatch system.
- Aim
- fewer where-is-my-parcel calls.
Built in the journey builder
Answer the tracking page before it becomes a callLOGISTICSThe rider's window from your dispatch, by push over our own network, SMS if not delivered.
Campaign StartTracking page opened 3 times, no slot
API CallRider's window from your dispatch
Push + InboxPush with the window, own network
Delivery StatusDelivered?
Yes
No
End
Message · SMSSMS with the same window
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 where-is-my-parcel calls.
- Trigger
- session rule: tracking page opened 3 times, no slot
- Events and identifiers
- session rule: tracking page opened 3 times, no slot. 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
- rider's window (your dispatch). 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 when the parcel is delivered. 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 where-is-my-parcel calls. 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
Fix the address before the van leaves the hub.
An address your dispatch system cannot map at the hub sends one WhatsApp asking the consignee to share a location or confirm the address; the pin is written back and the parcel released, silence becomes a call, and the parcel is held with an SMS if nobody answers.
- Decides
- your dispatch system; the consignee.
- Aim
- fewer address failures on the first attempt.
Built in the journey builder
Fix the address before the van leaves the hubLOGISTICSA shared location is written back before the parcel is released; silence becomes a call.
Campaign Start · APIAddress not mappable at the hub
WhatsApp FlowWhatsApp: Share location / Address is right
Location shared
Address is right
No reply
API CallPin written back, parcel released
End
API CallReleased with a note for the rider
End
IVR CallCall, keypad confirms the address
Message · SMSHeld at the hub, SMS with hours
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 address failures on the first attempt.
- Trigger
- address not mappable at the hub (your dispatch)
- Events and identifiers
- address not mappable at the hub (your dispatch). 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
- location: pin written back, released · right: released with a rider note. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- The message is delivered on the first channel that reports delivery, or the fallback order is exhausted and the failure is recorded.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; when the last channel in the order has reported failure, the message is recorded as failed with the reason. Delivery callbacks that arrive late update the record when they arrive.
- Success metric
- fewer address failures on the first attempt. 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
Deliver the handover code as the rider arrives.
A rider-arriving event from your dispatch system sends the code by push over our own network to app users, falls back to SMS on the carrier's failure signal, and goes straight to SMS on the OTP lane for everyone else.
- Decides
- your channel order for the OTP lane.
- Aim
- codes that arrive while the rider is at the door.
Built in the journey builder
Deliver the handover code as the rider arrivesLOGISTICSPush over our own network for app users; SMS on the carrier's signal; the OTP lane for everyone else.
Campaign Start · APIRider arriving (from your dispatch)
ConditionApp user?
Yes
No
Push + InboxCode by push over our own network
Delivery StatusDelivered?
Yes
No
End
Message · SMSSMS on the carrier's failure signal
End
Message · SMSCode by SMS on the OTP lane
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
- codes that arrive while the rider is at the door.
- Trigger
- rider arriving (your dispatch)
- Events and identifiers
- rider arriving (your dispatch). 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 code. 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
- codes that arrive while the rider is at the door. 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.