Nobody was missing information. They were missing it in one place.

Abstract

A customer rings up and asks where their order is.

If the thing is sitting in a warehouse, that's one lookup and a straight answer. If it was bought in specially for them, it isn't, and most of what this company sells is bought in specially.

They wanted the question answered faster. What we found was that it wasn't slow. It was scattered.

Problem

There are two orders behind every one of these calls.

The first is the customer's, and it's the one everybody thinks about. The second is the order the company placed with its own supplier to get the goods in, and that's where the real answers live. Have the goods actually been bought yet. When is the supplier promising them. Have they shipped. Where does the money stand.

So somebody on the phone is being asked a simple question whose answer sits one step removed from anything in front of them.

And not in one step, in several. Part of it was with the customer's order, part with the supplier's, and the rest spread across records for the items, the suppliers, and the parts that things are made from. Some of it was in a spreadsheet somebody kept by hand, which is where operational truth ends up once the systems stop covering it.

Answering one customer meant opening all of that at once and reconciling it. Then doing it again for the next call.

Here's the part that took us a while to say properly. Nobody was missing information. Every fact needed was somewhere, and the people doing this knew where. What they were missing was all of it in one place, which is a different problem and a much quieter one. It doesn't show up as a gap. It shows up as everything taking longer than it should for no reason anyone can point at.

Two other things mattered more than they look.

A nearly-right answer here is worse than no answer. Whatever comes back gets repeated to the customer while they're still on the line, so a stale date doesn't stay internal. It becomes a promise, and somebody has to break it later.

And a stock total can include things that can't actually be sold to the person asking. Knowing which of it counted and which of it didn't was knowledge somebody carried in their head. It appeared in no system, which meant the answer was only as good as who you asked.

Solution

One row per order line, carrying the whole story instead of half of it.

Each row joins what the customer ordered to what was actually bought to fulfil it, and puts both states side by side: bought or not, expected when, shipped or not, and where the money sits. The person on the phone reads a line instead of assembling one.

It's a sheet rather than a screen, which was deliberate. The people who need this already live in spreadsheets all day. An answer that arrives somewhere nobody works isn't an answer, it's a second thing to remember to check.

The join is heavy, so it's put together on request and handed over when it's ready rather than making anyone wait on it. And it won't hand back an earlier result to somebody who asked for something different, because of what a nearly-right answer turns into once it's been read out to a customer.

Then something happened that nobody planned.

Three more reports got built on top of it. Not one of them was asked for at the start. They only became possible once the joined answer existed, and once it did they were obvious: the same data regrouped for the people chasing shipments, and again for the people chasing money.

That's the part worth noticing. This was commissioned to answer one question at one desk. What it actually did was make something exist that hadn't before, and most of the value of that turned up somewhere nobody was looking when they asked for it.

The question gets answered from one place now, by whoever picks up the phone.