COD · Risk screening
WorkflowD2C brandsScreening risky COD orders before they leave the warehouse
Most COD orders are fine. A few have a half-written address, a buyer with three returns to origin, or a pincode the courier struggles with. These notes cover a workflow that holds those orders for a check and never cancels one on its own.
Valnora & Elric team6 min read
A return to origin on a COD order costs two shipping legs and keeps a unit of stock out of sale for days. Some of those returns can be seen coming before the parcel leaves: an address with no house number, a phone number with two earlier RTOs, a pincode where your courier rarely delivers first time, a large order from a first-time buyer.
These notes describe a screening workflow in Agent Serve that looks at each COD order before dispatch, scores it with rules a person wrote, and holds the risky ones for a check. Its most important rule is what it never does: it never cancels an order without a person approving it. Thresholds and amounts below are illustrative.
Why written rules and not a black-box score?
Ops teams already have instincts about risky COD orders. The trouble is that those instincts live in a few people’s heads, and they change with the shift. Writing them down as Rules, plain-language checks that pass, fail or flag a record, makes them the same at 2 am as at 2 pm, and lets anyone see why an order was held.
A starting set might be:
- Address quality. No house, flat or plot number, or only a landmark: +3. Address shorter than a set length: +1.
- Past RTO on this number. One earlier COD return to origin: +1. Two or more: +2.
- Pincode. RTO share for that pincode above 25% last quarter in your own data: +1.
- Order value. Above ₹5,000 on COD: +1. First order from this number and above ₹5,000: +1 more.
A score of 5 or more holds the order. Below that, it ships as normal. Every rule writes a short reason, so the score is never a bare number.
How does an order reach the screen?
Shopify has no Agent Serve trigger, so in Shopify admin you create an orders webhook pointing at the Webhook trigger of a workflow. The workflow stops for prepaid orders and carries on for COD.
It then gathers three things:
- The address, from the order. An Agent block reads it and answers one narrow question: does it contain a house or flat number, a street, and a locality? It returns yes or no and the part it found missing. It does not judge the buyer.
- The buyer’s history, from Shopify List orders by phone number, joined with your delivery outcomes table in Tables to see which past orders came back.
- The pincode’s RTO share, from the same delivery outcomes table. If you already run non-delivery follow-up, that workflow is writing these rows.
What happens to a held order?
Score, hold, confirm, decide
Workflow · Screen
- 01Shopify order webhookShopify sends each new order to the workflow’s Webhook trigger.
- 02History lookupsPast orders for the phone number, and the pincode’s RTO share from your own delivery table.
- 03Screening rulesPlain-language checks for address, history, pincode and value, each adding points and a reason.
- 04Tag and noteShopify tags cod-clear or cod-hold, with the reasons in the order note.
Hold queue · People
- 05Ask the buyerAn approved WhatsApp template asks the buyer to confirm or fix the address.
- 06Cancel needs approvalA Human in the loop step pauses the run; only an ops lead can approve a cancellation.
- 07Ops leadReleases, edits the address, asks for prepaid, or approves the cancel.
The workflow uses the Shopify order update, which covers note, tags and email. It adds a cod-hold tag and writes the reasons into the order note, so the warehouse sees the hold in the tool it already uses and does not pack the order.
Then it asks the buyer. An approved WhatsApp template, sent with Send Template, says the order is ready and asks them to confirm the full address with a reply. Address replies are added to the order note and the order is tagged for a person to edit the shipping address; the Shopify update cannot change the address itself.
What the solution produces
Screening result on a held order (illustrative)
Record- Order
- #62018 · ₹6,480 · COD · pincode 8xxxxx
- Score
- 7 of 10 · Hold
- Address
- +3 · No house or flat number; landmark only ("near bus stand").
- History
- +2 · Two earlier COD orders on this number, both RTO.
- Pincode
- +1 · RTO share above your 25% threshold last quarter.
- Value
- +1 · Above the ₹5,000 COD review line.
- Action taken
- Tagged cod-hold. WhatsApp sent asking for the full address. Not cancelled.
If you already confirm every COD order, as in COD order confirmation on WhatsApp, the screen changes the tone rather than adding a second message: held orders get the address-focused template, and clear orders get the normal one.
Who decides whether to cancel?
A person, always. The hold queue is a filtered view of the screening table, one row per held order with its score and reasons. The ops lead on shift has four choices:
- Release the order once the buyer confirms or the address is fixed.
- Ask for prepaid, by sending the buyer a payment link from your own gateway. Payment gateways such as Razorpay are not native integrations; the API block can create the link with a key stored as a workspace secret.
- Keep holding while waiting for the buyer.
- Cancel, which goes through a Human in the loop block. The run pauses, shows the order and the reasons, and only proceeds to the Shopify cancel, with restock and the customer notice on, when the ops lead approves.
There is no timer that cancels on its own. An order nobody has acted on stays on hold and stays visible, which is a nudge to staff the queue, not a reason to cancel.
How do you know the rules are fair and working?
Run the screen in tag-only mode for the first two weeks. It scores and notes every COD order but holds nothing, so you can compare scores with what actually came back.
A small dashboard on the screening table then answers the questions that matter: share of orders held, share of held orders that confirmed and delivered, RTO rate by score band, and which rule fires most. If the "landmark only" rule holds many orders that then deliver fine, loosen it. If high-score orders that shipped anyway keep coming back, tighten the threshold.
Two guardrails are worth writing into the rules themselves. Do not score on the buyer’s name or on anything that stands in for who they are; score the order and its delivery history. And review the pincode rule each quarter, because a courier change can fix a pincode overnight.
What keeps the record straight?
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.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
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.
More on how Agent Serve handles access, data and audit on the security page.
Every run is in Logs with each block’s input and output, so when a buyer asks why their order was delayed, support can see which rule held it. Phone numbers and addresses can be masked in logs with PII redaction. Rule changes are made in a reviewed, deployed version of the workflow, so the threshold that held yesterday’s orders is on record.
What you need
- A Shopify orders webhook pointed at the workflow, and an app token that can read orders and update tags and notes
- A delivery outcomes table with past orders and RTO results, for example from your NDR follow-up workflow
- Your screening rules written out in plain words, with points and a hold threshold agreed by ops and finance
- An approved WhatsApp template for address confirmation
- A named ops lead per shift to work the hold queue and approve any cancellation
Questions teams ask
Does the workflow ever cancel an order by itself?
No. The workflow tags, notes and asks. Cancelling goes through a Human in the loop step, and only a person can approve it. If nobody acts, the order stays on hold and appears in the queue.
Is this a fraud model?
No. It is a set of written rules your team can read and change, scored the same way every time. An Agent block helps only with reading the address, and its reason is shown on every order.
Can we use our courier’s serviceability or RTO data?
Couriers and aggregators are not native integrations. If yours offers an API for pincode serviceability, call it with the API block and a key stored as a workspace secret, and add the answer to the pincode rule.