A shipment tells you what will go wrong before it does. Act on it before the parcel comes back.
A second failed attempt at the same address. A tracking page opened five times in an hour. A shipper whose bookings thinned three weeks running. Most carriers record all three. Here each one starts a journey on the consignee's or the shipper's channel, asks your dispatch system first, and stops the moment the parcel moves.
The moments that matter.
Each one is a moment the platform can act on. Here is what it does.
- 01Your dispatch decides
A second failed attempt at the same address.
Your dispatch system gives the reason, and one WhatsApp offers a slot or hub collection; the tap is written back before the next run.
- 02Session rule
The tracking page opened five times in an hour.
A session rule sends the rider's window from your dispatch by push, and by SMS if the push is not delivered.
- 03Keypad reply
A cash-on-delivery order from a consignee who refused the last one.
A call captures the keypad answer before dispatch; Confirm releases the parcel and Cancel stops it, both written back.
- 04Write back
An address the rider cannot find.
One WhatsApp asks for a shared location; the pin is written back to your dispatch and the reattempt booked.
- 05Buttons
A rider ETA that moved after the window was promised.
A WhatsApp with Deliver tomorrow or Pick a slot; your dispatch system answers mid-journey with the open slots.
- 06Segment entry
A shipper whose bookings thinned, third week running.
The shipper enters a segment you defined and gets one message from the account owner, not a rate card. A reply reaches a person.
- 07Your rating engine
A quote calculated and never booked.
A session rule checks with your rating engine that the rate still stands, then sends it with a tap to book.
- 08Your system decides
A fragile or high-value item declared at booking.
Your booking system confirms cover is available for the lane and the value, and one WhatsApp offers it with a tap.
- 09OTP lane
A handover that needs a code at the door.
The code rides the OTP lane by push over our own network, with SMS on the carrier's failure signal, not a timer.
Signals from four places, one record per consignee and one per shipper.
Your dispatch system sends the scan, the attempt, the reason it failed, the cash-on-delivery outcome and the ETA by API. The tracking page and the app send what people do there, and the session itself. The status updates you already send become events. Every button tap, keypad answer and read receipt comes back to the same record.
Your status updates are already behaviour data.
A template declares which of its fields count as an event. The out-for-delivery text you send today becomes a shipment event with the status, the window and the attempt number, with no SDK and no release. Delivery history per consignee starts on day one, from the traffic you already send.
Catch the shipper who is leaving quietly.
No shipper cancels an account. The bookings thin, a lane goes quiet, the daily pickup becomes weekly. RFM on your booking events scores recency, frequency and revenue per shipper, segments on your own definitions catch each pattern, and entering a segment starts a journey. One message from the account owner, not a rate card, then silence.
Add cover when the item deserves it.
A declared value above the standard cover starts the journey. It asks your booking system whether cover is available for the lane and the value, and only then sends one WhatsApp with Add cover or Send as is. A tap goes to your system to add it before the parcel leaves the hub. No call, no blanket upsell, no offer on a lane you do not cover.
Sell the next service on the signal, not the rate card.
Three pickups booked in a week is a pickup subscription. A quote with a deadline in the notes is an express upgrade. A return declared at booking is a returns pickup. Each signal checks your system for what the shipper already holds and what the lane supports, then sends one offer on the channel they answer. If they do not act, the journey ends. Nobody gets the same offer twice.
Turn intent into a delivery.
The slot picker opened and closed with nothing chosen, the address edit started and never saved. A session rule sends the open slots your dispatch system holds, with a tap to choose. The journey stops the moment a slot is written back or the parcel is delivered.
See where the tracking page loses people.
The web tracker and the SDK capture what people do on the tracking page and in the app. Funnels show where reschedule, address change and hub collection stop. A session rule turns what did not happen into a trigger: the page opened three times with no slot chosen, an address edit started and never saved. Ask the question in plain language and get the answer this session, not a ticket.
Explain the delivery with Stories you can measure.
A text says one thing and reports one delivery. A Story on your tracking page, in your app or inside an email walks the consignee through how the day goes, the code at the door and how to pick a slot, page by page, and reports views, completion, the drop between pages, poll answers and form submissions. Delivery-day instructions, a returns walkthrough, a shipper onboarding: built in the builder, withdrawn in one action, no release.
Confirm the cash-on-delivery order before it leaves the hub.
Call the consignee, capture the keypad answer, escalate to WhatsApp, then SMS, if nobody picks up. Confirm releases the dispatch, Cancel stops it, and both are written back to your system. A branch per answer, a deadline per branch, a path for silence. The same shape serves address confirmation.
Handover codes on their own lane.
Codes, status updates and promotions go through the API today, each on its own channel order, escalation and dispatch rate. The delivery code escalates on the carrier's failure signal, not a timer, so a promotion burst never holds a rider at the door.
Reschedule from the message, written back before the rider moves.
Every reply that changes the plan goes to your dispatch system mid-journey. The journey asks for open slots, branches on the tap, and writes the chosen slot, the new pin or the hub collection back. The rider sees the change in your system, not in a screenshot.
Consent that survives the handover.
The shipper's customer becomes your consignee for one parcel. Delivery updates ride with the shipment. An offer or a Story checks consent for that channel first, and the record shows who gave it, when, and on which channel.
One record per shipment message.
When a consignee says nobody told them, the record shows the update, the channel, the attempts, the read and the tap, with the slot written back and the time it was written. Exportable, per shipment and per shipper.
A journey you could ship in the pilot.
Second attempt failed at the same address → reason? your dispatch → not home: WhatsApp Pick a slot / Collect from hub → slot: open slots from your dispatch → consignee picks → written back → SMS confirmation → address not found: share your location, pin written back → no reply: call.
Playbooks you can configure.
Ten journeys a carrier can configure, from the second failed attempt to the handover code at the door, each drawn as it runs in the builder.
- 01Rescue the second failed attempt before the parcel comes back.
- 02Confirm the cash-on-delivery order before it leaves the hub.
- 03Catch the shipper whose bookings are thinning.
- 04Turn the quote that was never booked into a booking.
- 05Add cover when the declared value deserves it.
- 06Turn three ad-hoc pickups into a subscription.
- 07Turn a slipped delivery into a choice the consignee makes.
- 08Answer the tracking page before it becomes a call.
- 09Fix the address before the van leaves the hub.
- 10Deliver the handover code as the rider arrives.
These are configurations you build in the pilot, not documented deployments.