AI ON BUSINESS DATA
What is conversational BI?
Business intelligence you talk to. Ask in plain language, get a KPI, a chart or a table back, and ask the next question without building anything.
- The questions someone designed in
- The question you have right now
The region pivot shows North far ahead with 395 orders, followed by West with 247, East with 168 and South with 142.
- Any question, in a sentence
- The next question, one click away
BI you talk to
Business intelligence has always meant turning records into answers: how many, how much, compared with what, broken down by what. For thirty years the interface was a report, then a dashboard: somebody designed the questions in advance and built the screens that answered them. Conversational BI changes the interface, not the job. You type the question - orders by region this month, and which one grew most? - and get back the same kinds of answer a dashboard would show, a leaderboard with North at 395 ahead of West 247, East 168 and South 142, a summary in a sentence, and suggestions for what to ask next. Nothing was built in advance except the data layer.
The lead visual puts the two side by side. On the left, a dashboard built in advance: 952 orders, 14 urgent, 36 rejected, and the regions chart. On the right, a conversation: one typed question, the summary, the leaderboard, and the next questions offered. Same collections underneath; one surface was designed, the other was asked.
What it looks like
A chat window over business data. The answers are not paragraphs; they are the shapes business people already read. One number comes back as a KPI tile with its change. Two dimensions come back as a pivot. A ranking is a leaderboard; a trend is a chart; "show me the orders" is a table. Around the shape, a summary states the finding, a short list suggests what you could do when the findings call for it, and a row of next questions - which stores in North declined most, show the orders behind this - keeps the conversation moving. How an answer gets its shape goes through the formats.
How it works, briefly
Five steps. The model reads the question and works out what is being asked. It maps the question onto a vocabulary it was given - collections, fields, filters, facets - rather than writing a query. The index runs the request and returns exact counts and records. The result picks its shape. The model writes the sentence and proposes the follow-ups. The division of labour is the whole design: the model is good at language and intent, the index is good at numbers, and neither does the other's job. How can AI answer questions about business data? follows one question through all five steps.
Not a replacement for dashboards
The first instinct is to see conversational BI as dashboards' successor. It is their complement. A dashboard answers the questions a business asks every week, with definitions everyone shares, open on a screen, watched. A conversation answers the question you have right now, which nobody built a widget for, and which leads to another. Re-asking "how many urgent orders?" every morning in chat is slower than a saved grid that shows 14; building a widget for every question anyone ever asked is how dashboards sprawl. Each surface has a job, and the handoff between them runs both ways. Dashboards vs chat is about that handoff.
What makes it trustworthy
Three things, and the first is the one to check. Where the numbers come from. In a trustworthy design every figure in an answer was computed by the data layer - the index counted 395 orders for North - and the model only phrased it. A design where the model produces or adjusts numbers is a design that will eventually produce a confident, wrong one. What the model is allowed to do. Choosing from a fixed vocabulary of collections and fields, rather than writing free SQL, means a question either maps to the data or is refused, and nothing a user types can reach past the vocabulary. What leaves your environment. The model runs at a provider; what it is sent should be the information the request needs, under your own account and key, and nothing more. Why grounded answers don't invent numbers covers the first; What the LLM sees covers the third.
| Property | What to look for in an answer |
|---|---|
| Grounded numbers | Every figure computed by the data layer, none produced by the model |
| Visible scope | The collection, filters and period the answer used, stated with it |
| Stated freshness | "As of 09:00", because the index is a scheduled copy |
| Same access as the dashboards | A user is answered from the data they are allowed to see |
| Constrained vocabulary | Collections and fields to choose from, not free SQL to write |
| Known boundary | What is sent to the model provider, under whose key |
Who it is for
People with questions and no SQL. The operations manager who wants to know which region drove the spike; the regional lead who wants last week's rejected orders by store; the executive who wants one number before a call. It is also for the people who do have SQL and would rather not write it at three in the afternoon. What it is not for is monitoring: the question you ask every day belongs on a dashboard, where it is already answered when you arrive.
Where the data comes from
Conversational BI is only as good as the layer underneath it. If the assistant has to query the production database, every question is a load and a risk. If it reads an indexed copy - the same collections a dashboard reads, refreshed on a schedule - the answers are fast, exact, and agree with the dashboard, because they counted the same records. That shared layer is what turns two interfaces into one system rather than two sources of truth. Three ways AI answers from your data compares the indexed approach with the alternatives.