What is conversational analytics, and when is it worth it?

Conversational analytics means asking your business data a question in plain language, for example which customers ordered less this quarter than last, and getting back the number, a short explanation and usually a chart. It is worth it when people ask the same kinds of questions every week, each metric has one agreed definition, and every answer can be checked against a report. When those conditions are missing, the assistant still answers, just not reliably.

What is conversational analytics?

The term covers two different things, and search results mix them up. In contact centers, conversational analytics means analyzing recorded customer calls and chats for sentiment, topics and complaints. In business intelligence, which is what this guide is about, it means a chat interface on top of your own data: sales, receivables, margin, pipeline. You ask, it queries, it answers.

A typical exchange looks like this. A sales director types "how did gross margin in Germany compare with last quarter?" The assistant finds the margin measure, filters on Germany and the two quarters, runs the query and replies with both figures, the change and a small bar chart. A good setup also shows which measure, filters and period it used, so the director can check the answer against the monthly report in a few seconds.

Older tools did a version of this. Power BI has had a natural language box called Q&A for years, which matched the words in your question to field names. The newer generation runs on large language models, which cope far better with loose phrasing and follow-ups ("and in France?"). They also bring a new problem: they produce a fluent, confident answer even when they picked the wrong field.

How natural language query works: semantic models and text to SQL

Under the chat window there are two common designs, and which one you end up with depends on where your data lives.

The semantic model route. If your reporting runs on Power BI, the assistant reads the semantic model: the tables, relationships and DAX measures your reports already use. Copilot in Power BI and Microsoft Fabric data agents both work this way. The question is translated into a query against measures someone has defined, so revenue means whatever the Revenue measure says it means. Microsoft's documentation also notes that when a question is not about data in the semantic model, Copilot answers from the language model's general knowledge, which is good to know before you put it in front of a leadership team.

The text to SQL route. Outside Power BI, a custom assistant usually turns the question into an SQL query, runs it against the database and describes the result. This is flexible, and it is also where most of the risk sits, because the model writes new query logic every time. When I build one, I restrict it to read-only views of approved tables, apply the user's permissions in the database before any rows reach the AI, and show the query next to every answer.

Either way the language model does two jobs. It works out what the person meant, and it maps that onto your data. Current models are usually good at the first. The second depends almost entirely on how clearly your data describes itself.

Can an AI data analyst replace your analyst?

It can take over part of the job. The routine questions an analyst gets every week (totals, trends, top ten lists, this period against last) suit an assistant well, provided the metrics are defined. That frees the analyst from lookups that keep interrupting deeper work, and it gets managers their answer in seconds instead of a day later.

What it does badly is explain why. If margin fell because a supplier raised prices in March, and the supplier's price list is not in the data, the assistant cannot know that. It may still offer a plausible reason, which is worse than offering none. It also won't tell you that a question is the wrong question, or that the number someone wants doesn't exist because no system records it.

I'd describe a well-built AI data analyst as a fast, literal junior colleague who knows the data model inside out and has no context outside it. Useful, and in need of supervision.

Why conversational analytics gives wrong answers

When a demo goes wrong, the cause is rarely the AI itself. In my experience it is the model underneath. Microsoft says so plainly: without preparation, Copilot can misinterpret the data and return generic or inaccurate results. These are the problems I see most often when I open a model that someone wants to put a chat interface on:

• Measures named Measure 7, Total2 or Rev_new_FINAL, with no description, so the assistant has to guess which one is revenue.
• Two or three date tables, or dates stored as text, so last quarter can be computed in several ways.
• The same KPI defined twice, for example gross margin before and after freight, in different tables.
• Keys and helper columns left visible, which hands the assistant dozens of plausible fields to choose from.
• Numbers that only exist as calculations inside one report visual, so there is no measure for the assistant to find.
• No row-level security, because everyone who used the report was allowed to see everything.

The last one deserves a second look. A dashboard shared with five managers can get away without security rules; a chat box that anyone in the company can type into cannot.

All of this is ordinary modelling work, and fixing it also makes the normal reports easier to use. That is why I treat an AI readiness assessment of the data model as the first step of a conversational analytics project.

When is conversational analytics worth it?

Before spending money on it, I'd look for most of these:

• People ask the same families of questions over and over, and today those questions land on one analyst's desk or in a long email thread.
• The questions are about data you hold in one place: sales, receivables, pipeline, stock, hours.
• Each metric has one written definition, or you are willing to agree on one.
• The people asking are comfortable checking a number before they repeat it in a meeting.
• There is an existing report the answers can be compared with.

And these are signs to wait:

• The main driver is wanting an AI project to show, with no specific questions behind it.
• No one can say which of three revenue figures is correct.
• The data sits in six systems and has never been brought together. Then a business intelligence dashboard on the combined data is the earlier step.
• Most questions are about why, and the reasons live in emails, meetings and people's heads.

There is a middle case too. If your managers have dashboards they don't open because clicking through pages is a chore, a chat on the same model might get them to use the numbers. If they don't open the dashboards because they don't trust them, a chat won't fix that.

Power BI Copilot, a Fabric data agent or a custom chat?

If you run Power BI, Copilot is the natural starting point, and the calendar pushes in that direction: Microsoft is retiring Power BI Q&A in December 2026 and points people to Copilot as the replacement. Check the licensing before you plan anything. According to Microsoft's Copilot requirements, Copilot needs a paid Fabric capacity (F2 or higher) or Power BI Premium (P1 or higher). A Pro or Premium Per User licence alone is not enough, trial capacities are not supported, and your admin has to leave the Copilot tenant setting switched on. For how capacity compares with ordinary licences, see my Power BI pricing guide.

A Fabric data agent goes a step further. It can answer across several sources (semantic models, lakehouses, warehouses), and you can give it your own instructions and example questions. It needs the same kind of paid capacity.

A custom chat makes sense in three situations: the people asking have no Power BI licence, the questions should be answered inside a client portal or your own app, or the data never passes through Power BI. An agency that wants its clients to ask about their own campaign results is a typical case; the concept client portal on sample data shows the kind of place such a chat could sit.

The routes also differ on data handling. Copilot and data agents process requests under your own Microsoft tenant and agreement. A custom chat sends the question and the query results to an AI provider's API, so I use EU regions where the provider offers them and send only the rows needed for the answer. An NDA and DPA are available on request.

How to start a conversational analytics project

The projects that go well tend to start narrow and get wider only once people trust the answers. This is the order I work in:

1. Pick one dataset. Sales, receivables or pipeline, not the whole warehouse. A narrow assistant is far easier to get right than a broad one.
2. Collect 20 to 30 real questions. Ask the future users what they asked an analyst last month, and write down the correct answer to each one from an existing report.
3. Fix the model. Business names, descriptions, one date table, a measure for every number on the question list, and written definitions of terms like active customer.
4. Build and grade. Set up the assistant, run the question list and count how many answers match. Where you can, fix the model instead of the prompt, then run the list again.
5. Roll out to a few users. Their new questions become new test cases. Only after that do you add people or datasets.

What it costs, and a test you can do today

Most of the cost sits in the model work, not in the chat window. If your Power BI model is clean and you run a Fabric capacity, switching Copilot on and preparing the model can be a short job. If the model needs restructuring, that part takes longer, and it pays off in the ordinary reports as well. A custom chat adds development time for the interface, the permissions and the logging of questions and answers.

Here's a test you can do before asking anyone for a quote. Open your model and ask whether a new colleague could find the right revenue measure in under a minute, from the names alone. If they couldn't, an AI won't do better.

If you want help with it, I build conversational analytics on your own data, starting with one dataset and a graded set of your real questions. If your model needs work first, I'll say so in the quote.

Frequently asked questions