How natural language analytics works, and where it fails
Asking your data a question in plain English works well for some questions and badly for others. Here is what happens between the question and the chart, the failure modes to watch for, and how to phrase questions that get reliable answers.
Natural language analytics means typing a question such as "What was revenue by region last quarter?" and getting a number and a chart back, without writing SQL or building a pivot table. In 2026 this works well for a large share of everyday business questions. It also fails in predictable ways. Knowing how the systems work makes it much easier to tell a good answer from a plausible-looking wrong one.
What happens between the question and the chart
Every system has to do four things:
- Understand the question: which metric, which grouping, which filters, which period.
- Map it to the data: which table and columns hold "revenue", "region" and the order date.
- Compute the result: filter, group, aggregate, compare.
- Present it: pick a chart and write a short explanation.
A large language model is very good at step 1. It understands "how much did we sell", "total sales" and "revenue" as the same request. The differences between products lie mainly in steps 2 and 3.
Two common designs
Text-to-SQL. The language model writes a SQL query from the question and the database schema, the database runs it, and the result is shown. This is flexible: anything SQL can express, the model can in principle write. The risk is that the query runs without error but is logically wrong: a join on the wrong key, a filter applied after an aggregate instead of before, a double-counted row. The output looks equally confident either way.
Planned tools. The language model does not write the calculation. It picks from a fixed set of analysis operations (sum by group, trend over time, period comparison, top N, correlation, join two sources by date) and fills in their parameters. Regular code runs those operations. This is less open-ended, but each operation is tested code, so the arithmetic is right whenever the plan is right.
clariBI uses the second design. The model plans which operations answer the question, pandas code computes them on your data, and the model then writes the answer around the computed results. Before the answer is shown, every sentence that contains a number is checked against those results and removed if the figure cannot be derived from them. The conversational analytics page shows the flow.
Neither design removes every error. They move where errors happen, which is why the rest of this article applies to both.
Where it works well
Clear, single-metric questions. "Total revenue last quarter." "Monthly active users in 2026 by country." "Which product category sold most in March?" One metric, one grouping, one period.
Comparisons and rankings. "Compare Q1 and Q2 revenue by sales rep." "Top 10 customers by revenue this year." These map directly onto standard operations.
Follow-up questions. "Break that down by product." "Just the top three." "Same quarter last year?" A conversational session keeps the context, which is often faster than rebuilding a report in a traditional BI tool.
Questions across two tools. "Weekly ad spend next to new customers for the last 12 weeks" combines two sources by date. Doing this by hand means exporting both and lining them up in a spreadsheet.
Getting more people to ask. The biggest gain is who can ask. A sales manager who would never open a SQL editor can ask for win rate by rep and get a chart.
Where it fails
1. Ambiguous questions. "How are we doing?" and "Show our best customers" leave the metric, the period and the definition of "best" to the system. It will pick something, and it may not be what you meant.
2. Words with several meanings. "Active user", "conversion" and "customer" can each map to different columns or events. If your data has more than one candidate, the system has to guess.
3. Multi-step logic. "Net revenue retention excluding customers who came from the trial tier" or "customers whose usage fell three months in a row but who did not churn" need several dependent steps. Systems handle these inconsistently. Break them into a sequence of simpler questions.
4. Data quality. If "US", "USA" and "United States" appear as three countries, or refunds are stored as positive amounts, the answer will be computed correctly on wrong data. The interface does not show you the raw rows unless you look.
5. Rates and averages. Summing a column of conversion rates or closing prices gives nonsense. Good systems know which columns must not be added up; clariBI knows this for its Google, Meta and API connectors, and for your own files it relies on the column names.
6. Calendars and time zones. "Last quarter" in a company with an April fiscal year, or "yesterday" when timestamps are stored in UTC, can silently shift the window.
7. Why questions. "Why did churn go up?" asks for a cause. Data can show that support response times rose at the same time; it cannot show that one caused the other. Treat any "because" in an answer as a hypothesis.
8. Anything outside your data. Industry benchmarks, a competitor's revenue, the weather last Tuesday: unless you connected that data, the system cannot answer it from your sources.
The help center's article on when AI analysis falls short covers each of these with a workaround.
How to get reliable answers
Name the metric, the period and the grouping. "Total revenue from completed orders in Q2 2026, by product category" beats "How were sales?"
Use your own column names when terms are ambiguous: "count of distinct customer_id", "orders where status is paid".
Start broad, then narrow with follow-ups. Several simple steps are more reliable than one long question.
Check the numbers you will repeat. In clariBI, clicking a chart point opens a drill-down with the dataset, date range, number of rows aggregated and the items behind the value. For a number going into a board deck, also ask the question a second way and compare.
Pick only the sources the question needs. Fewer candidate tables means fewer wrong guesses in step 2.
Writing better questions for AI analytics has 40 before-and-after examples.
Where the technology stands
Compared with a few years ago, language models are much better at understanding intent, and designs that keep the arithmetic in ordinary code have removed the worst failure, invented numbers. What remains is mostly the old problem of analytics: clear definitions and clean data. Natural language analytics is best seen as a fast way for people who understand their business to query their data, not as a replacement for knowing what the numbers mean. AI in BI today looks at the wider picture.
To see where the edges are on your own data, connect one source, ask three simple questions and one multi-step question, and open the drill-down on each answer. You will learn more about the tool in ten questions than from any comparison chart.