Nobody Did Anything Wrong
A client gives notice. In the review afterwards, every number is defensible.
Receiving hit dock-to-stock. Picking accuracy was above target. Customer service closed tickets inside SLA. Finance invoiced on schedule. Nobody was slacking, nobody dropped a ball anyone can name, and the reports for the quarter are green.
So the conversation turns to relationship management, or pricing, or a competitor with a better story, because those are the explanations left once the operational ones are eliminated.
The numbers are all accurate. They are also all describing pieces of something the client never experienced in pieces.
What the Client Was Actually Measuring
Your client wasn't watching dock-to-stock. They were watching whether the thing they promised their customer showed up.
Between your receiving metric and that outcome sits a chain: goods arrive, a discrepancy gets flagged, someone has to decide whether to hold or release, the client needs telling, the order waits, the cutoff passes, the shipment goes a day late. Every station in that chain performed correctly. The chain still took four days.
Nobody owns four days. Receiving owns receiving.
An operation full of functions that each perform well produces an outcome nobody is accountable for, and the outcome is the only part the client can see.
Systems Are Configured the Same Way You Are Organized
This is where it stops being an org chart problem.
When a warehouse system gets configured, the conversation follows the same shape as the org chart, because that is who is in the room. Receiving is specified by the receiving lead. Picking by the ops manager. Billing by whoever owns billing. Each area gets defined thoroughly by the person who knows it best.
The seams between them belong to nobody, so nobody specifies them. What happens when a discrepancy at receiving blocks an order that customer service has already promised? That question has no owner in the room, so it does not become a configured behavior. It becomes a phone call, made by whoever notices.
The gaps in the system end up in exactly the same places as the gaps in the org chart, because the same people drew both.
The Reporting Follows the Same Fault Line
Then the system reports on what it was configured to model, which is functions.
You can get dock-to-stock, pick rate, ticket resolution time, days to invoice. What you generally cannot get, without building it yourself, is the elapsed time from a client's order landing to that client's customer receiving it, broken down by where it waited.
So the operation manages what it can see. Each function optimizes its own number, sometimes at the direct expense of the chain, and every one of those trade-offs looks like an improvement in the report where it lands.
A system that measures functions will make an operation better at functions, which is not the same thing as better for the client, and occasionally the opposite.
The Question Nobody Brings to a Demo
Evaluations follow the org chart too. Each department watches its own part of the demo and judges the system on how well it handles their work.
Nobody asks the vendor to trace one order end to end, through an exception, across three functions, and show who is told what at each handoff. That scenario has no natural owner in the evaluation either, so it goes untested in exactly the way it went unconfigured.
It is the same blind spot twice, and the second time it costs more, because now it is built in.
The operation buys a system that mirrors its existing structure, including the parts of that structure where nothing is anybody's job.
Fixing this rarely required a reorganization. It required picking one client outcome that mattered, tracing it across every function it touched, and finding where it sat waiting.
What that exercise produces is a description of the operation organized by flow rather than by department. It is a difficult document to assemble and it is the one thing a system evaluation actually needs.
