Why your ‘overnight’ order showed up three days late 

Same dishwasher saga, second insult. The part being wrong is a data story I’ve already told. The part being three days late—after I paid for it to arrive overnight—is a different problem, and it lives in the pipes between systems. 

Consider what the website knew versus what the warehouse knew. The site told me the pump was in stock and would land on my porch tomorrow. Deep in the distributor’s back office, a truer version existed: in stock, yes, but sitting in a distribution center on the other side of the country, nowhere near an overnight promise. 

That location detail never made the trip to the front end, so the site fell back on the only rule it had. In stock means overnight. It wasn’t lying to me. It just didn’t know what it didn’t know. 

This is an integration problem at its core. You don’t become a national distributor without piling up complexity. Maybe you grew by acquisition, thirty companies in three years, each arriving with its own ERP, its own inventory system, its own private dialect for describing the same bolt. Matt worked with an electrical distributor doing exactly this, swallowing regional shops and treating each one as a new distribution center. Great for reach, less great when every acquired system stores its data differently. 

I like to imagine data moving through clean plumbing, the same shape start to finish. It doesn’t. It comes out of one system as steam and the next system needed ice. (My metaphor falls apart right around there, but you feel it, right?) You can’t just yank the old systems out, either. That branch runs on that software, and pulling it makes the whole operation seize. 

The systems are load-bearing, so they stay, and the connections between them harden into what Matt calls a twisted ball of yarn: brittle, hand-coded links, some built by a vendor, some by a contractor, some by your own team five years ago. Each one is patched differently and a few are not patched at all. Change one field type in the ERP and something three systems over collapses. 

The way out is easy to say and brutal to do. Everything has to connect and one person has to own how. That means dragging the whole mess onto a single map, finding the joints that are brittle or missing, and putting someone in charge of the macro view—the architect who can see what connects to what and govern it as it changes. 

Strip away the tech and it’s just old-fashioned discipline. People get frustrated in IT for the same reason they get frustrated anywhere. Someone never defined how this was supposed to work. 

Now here comes the plot twist everyone’s excited about, which is AI. Wiring systems together used to eat up months. Matt’s team once spent a year building two ERP integrations for a single launch, and that was normal. AI reads those APIs and maps those connections faster than a human developer can type. It can also keep watch afterward, catching a change in a core system before it takes the order flow down with it. 

Point that same AI at a swamp, though, and it’ll automate the swamp. These tools are only as good as the context you feed them and they hallucinate with total confidence. Matt watched an order management system look at a customer’s uploaded photo, misidentify the part, and cheerfully drop the wrong thing into the cart, ready for checkout, because the data underneath it was wrong. 

So the order of operations matters. Map the architecture, build the layer, clean the data, then let AI do the fast connecting and the tireless watching. In that sequence, the overnight promise becomes one you can keep. 

Listen to Episode 2 of Data vs. Commerce wherever you get your podcasts.