The question “where is my order?” is one of the most common in eCommerce, and it exposes a much bigger problem: no single system knows the whole story.
Four systems. Four dashboards. Four pieces of information.
Four systems report four different statuses. All four are correct. And yet the Customer Service agent still cannot answer the customer’s question.
A customer sends a simple email: can you tell me where my order is? That should be an easy question to answer.
The agent opens the webshop first. Order status: Fulfilled. That sounds promising, but it only means the webshop considers its own part of the process complete.
Next, the ERP. Order status: Released. The order has been released, but that doesn’t tell us whether anything has physically left the warehouse.
Then the WMS. Fulfilment status: Packed. That helps. At least the parcel exists.
Finally, the carrier portal. Shipment status: Label created. No collection scan. No depot scan. No movement.
So where is the order?
Is the parcel still on a packing bench? Waiting somewhere in the dispatch area? Did the driver take it without a scan? Or did something go wrong between the warehouse and the carrier?
Four systems. Four dashboards. Four pieces of information. And one very ordinary question that nobody can answer with confidence.
“Where is my order?” is not an exception
“Where is my order?” is consistently one of the most common questions handled by Customer Service in eCommerce. Benchmarks differ on the exact share. Depending on how it is measured, it accounts for roughly one-fifth to two-fifths of all customer enquiries. During peak periods, that share can rise even further.
It is worth considering how remarkable that is. One of the most routine questions in eCommerce, asked thousands of times every week across the sector, often cannot be answered with confidence by any single system within the organisation.
Often, the wrong problem gets solved
At this point, many businesses draw the wrong conclusion. They think they need better visibility: a central dashboard, a reporting environment or a Customer Service console that brings all the statuses together.
That can certainly make the investigation faster. But it does not necessarily solve the underlying problem. Put all four statuses on one screen and you still see:
- Webshop: Fulfilled
- ERP: Released
- WMS: Packed
- Carrier: Label created
The information is now easier to find. The uncertainty is exactly the same.
A dashboard effectively asks each system: what do you think is true right now? It does not ask: what actually happened?
A status is a system’s interpretation based on the events it has received. An event is evidence that something actually happened.
Four interpretations on one screen do not automatically add up to one reliable answer.
Sometimes they simply mean that an employee has to make the same judgement call faster.
You did not buy a distributed system. You assembled one.
No retailer wakes up one morning and decides to build a distributed system. You choose a webshop, then a marketplace connector, an ERP, a WMS, a fulfilment provider, a carrier integration, a returns platform and an accounting package. Every choice makes perfect sense on its own.
But what you have ultimately assembled is a distributed system: independent systems with no shared clock, no shared vocabulary and no single system able to oversee the entire process.
Distributed systems have well-known failure modes:
- Events arrive in the wrong order.
- Messages are delivered twice.
- One component stops without anyone noticing, while the other systems simply carry on as if nothing has happened.
These are not theoretical IT problems. In day-to-day operations, they show up as:
- Products being oversold because an inventory update arrived too late.
- Duplicate parcels because a warehouse received the same order twice.
- Cancellations that reach the webshop but not the fulfilment provider.
- Returns that are physically received but never trigger a refund.
At first glance, these all look like different problems. Structurally, they have the same underlying cause.
Nothing in this example was broken
Look again at the example above. No system needed to crash. Nor was an obvious integration error required. Each application could be reporting correctly based on the event it knows about: the webshop considers the order complete, the ERP has released it, the WMS or fulfilment provider has packed the parcel, and the carrier only knows that a shipping label has been created.
Four systems, each of them correct. And still one question that cannot be answered with confidence.
That is the difference between connecting applications and having a Data Journey under control.
This also connects to a theme we explore in our KoneX Community Talks™: what happens when growth exposes the complexity between systems and processes?
In Episode 3 of ‘When Growth Stalls’, we look at this from another angle: why adding more systems and connections does not automatically mean that your processes are better under control.
The goal is not a single source of truth
Businesses are often told they need a single source of truth. It sounds appealing, but it is not the right goal.
Different systems are rightfully the owners of different facts.
The payment provider owns the payment, the WMS or fulfilment provider knows what was actually picked and packed, and the carrier owns the physical scan. Trying to bring all that information together in a single application is not only impractical, but also undesirable.
The goal is for the systems that need to act on an event to agree on what happened. That requires four things a dashboard cannot provide on its own.
Four conditions for a reliable Data Journey
- Identity: A webshop order number, an ERP order, a warehouse reference and a carrier shipment number must remain connected. Otherwise, you cannot prove that four different records refer to the same customer transaction.
- Ownership: For every status that triggers an action, it must be clear which system is authoritative. Without that agreement, systems can quietly overwrite each other’s information.
- Meaning: Every status needs a clearly defined event behind it, with a clear meaning for what should happen next.
- Recovery: Events sometimes arrive late, twice, or not at all. The chain must be able to handle this without, for example, executing a shipment or refund twice. At the same time, it must be visible which transaction stopped and where
A reliable eCommerce Data Journey does not depend on the webshop, ERP, WMS, fulfilment provider and carrier storing the same data.
They need to recognise the same transaction, know which system owns each event, and respond correctly when that event occurs
Get those four things right and a dashboard becomes genuinely valuable. It is then reporting on a process that is under control, rather than trying to compensate for a lack of control. It can show which orders need attention, which event failed, which system is responsible and whether the customer is affected. What a dashboard should never do is ask an employee to compare four conflicting statuses and then guess which one is probably correct.
AI increases the impact of this problem
For years, the real integration layer within many retailers was simply a person: someone who knew that the figures in the ERP were an hour behind, that the warehouse feed was not entirely reliable after six, and which status could or could not be trusted on a Monday morning.
That knowledge was never written down. And automation does not automatically inherit it. An AI agent has no instinct telling it which information is outdated or which status it should distrust. It sees the data made available to it and acts accordingly. If, for example, the webshop says an order can still be cancelled while the warehouse has already packed the parcel, a refund may be issued while the parcel is still shipped.
Good data integration and reliable data flows are critical to the success of AI agents.
The Salesforce and MuleSoft 2026 Connectivity Benchmark Report found that the organisations surveyed use an average of 957 applications, of which only 27% are integrated. At the same time, 96% of the IT leaders surveyed consider data integration critical to the success of AI agents.
The point is not that AI is unreliable. The point is that automation removes precisely that last informal safety net at the moment when inconsistencies between systems become machine-readable.
Automation is ultimately only as reliable as the Data Journey it runs on.
A test you can run this week
You do not need to start a major project to find out where you stand. Take one recent order where something went wrong and follow it from checkout through payment, inventory, fulfilment, carrier, return and financial processing.
That is a Data Journey.
For each step, write down:
- Which system owned the decision?
- Which event should have occurred?
- Where did the systems stop agreeing?
If the same handoff between systems keeps appearing across multiple problem orders, you have probably found something more valuable than a new dashboard: a specific part of the Data Journey that needs attention.
From connected applications to a Data Journey under control
KoneX is built for precisely that layer. Your webshop, marketplaces, ERP, WMS, fulfilment providers, carriers and returns systems continue doing what they do best.
KoneX orchestrates the events between those systems, so that what happens in one place is understood correctly by every other system that needs to respond: from Pixel to Parcel.
The goal is not to replace your existing applications, but to ensure that when something important happens, every system that needs to know agrees on what happened.
Your business does not need another dashboard.
Your systems need to agree. The Data Journey needs to work.
If the test above exposes unclear ownership, conflicting statuses or handoffs that repeatedly require manual investigation, the problem probably is not in your reporting.
Map your Data Journey
Book a free Data Journey Audit. We map how a transaction moves through your webshop, ERP, WMS and carriers. We identify where information becomes inconsistent, events stop moving or manual intervention enters the journey, and show you where you can bring the Data Journey back under control.
