Why Your eCommerce Product Is Losing Money Between the Cart and the Warehouse (And How to Fix It)
The Problem Is Not Your Checkout
Every eCommerce team I have worked with obsesses over conversion rate optimisation. A/B testing headlines, tweaking button colours, shaving seconds off page load time. And they should — it matters. But in my experience working with 40+ retail and eCommerce brands on their product and operations architecture, the most expensive problems rarely happen before the checkout. They happen after it.
The moment a customer clicks ‘Order Now,’ they enter the operational product — the invisible system of order management, inventory allocation, warehouse communication, fulfilment routing, and returns logic. For most eCommerce businesses, this system is a patchwork of disconnected tools, manual processes, and workarounds that have accumulated over years. And that patchwork has a cost that rarely appears on the product roadmap.
The Five Places eCommerce Revenue Leaks Operationally
- Inventory Overselling and Stockout Failures
- Fulfilment Routing Inefficiency
- Returns Processing as an Afterthought
- Carrier Integration Brittleness
- Data Fragmentation Across the Order Lifecycle
Your eCommerce product does not end at the checkout. It ends when the return is processed and the refund lands. Every step in between is a product decision
1. Inventory Overselling and Stockout Failures
Real-time inventory accuracy is harder than it sounds at scale. When you are selling across a website, a marketplace, a physical store, and a wholesale channel simultaneously, inventory records can desynchronise in minutes. An order comes in for an item your system shows as in stock, but that stock is already committed to a marketplace order that has not synced yet. The customer gets an out-of-stock notification after checkout. The experience is broken. The trust is damaged.
The technical fix is a centralised inventory management system with atomic reservation logic — the moment an order is placed, inventory is reserved in real time, not after it is picked. But the more important fix is the product architecture: knowing which channel has authority over which SKU pool, and designing the data flow accordingly before you scale to additional channels.
2. Fulfilment Routing Inefficiency
For multi-warehouse operations, which warehouse fulfils which order is not a logistics decision — it is a product decision. Most teams treat it as the former. Routing logic — factoring in warehouse proximity, current stock levels, carrier SLAs, order priority, and cost — needs to be designed as a configurable rules engine, not left to a logistics manager making manual decisions in a spreadsheet.
The difference between optimised automated routing and manual routing is measurable in both cost per order and customer satisfaction scores. Automated routing is not just faster — it applies rules consistently, which means it scales.
3. Returns Processing as an Afterthought
Returns in eCommerce are not an edge case. For apparel, returns can run 20–40% of orders. Yet most eCommerce product teams design returns as an afterthought — a basic form that dumps a return request into someone’s inbox, with no automated inspection logic, no refund trigger, no inventory re-integration.
A properly designed returns flow is: customer initiates return with reason code → automated eligibility check against return policy → carrier label generation → return received and inspected → inventory decision (restock, quarantine, dispose) → refund triggered automatically. Every step should be in the product, not in someone’s email queue.
4. Carrier Integration Brittleness
Most eCommerce operations start with one or two carrier integrations and then discover they need more as volumes grow. If those integrations are built directly into the core order management system rather than through an abstraction layer, adding a carrier means an engineering project. Switching a carrier means another engineering project.
Building a carrier abstraction layer — where the business can configure carrier selection rules and add new carriers without code deployments — is the kind of product architecture decision that looks like over-engineering on day one and looks like the best decision you ever made on day 300.
5. Data Fragmentation Across the Order Lifecycle
Where did the customer come from? What did they buy? When did it ship? When did it arrive? Did they return it? Why? Most eCommerce businesses cannot answer all of these questions from a single system. Acquisition data is in the marketing platform. Order data is in the OMS. Shipping data is in the carrier portal. Returns data is in a spreadsheet. The result: no one has a complete view of the customer order lifecycle, and decisions about assortment, supplier performance, and carrier quality are made on partial data.
What a Modern eCommerce Product Architecture Looks Like
- Centralised Order Management System (OMS)
- Real-time Inventory Service
- Configurable Fulfilment Rules Engine
- Carrier Abstraction Layer
- Returns Management System
- Unified Data Warehouse
The eCommerce platforms I have helped design or restructure share a common architectural pattern — one that treats the entire order lifecycle as a product surface, not just the storefront.
Centralised Order Management System (OMS): A single source of truth for all orders across all channels. Every order — web, marketplace, wholesale, POS — flows into the OMS. No channel maintains a private order queue.
Real-time Inventory Service: Inventory availability is computed in real time from a centralised service that all channels query. No channel holds its own inventory copy.
Configurable Fulfilment Rules Engine: Routing logic expressed as business rules that the operations team can configure without engineering. Who fulfils what, and why, is a business decision.
Carrier Abstraction Layer: Carriers plugged in through a standard interface. Adding a new carrier is a configuration task, not an engineering project.
Returns Management System: A structured flow with reason code capture, policy-based eligibility, automated label generation, inventory disposition logic, and automatic refund trigger.
Unified Data Warehouse: All order lifecycle data — acquisition, transaction, fulfilment, delivery, returns — in a central warehouse where it can be analysed as a complete picture.
The Marketplace Complexity Problem
If you are selling on Amazon, Lazada, Shopee, or any marketplace alongside your own storefront, operational complexity multiplies. Each marketplace has its own order format, SLA expectations, cancellation policies, and data schema. Keeping your OMS synchronised with multiple marketplace order streams is one of the highest-failure-rate integrations in eCommerce.
The teams that manage this well have designed their marketplace integrations through a normalisation layer — incoming marketplace orders are transformed into a canonical order format before entering the OMS. The OMS does not know or care whether an order came from your website or a marketplace. This normalisation is a product architecture decision that needs to be made before you integrate your second channel.
When to Build vs. When to Buy
If your competitive advantage is product curation, brand, or customer acquisition — buy an OMS. Use Shopify, Linnworks, or a comparable platform. Your engineering team’s time is better spent on your differentiation, not on order management infrastructure.
If your competitive advantage is operational efficiency — custom routing logic, complex multi-warehouse management, proprietary supplier integrations — you will eventually need to build core OMS components. But buy first, customise second, build third. The operational complexity of an OMS is almost always underestimated.
Scale Does Not Create These Problems. It Reveals Them.
The eCommerce businesses that scale cleanly made the right product architecture decisions at 10,000 orders per month that held up at 100,000 orders per month. The ones that struggle at scale almost always point to the same root causes: an OMS not built for multi-channel, inventory management that was not real-time, and fulfilment routing that was never automated.
The revelation usually happens at the worst possible moment — peak season, a viral product launch, or a new channel integration that breaks the old ones. The investment in operational product architecture at 10,000 orders per month is the most leveraged investment you can make. It does not show up in your marketing. But it is what separates a business that can grow from one that collapses under its own volume.
Vikram Parikh is a Fractional CPO at Parikh Advisory. He has designed order management, fulfilment, and eCommerce product architecture for 40+ retail and eCommerce brands including global QSR, luxury retail, and marketplace clients.
