We were asked to build a dashboard. We almost did. The decision not to — made in a warehouse, in a conversation with no agenda — turned a reporting exercise into $51M of combined operational savings.
The ask from the executive team at Dunelm was straightforward: build a returns dashboard. Real-time visibility into return volumes, cost trends, category breakdowns. The kind of thing a data team can scope, estimate, and deliver in a few sprints. We had the brief, we had the access, and we had a team ready to move.
Most organisations would have started building immediately. We didn't — not because we doubted the brief, but because I've learned to be deeply suspicious of briefs that arrive already shaped into a solution.
I sat down with the people actually processing the returns — the warehouse operatives whose hands were on the problem every day. Not to validate the brief. To understand what the brief might be missing.
Within minutes, one of them said something that reframed everything:
"We don't know what's coming in, from whom, or which order it belongs to."
Returns were arriving physically detached from the original transaction. No link to the customer. No link to the order. No link to the product journey. At the moment a return entered the building — the moment that mattered most for understanding it — the system was completely blind.
This wasn't a data visibility problem. The data didn't exist yet in any usable form. Building a dashboard on top of that would have been like building a speedometer for a car with no engine.
The executive brief assumed the data existed and needed surfacing. The warehouse told us the data needed to be created first — and that it needed to be created at the point of return, not retrospectively.
That's a fundamentally different problem. A dashboard answers: what is happening? What we actually needed to build answered: why is it happening, and what can we do before it happens again?
The reframe cost us a few days of discovery. It saved months of building the wrong thing.
The core technical challenge was transaction linkage. Every return needed to be automatically tied to its originating order in SAP — our ERP — at the point of receipt. This required an integration layer between the warehouse management system and SAP that didn't exist, triggering a reconciliation process that matched inbound returns to order history using a combination of product identifiers, customer records, and despatch data.
Once that linkage existed, two things became possible that weren't before. First, pattern recognition: you could see which products, which routes, which suppliers, which customer segments were generating returns — and why, at a granular level. Second, intervention: because you now had the full order context, you could act on the patterns rather than just observe them.
The dashboard came second. It was straightforward to build once the underlying data had integrity. Reporting is easy when the data model is correct. The hard work is always in the model.
The figure represents combined operational savings across reduced return processing costs and — more significantly — returns prevented through targeted intervention once patterns became visible and actionable. It accumulated over time, not overnight, and it required the commercial and operations teams to act on what the system surfaced. The technology created the conditions; the business decisions created the value.
A dashboard showing the same return volumes, built on disconnected data, would have shown the scale of the problem clearly. It would not have enabled a single fix.
Expensive data mistakes are rarely made by building the wrong thing.
They're made by building the right thing for the wrong problem —
because the problem definition came from people with authority over it,
not people with knowledge of it.
Your data team can tell you what's happening.
The people doing the work can tell you why.
Your executives can tell you what matters.
You need all three. Most projects only get one.