How CNetworQ designed, built and now operates a multi-carrier e-commerce logistics platform — from a single pickup request to COD money landing back in a seller's account.
10M+
Shipments delivered
22,000+
Pincodes covered
10K+
Sellers & brands
100+
Cities served
A seller shipping across India cannot use one carrier. Coverage, pricing and reliability vary enormously by region, by pincode, and by whether a parcel is prepaid or cash-on-delivery. So most sellers end up juggling three or four courier partners at once.
That fragmentation is where the cost hides. Every carrier has its own panel, its own tracking format, its own returns process and its own remittance cycle. The operational load does not scale with revenue — it scales with the number of carriers, which is exactly the wrong thing to grow.
The design decision that shaped everything else: WePicks does not try to replace courier networks. It sits above them. Sellers integrate once, and the platform decides which carrier moves each parcel, tracks it in a single normalised format, and handles the money at the end.
That framing turned a logistics problem into a software problem — which is the kind we are equipped to solve.
Orders arrive from the seller's store, marketplace or a direct API call and are normalised into a single internal shipment record — so everything downstream works off one shape of data regardless of where the order came from.
The platform checks which carriers actually service the destination pincode, then scores the eligible ones on cost, expected transit time and recent delivery performance on that lane. The AI allocation layer picks the winner. This is the single highest-leverage decision in the whole pipeline — get it right and NDR rates, transit times and cost all improve together.
Pickup is scheduled with the chosen carrier, labels and manifests are generated, and the shipment enters the tracking pipeline. The seller does not touch a carrier panel.
Every carrier reports status differently. The platform maps each carrier's scan codes onto one internal status model, so the seller — and their customer — see one consistent journey whoever is carrying the parcel.
When a delivery fails, the clock starts. The platform flags it immediately, triggers customer contact to confirm address or reschedule, and pushes the reattempt back to the carrier — instead of letting the parcel drift toward an automatic RTO.
Reverse pickups are treated as a first-class flow with their own tracking and states, not as a failure case bolted on at the end.
Cash collected on delivery is matched back to the originating order automatically, reconciled against each carrier's remittance statement, and paid out on a predictable cycle. For a COD-heavy seller this is often the feature that matters most — it is their working capital.
No two carrier APIs agree on anything — not authentication, not rate limits, not status codes, not how a failed delivery is expressed. We built an adapter per carrier and a single canonical shipment model behind them, so adding a new carrier is an adapter, not a rewrite. Everything upstream of that boundary stays untouched.
Carrier selection has to happen in the request path, against live serviceability data, using historical performance per lane. The scoring model weighs cost against expected transit time and recent success rate on that specific origin–destination pair, and it has to stay fast while the shipment table grows into the millions.
COD is the part where software mistakes become real financial disputes. Every rupee collected has to tie back to a specific shipment, survive carrier statement mismatches, and produce an auditable trail. We treated the COD ledger as a financial system rather than a reporting feature — append-only records, explicit reconciliation states, and no silent corrections.
“FILL: quote from your ops or engineering lead about what the platform changed — 1–2 sentences”
— FILL: Name, Role, WePicksThese are the numbers worth publishing once you pull them — they are the ones prospective sellers actually ask about:
Most agencies have never had to live with their own code at scale. WePicks means we run a production platform where a bug costs us money, an outage costs a seller their peak-season revenue, and a reconciliation error turns into a support call. That changes how we build for everyone else.
When we advise a client on architecture, integration boundaries or how to structure an operations system, it comes from having done it under load — not from a slide deck.
If your operations have outgrown spreadsheets and vendor panels, that is the kind of problem we take on. Tell us what is breaking.
Talk to our team
© 2026 CNetworQ Private Limited. All Rights Reserved
