A one-line email and a lost afternoon
The managing director sends a message on Tuesday morning: how many customers bought from us last year but not this year? Or: which product lines have the lowest margin in the north? It sounds like a quick answer.
It is not. The person asked has to export orders from one system, customer regions from another, costs from a third, then join them in Excel with lookups that break on inconsistent names. By Thursday there is an answer, with caveats. The director has already made the decision on instinct.
Why simple questions are slow
The questions are simple. The data is not arranged to answer them. Each system is built to run its own process, such as taking orders or sending invoices, and nothing joins them together in a form you can query.
- Data needed for one answer sits in three or four systems
- Customer and product names differ between those systems
- Only one or two people know which export has the right fields
- Every question starts again from scratch, so nothing gets faster
That last point is the telling one. If the tenth question takes as long as the first, the work is not accumulating anywhere.
The cost of slow answers
Decisions get made without the evidence, or they wait for it. Managers stop asking questions because they know the answer will take days, so problems surface late. The people who can pull the data spend their time as a human query service rather than on their actual job.
It also creates a bottleneck around those one or two people. If they leave, the knowledge of how to answer anything leaves too.
And answers built by hand are hard to repeat. When the director asks the same question next quarter, the spreadsheet from last time uses different exports and a slightly different method, so the two answers cannot be compared with confidence.
How we make answers quick
- We collect the questions management has asked over recent months. They tell us which data matters.
- We pull the relevant data from each system through APIs into one database, often Postgres, BigQuery or Azure SQL depending on what you use already.
- We clean and link it: one customer ID, one product ID, one set of regions, with the matching rules written down.
- We model it into a small number of well-named tables, such as orders, customers, products and costs, with definitions for every field.
- We connect it to a tool your team can use: Power BI, Looker Studio, Excel pivot tables or a simple internal web page with filters.
- Where it suits, we add a natural-language layer using OpenAI or Anthropic Claude that turns a question into a query against these tables and shows the query and the result, so the answer can be checked.
| Question type | Where the answer comes from |
|---|---|
| Routine, asked every month | A saved report or dashboard page |
| Variation on a routine one | A filter or pivot on the modelled tables |
| Genuinely new question | A short query, or the AI assistant with its query shown |
We are careful with the AI layer. It is only as good as the tables underneath, and it must show its working. On messy data it gives confident wrong answers, so the modelling comes first.
Tuesday's question, answered on Tuesday
Most routine questions are answered from a filter by the person who asked. New questions still need thought, but the analyst starts from joined, cleaned tables rather than four raw exports. Answers stop coming with a paragraph of caveats about which data was used.
Over time the set of saved reports grows to cover what management actually asks, and the analyst has room to look for problems before anyone asks.
Is this your situation?
- Simple questions from directors take days to answer
- Answers need data from several systems joined in Excel
- Only one or two people know how to pull the numbers
- Managers have stopped asking because the answers are slow