COD Refusals Are a Solvable Operations Problem: A Plain Operator's Guide for KSA and UAE DTC Brands

If you are shipping direct-to-consumer into Saudi Arabia or the UAE, cash-on-delivery is not a legacy oddity you can engineer away. It is a material share of your order volume, and when those orders come back — refused at the door — the cost shows up on three lines at once: the outbound courier fee, the return courier fee, and the unsold inventory that has just circled once through your fulfilment centre.

This guide is not about AI transforming your logistics. It is about naming what is broken, measuring it properly, and applying fixes in the right order. Operator to operator.

Step one: name the record before you claim a fix

The most common mistake is treating refusal rate as a single number. It is not. It is a ratio with at least four distinct components, and conflating them produces the wrong remedies.

The record you need before any intervention:

• Orders shipped (COD), by courier, by region, by week
• Orders refused (returned-to-origin), with a reason code attached to each
• Reason codes, at minimum: customer not available, address not found, customer cancelled, customer refused price, no reason recorded
• Courier-level refusal rate = refused ÷ shipped, not refused ÷ total orders

If your courier does not supply reason codes, negotiate for them. If your WMS or OMS does not record them, add the field before you change anything else. A refusal rate without a reason-code breakdown is a number you cannot act on.

One note on reporting: if you are pulling refusal data from three systems — courier portal, OMS, and a spreadsheet someone maintains — you do not have one record. You have three estimates. Reconcile them to a single source of truth, then set a weekly cadence for reviewing it. That cadence is more important than the tool you use.

The single highest-leverage change: pre-ship verification

Most DTC brands in KSA and the UAE have not yet ratified a pre-ship verification step. This is the practice of contacting the customer — by WhatsApp message or voice call — between order placement and dispatch, to confirm the address and the delivery window.

Why it works: a large share of refusals in the Gulf fall into two buckets that pre-ship verification directly addresses. First, address problems — incomplete building references, missing apartment numbers, incorrect city districts. Second, customer-not-available failures — the order ships to a time window the customer cannot honour.

What a verification step looks like in practice:

• Order is placed (COD, any value).
• Address check against your customer record — flag any order where the address has failed delivery before, or where the district-to-postcode mapping is ambiguous.
• Send a templated WhatsApp message within two hours of order placement: confirm the address, offer two delivery-window options, give the customer a one-tap way to switch to card payment.
• If no response within four hours, attempt a single voice call.
• Log the outcome (confirmed, updated address, cancelled, no response) against the order record.
• Dispatch only orders with a confirmed or updated address. Hold no-response orders for an additional window before dispatching — your operations team decides the threshold.

The human ratify step is explicit here: the system drafts and sends the message, but the dispatch decision — and any exception handling — stays with your ops team. That is not a limitation. It is how you keep accountability in the right place.

A note on conversion: some operators worry that a verification step adds friction that kills orders. The evidence from brands that have implemented it is mixed, and we will not quote a lift we cannot cite to a specific tenant record. What is consistent: customers who confirm a COD order pre-ship have a materially lower refusal rate than those who do not. Customers who cancel during verification were likely to refuse at the door anyway. The verification step moves the cancellation earlier — before you have paid for the outbound shipment.

Partial prepayment nudges: shift refusal rates without killing conversion

A small deposit or wallet credit at checkout is not a payment-model overhaul. It is a commitment device. A customer who has paid even a nominal amount to place an order has a tangible reason to be available at delivery.

Three formats that DTC brands in the region have tested:

• Fixed deposit (e.g., a flat amount held at order, deducted from COD at door): reduces no-show refusals; requires a payment gateway that supports partial auth or a manual reconciliation process.
• Wallet credit for card-on-file: offer the customer a small credit — applied to their next order — if they switch to card payment now. Positions the ask as a benefit to them, not a demand from you.
• Discount for card-on-file: a percentage off the current order for switching. Higher conversion lift, higher cost; model it against your average refusal cost per order before setting the discount level.

Whatever format you choose: publish the before/after in your own reporting, not as a public promise. If the nudge reduces your refusal rate, that is your record. If it does not, adjust the threshold or the offer. Do not claim a reduction you have not measured.

One practical limit: partial prepayment nudges do not fix address problems or customer-not-available failures. They address the small share of refusals that are genuinely price-motivated — customers who placed a COD order speculatively and decided against the purchase. Combine the nudge with verification; do not substitute one for the other.

Address quality and delivery-window accuracy: fix the data capture first

Address failure is, in the Gulf context, a structural problem. Postcode coverage is incomplete. Building references are non-standard. Many residential addresses rely on landmarks that are not machine-readable. This is not a courier problem you can solve by switching providers — it is a data capture problem you solve at checkout.

Minimum changes to your address capture form:

• District / neighbourhood as a required field, with a drop-down mapped to your couriers' zone definitions — not a free-text field.
• Building name or number as a required field.
• Apartment or flat number as a required field where applicable.
• Landmark field as optional but explicitly labelled ("nearest landmark, if your building is not numbered").
• Phone number verification at checkout — one-time PIN — so the number on the COD order is confirmed before dispatch.

Delivery-window accuracy is a separate but related problem. Many refusals coded as "customer not available" are actually "customer was not told an accurate window." If your courier promises next-day and delivers in two days without notifying the customer, the customer may not be home. Audit your courier's stated SLA against your actual delivery timestamps over a 90-day period. The gap, if there is one, belongs on your courier scorecard.

Courier scorecard format:

• Courier name
• Shipments (period)
• Refusals (period)
• Refusal rate (%)
• Top three reason codes
• Average transit time vs. stated SLA
• Last reviewed date

Review this monthly. If a courier's refusal rate on a specific reason code is consistently above your threshold, that is a conversation with the courier account manager — with data — not a gut-feel decision to switch providers.

Running a courier scorecard: what to put in it and what to do with it

A courier scorecard is only useful if it is reviewed on a fixed cadence by someone with authority to act on it. The cadence matters more than the format.

What to do with the scorecard:

• If refusal rate is above your threshold: open a formal review with the courier, share the reason-code breakdown, ask for their explanation and their remediation plan. Document the response.
• If the top reason code is "address not found": the problem is yours, not the courier's. Fix the data capture before the next review.
• If the top reason code is "customer not available": audit the delivery-window communication, and check whether pre-ship verification is running for those orders.
• If the top reason code is "customer refused" with no sub-code: negotiate for more granular reason codes from the courier. "Customer refused" is not actionable.
• If a courier's rate is consistently above threshold with no improvement over two review cycles: that is a business conversation about volume allocation.

The scorecard is a record, not a verdict. Use it to have evidence-cited conversations, not to make changes in reaction to a single bad week.

Where Jurnies fits — and what we will not promise

Jurnies builds the refusal dashboard, the pre-ship verification journey, and the partial-prepayment nudge flow inside one customer record. Joe — the AI — drafts the verification message, the recovery journey sequence, and the dashboard layout. You ratify each one before it goes live. Joe answers for the result in the sense that every action it takes is logged, visible, and traceable to the decision you approved.

What Jurnies records as live today: one journey canvas, one customer record, one revenue dashboard, Joe drafts and you ratify before dispatch.

What we will not promise: a specific reduction in your refusal rate. We do not have a tenant record that authorises that claim for your operation. What we can tell you is what the system records, what Joe drafted, what you ratified, and what the order-level outcome was. That is the evidence trail. You own the decision.

If you want to pause the AI — stop Joe from drafting new verification messages while you review a courier incident, for example — that is a sixty-second change in your account settings. We built the pause function precisely because "the AI is running and I cannot stop it" is not a position any operator should be in.

We also will not tell you there is no setup involved. Connecting your OMS, mapping your courier reason codes, and configuring your address-check rules takes time. We will tell you what that time looks like on a real implementation, not an optimistic one.

The short version

COD refusals are a measurable operations problem. The fixes are not novel, but they have a sequence:

• Build the record: reason-coded refusal data, by courier, by region, by week.
• Fix the data capture: address fields, phone verification, landmark support.
• Add pre-ship verification: WhatsApp or voice, with a human ratify step before dispatch.
• Layer in prepayment nudges: model them against your actual refusal cost before setting the offer.
• Run the courier scorecard on a fixed cadence: use it to have data-cited conversations, not to react to single weeks.

If you are using Jurnies, Joe can draft steps two through five. You ratify. If you are not using Jurnies, the sequence is the same. Start with the record.