Logistics · RTO and NDR
Multi-workflowD2C logisticsCutting RTO by following up every non-delivery report the same day
Most returned-to-origin parcels had a failed delivery attempt first, and nobody asked the buyer what went wrong. This playbook catches every non-delivery report, asks the buyer, and sends the answer back to the courier before the next attempt.
Valnora & Elric team5 min read
- Format
- Playbook
- Steps
- 6
- Solution
- Multi-workflow
- Parts used
- 6
A parcel rarely goes straight from "out for delivery" to "returned to origin". In between, the courier logs a non-delivery report (NDR): buyer not reachable, address incomplete, refused, asked to come later. Aggregators usually allow a re-attempt if someone responds in time. Often nobody does, and after the last attempt the parcel starts its trip back.
This playbook closes that gap in Agent Serve. It assumes you already confirm COD orders before dispatch, as in COD order confirmation.
Step 1: Get NDR events into a table
Courier aggregators such as Shiprocket, Delhivery and iThink Logistics are not native integrations. You connect them with the API block, which sends HTTP requests with your API key stored as a workspace secret.
There are two ways in, and you pick based on what your aggregator offers:
- Webhook. If the aggregator can push status updates, point it at the Webhook trigger of a workflow in the workflow builder. Each NDR arrives as it is logged.
- Schedule. If not, a Schedule trigger runs every 30 minutes and the API block pulls shipments in NDR status since the last run.
Either way, write one row per NDR event to a table in Tables: AWB, order number, courier, pincode, the aggregator’s reason code, attempt number and buyer phone. Map reason codes to your own short list (not reachable, address issue, refused, reschedule requested, other) so couriers can be compared.
Step 2: Ask the buyer on WhatsApp, quickly
Speed matters more than polish. In the same workflow, send an approved WhatsApp template with Send Template, with quick-reply buttons for Deliver tomorrow, Update address and Cancel order. Use the buyer’s pincode and the reason code in the text so they know you are not guessing.
Skip buyers without WhatsApp opt-in and send a Twilio SMS instead. Skip "refused" reasons on prepaid orders, which usually need a person to talk to the buyer.
What the solution produces
WhatsApp message after a failed attempt (illustrative)
MessageHi Arjun, our courier could not deliver your Kaveri Studio order #51877 today.
Reason given: customer not reachable.
Delivering to: B-204, Sector 62, Noida 201309
What would you like us to do?
[Deliver tomorrow] [Update address] [Cancel order]
NDR record after the buyer replied (illustrative)
Record- AWB
- 1490 2238 7741 · Courier B · attempt 1
- Reason code
- Customer not reachable
- Buyer reply
- Deliver tomorrow, call after 1 pm, gate 2
- Sent to courier
- Re-attempt with remarks, accepted by the aggregator API
- Pincode status
- 201309 · RTO 8% · normal
- Outcome
- Delivered on attempt 2
Step 3: Push the answer back to the courier
A second workflow starts on the WhatsApp webhook trigger. An agent block reads the reply, including free text like "call after 1 pm, gate 2", and turns it into one of four actions: re-attempt, re-attempt on a date, re-attempt with address detail, or return.
Many aggregators expose an NDR action endpoint for exactly this. The API block posts the action with the remarks. If yours does not, the workflow writes the answer to the table and alerts the ops person who updates the courier panel. Either way the buyer gets a reply confirming what happens next.
Step 4: See the pattern on a dashboard
From non-delivery report to rescheduled attempt
Workflow 1 · Catch the NDR
- 01Webhook or scheduleThe aggregator’s NDR webhook hits a Webhook trigger, or a schedule polls its API every 30 minutes.
- 02API blockCalls the aggregator’s API with a key stored as a workspace secret. Not a native integration.
- 03NDR tableAWB, order, courier, pincode, reason code, attempt number, buyer phone.
- 04WhatsApp to buyerTemplate asking to confirm address, pick a new day or cancel.
Workflow 2 · Send the answer back
- 05WhatsApp triggerThe buyer’s reply arrives through the WhatsApp webhook trigger.
- 06Read the replyMaps the reply to re-attempt, new date, address detail or cancel.
- 07Courier NDR actionPosts the action to the aggregator’s NDR endpoint with the API block, where it offers one.
Dashboard · NDR and RTO
- 08Risky pincode ruleFlags pincodes whose RTO rate stays above your limit over enough shipments.
- 09NDR dashboardReasons by courier and pincode, response rate, saved vs returned.
- 10MonitorAlerts ops when a courier’s NDR rate jumps in one region.
The NDR table feeds a dashboard with:
- NDR reasons by courier and by pincode cluster.
- Buyer response rate to the WhatsApp message, and how many NDRs became deliveries.
- RTO rate by courier for the same pincodes, so you compare like with like.
A monitor re-checks as often as every 5 minutes and alerts ops if one courier’s NDR rate jumps in one region. That is often a hub problem, not a buyer problem, and worth a call to the courier’s account manager the same day.
Step 5: Flag risky pincodes with a rule
Some pincodes return a large share of COD parcels whatever you do. A rule in plain language, for example "RTO rate above 30% over at least 50 COD shipments in the last 60 days", flags them.
The rule does not change your checkout. Your team uses the flagged list in whatever COD settings or checkout app you already run to offer prepaid only, or feeds it into the confirmation workflow so those orders always get a call. Review the list monthly; a new courier or hub can change it.
Step 6: Keep the record
Controls and governance
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
More on how Agent Serve handles access, data and audit on the security page.
Every run is in Logs with inputs and outputs, which helps when a courier disputes an NDR reason. Mask buyer phones and addresses in logs with PII redaction. Row-level access lets a 3PL partner see their own shipments only.
Questions teams ask
Is Shiprocket or Delhivery a built-in integration?
No. Courier aggregators and couriers are connected through the generic API block, which sends GET, POST, PUT, PATCH or DELETE requests with your key stored as a workspace secret. Where a provider offers an MCP server, you can also connect it under Settings → Tool connections.
What if the aggregator has no NDR action endpoint?
Then the second workflow writes the buyer’s answer to the NDR table and alerts the ops person who updates the courier panel. You still gain the conversation with the buyer and the record.
Will Agent Serve switch pincodes to prepaid-only for me?
No. The rule produces the list. Your team applies it in the checkout or COD settings you already use, or feeds it into the COD confirmation workflow so those orders get a call before dispatch.