A US$2B retailer that could not get a straight answer in under two days.
How we framed the real problem behind an executive’s frustration, designed an AI control tower that answers in seconds, and planned a working prototype in fourteen days without touching a single live system.
This is a real piece of our strategy and product work, with the client and every name removed. It is not a paid delivery we are claiming credit for. It is the depth of thinking you get when we scope an AI engagement: the framing, the architecture, the prototype plan, and the way we take the risk out of the build.
- Role
- AI product lead, problem framing to prototype
- Sector
- Multi-format grocery retail
- Scale
- About US$2B revenue, 280+ stores, three markets
- Window
- A working prototype in 14 days
The problem
It was never a data problem. It was an insight latency problem.
The chief executive of a roughly US$2B grocery group put it plainly: he could not get a straight answer to a simple question without waiting days. The data existed. It was just scattered across half a dozen systems, and the moment that mattered had usually passed by the time anyone pulled it together.
“I want to sit at my desk and ask what is happening in my business right now. Not yesterday’s dashboard. An answer, like I am talking to my smartest analyst who has access to everything.”
Data fragmentation
Finance in one ERP, supplier relationships in a CRM, store sales in point of sale, supply chain in a legacy warehouse system, and the real ground truth buried in email, Teams, and WhatsApp. No single person held a unified view.
Insight latency
A simple cross-market margin question took one to two business days. By the time the answer arrived, the perishable inventory it described had already lost its margin.
Qualitative blindness
Dashboards showed what happened, never why. Nobody could connect a margin drop to the broken refrigerated truck that caused it without manually chasing regional managers.
A failed track record
An earlier reporting modernization had stalled and was seen internally as a failure. The bar for credibility was high, and slideware would not clear it.
Who we were solving for
Two people in the room, two very different fears.
The chief executive
Came up through finance and operations. Commercial, metrics-driven, impatient with anything conceptual.
A zero-friction way to ask a question and get a real answer with context. Not another dashboard. Not a 40-slide deck. Something that behaves like the smartest analyst in the building.
Low trust in technology after the earlier failure. The only thing that would move him was seeing it work live.
The chief strategy officer
Had championed an internal AI initiative for a year but could not get budget approved.
A tangible, working prototype she could use as internal ammunition to unlock the executive budget.
If the prototype looked like just another vendor demo, her credibility went down with ours.
Why nothing on the market fit
Every obvious option solved a different problem.
Before recommending anything, we ruled out the categories a buyer would reach for first, and named exactly why each one would fail here.
Traditional BI and dashboards
Needs the data centralized first, which is exactly the project that already failed. Shows what, never why, and executives do not adopt it.
Single-ecosystem copilots
Locked to one vendor's data. Cannot reason across finance, store ops, and messaging at the same time.
Vertical retail AI suites
Built for one function like demand forecasting. Not a conversational executive view, and they need long, deep integrations first.
Basic chatbots and RAG wrappers
Text in, text out. No charts or maps, no routing logic, no ability to bridge a number with the reason behind it.
What it looks like
You ask in plain language. It answers with the chart and the reason.
A preview of the interface we designed. The point is not the styling. It is that one question returns a number, a picture, and the why, with a source you can check.
How did fresh produce margins perform in New Zealand last month versus Australia?
New Zealand came in at 12.9%, short of the 15% target by 2.1 points. Australia held target at 15.0%.
15% target
Why did they drop in New Zealand?
A refrigerated truck failed at a regional distribution centre, forcing emergency discounts on spoiling stock. Pulled from this escalation:
“Auckland DC truck refrigeration failed overnight. Two pallets of berries are spoiling. Discounting to clear.”
The name and timestamp are read from the record, never generated.
Illustrative interface. Figures are synthetic, built to mirror a real retailer at this scale.
The approach
Bring the intelligence to the data, not the data to a new warehouse.
The usual pitch is a two-year project to migrate everything into one data lake, then add AI on top. That is the exact shape of the project that had already failed here. We recommended the opposite: leave the data where it lives, and put a thin, intelligent layer on top of it.
Plain-language question
"Why did our fresh produce margins drop in New Zealand last month?"
Semantic router
Classifies the question: is this a number, a reason, or a forecast? Routes it to the right tool.
Structured engine
Turns the question into a precise query against the finance and sales systems where the data already lives, then renders the result as a chart.
Context engine
Searches the unstructured reality, messages, email, and chat, and returns the answer with a verifiable citation: who said it and when, parsed from metadata, never invented.
One composite answer
The number, a chart or a map, and the reason behind it, with sources you can verify, returned in a single reply.
The difference that wins the room is the third move. The system does not just report that a margin fell. It decides, on its own, to go and find why, and brings the human explanation back with the number.
The demonstration
Four moments, designed to turn a sceptic into a buyer.
It speaks before it is spoken to
The interface opens on a short list of what needs attention today. One alert flags that a digital-channel slowdown is putting a measurable share of online revenue at risk. The system is watching the business, not waiting for a question.
A two-day question, answered in seconds
Asked how fresh produce margins compared across two markets last month, it renders a clean comparison chart: one market on target, the other short by 2.1 points. No report request. No waiting.
It tells you why, with the receipt
Asked why the margin fell, it bridges the number to the cause: a refrigerated truck failure at a regional distribution centre, quoted from a regional manager's own escalation message, with the timestamp attached. The analyst took three days to assemble that story last month. This took three seconds.
It looks forward, not just back
Asked how a 5% supplier price increase would ripple through profitability, it simulates the hit, then cross-references historical pass-through to show the realistic net impact is far smaller. It models the future, not only the past.
How we take the risk out
The hard part is not the demo. It is being trusted with the real systems.
A polished demo is easy to fake. Earning the right to plug into a company’s finance and messaging systems is not. These are the commitments that make the build safe, and they are the same principles we hold to on every engagement.
Sandbox first, never the live systems
The prototype runs entirely on a realistic synthetic copy of the data. Nothing touches production finance or messaging systems until the approach is proven and the client says go.
The data stays inside their walls
The design keeps company data where it already lives instead of copying it into a new warehouse. Lightweight agents query the existing systems in place. No migration, no second copy to secure.
Citations come from metadata, not the model
Every quoted source, the author and the timestamp, is read straight from the record. The language model is never allowed to generate a name or a date. That is the primary guard against a confident wrong answer.
A one-line fallback for the live demo
Every AI step has a deterministic backup that can be switched on instantly. If anything misbehaves during a high-stakes meeting, the experience stays flawless. No improvisation in front of the client.
The plan
Fourteen days, three people, one working prototype.
Days 1 to 4
Foundation
Write the realistic synthetic data and the exact demo sequence. Stand up the mock data services and the interface skeleton so the front end and the logic can be built in parallel.
Days 5 to 9
The reasoning layer
Build the router that decides where each question goes, wire it to the structured and context engines, and connect the interface so answers render as charts, maps, and citations. A full end-to-end run at the midpoint, logging every flaw.
Days 10 to 12
Hardening
Fix what the midpoint review surfaced, tune for consistent, zero-fabrication answers, and finalize the deterministic fallbacks. Then try hard to break it with odd phrasing and edge cases.
Days 13 to 14
Code freeze and rehearsal
No new features, only critical fixes. Script the walkthrough and rehearse it until the flow is seamless and lands in under fifteen minutes.
What this means for you
This is the thinking that comes before a line of code: the real problem named, the wrong solutions ruled out, the build de-risked before you commit. It is exactly what an AI Operational Audit delivers for your business, on your data, for a fixed fee.