Cash-on-Delivery Return Analytics for Small Online Sellers

The problem sellers face with returned COD parcels

Small online sellers in Pakistan, India, the Gulf and much of Africa still take a large share of orders as cash on delivery. When the customer refuses the parcel, is not home, or gave a fake number, the parcel travels back to the seller. The seller pays forward and reverse shipping, the stock is stuck in transit for a week or two, and packaging is often damaged. Most small sellers only find out how bad the problem is at month end, when the courier settlement arrives with deductions.

The data to understand this exists, but it is scattered. The store platform has the orders. Each courier portal has its own export with its own status names ("Refused", "RTO Initiated", "Returned to Shipper", "Consignee not available"). Sellers who use two or three couriers end up pasting CSVs into Excel and guessing.

What already exists and the gap

• GoKwik (India) offers checkout and RTO risk tools for direct-to-consumer brands, including actions like blocking COD or adding a fee for risky orders. It is aimed at brands on its checkout network.
• Shiprocket and ClickPost give shipment tracking and some return analytics across couriers, mainly for Indian merchants.
• Courier portals such as those of local couriers give per-courier reports, but each one only sees its own parcels.
• Shopify analytics knows the order, not what happened at the doorstep.

The gap: a small seller who uses local couriers outside those networks has no tool that joins store and courier data, explains where returns come from, and lets them test a policy on their own history before changing it. That joining and explaining is the data work this project is about.

What you build

A web app with two roles: seller (uploads or connects data, views reports, tests policies) and admin (manages courier status mappings and importer versions).

Main flows:

1. The seller uploads a store export and courier exports, or connects a store API.
2. The pipeline normalises everything into one model: order, shipment, delivery attempt, final outcome, cost.
3. The dashboard shows return rate and money lost, sliced by city, courier, product, order value, time of day ordered and customer history.
4. For each new COD order, the app gives a risk score and reasons ("new customer, high order value, city with 2x the seller's average return rate").
5. The policy simulator replays the last few months under a rule and reports trade-offs.

The technically interesting part

Two things make this more than a dashboard. First, status harmonisation and entity matching: each courier uses different codes, some parcels have several attempts, and order IDs are not always copied correctly into the courier's reference field. You need a mapping table, a matching step (order number, phone, amount, date window) and a report of unmatched records, the same reconciliation pattern payment teams use to match bank payouts to individual charges.

Second, honest evaluation of the risk score. Returns depend on time (festivals, sales, rain), so a random split leaks the future. Use a rolling time-based split, report precision at the threshold a seller would actually use, and show a calibration plot so "70% risk" means roughly 70%. Your supervisor will want to see that the simulator's savings estimate is built on the holdout period, not on training data.

How to evaluate it

• Matching quality: on 300 hand-labelled order/shipment pairs, report the share correctly matched and the share left unmatched.
• Model: precision, recall and PR-AUC on the most recent month, compared with a simple baseline (city return rate only).
• Calibration: Brier score and a reliability plot.
• Pipeline: time to process 50,000 orders on a laptop; every dbt test passing.
• Users: three or more real sellers use it on their own data; record which decisions they would change and time saved versus their spreadsheet.

Suggested plan

1. Weeks 1 to 3: interview sellers, collect anonymised exports, list all courier statuses.
2. Weeks 4 to 7: importers, status mapping, dbt models and tests.
3. Weeks 8 to 11: dashboard and unmatched-record report; first seller feedback.
4. Weeks 12 to 17: feature engineering, time-based evaluation, risk score with reasons.
5. Weeks 18 to 22: policy simulator and calibration.
6. Weeks 23 to 28: seller trials, evaluation report, write-up.

Path to a product

The first customer is a small seller doing a few hundred COD orders a month on Instagram, Daraz-style marketplaces or their own store. Charge a flat monthly fee per store, with a higher tier for multi-courier sellers. Couriers and fulfilment companies are a second market: they could white-label the dashboard for their merchants. Scale by adding importers for more couriers and a store app listing.

Scope warning

Do not build your own checkout, a courier booking system or a payment gateway. Do not scrape courier portals; use exports the seller downloads or official APIs. Never share one seller's customer data with another seller, so no shared "blacklist" of customers.

Learn what you need on Sefism

• Data Analytics roadmap : SQL, modelling and dashboards in the order you need them.
• Data Analytics cheat sheet : quick reference for joins, window functions and metrics.
• dbt Documentation : models, tests and sources for the pipeline.
• DuckDB Documentation : fast local analytics on CSV exports.
• Kimball Dimensional Modeling Techniques : designing the order and shipment fact tables.

Get help with this idea

The hardest calls here are how many couriers to support and how to split data so the risk score is honest. If you want a second opinion on scope, stack or how to evaluate it before you pitch it to your supervisor, a mentor can help you shape it. You still build it; the guidance is about making the plan realistic and the results defensible. New here? create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session