Conversational BI: what it is, how it works, and how to evaluate it

Conversational BI means using natural language to query business data. Instead of opening a prebuilt dashboard, filing a ticket with the data team, or writing a query, you type a question like "What did we sell by region last quarter?" and get the answer right away.

The point is to take analysts out of the loop for simple, repetitive questions. The sales director, the finance lead, and the operations manager can look at the data directly, at the pace of their own questions. Analysts stay essential, but they spend their time on judgment calls: defining metrics, cleaning up the data, and handling what a tool cannot.

You will see other labels for the same idea: generative BI, conversational analytics, "chat with your data," NL2SQL (natural language to SQL). What varies between vendors is how well the question gets translated, how tightly the AI's access is controlled, and how transparent the answer is.

It helps to keep two things apart. The language model understands the question. The data stays where it already lives: your database, your ERP, your warehouse. A good conversational BI product does not move your data around for the sake of the AI. It takes the question to the data.

Vendors differ in the details, but a question usually travels through five steps.

1. Question. The user types it the way they would say it. "Which customers bought less this month than last month?"
2. Understanding, with a semantic layer. The AI has to know what "active customer," "margin," or "delinquency" mean at that specific company. A semantic layer holds those definitions: a glossary of business terms, targets, and KPIs that guides interpretation. Without it, the AI guesses, and guessing is the main source of wrong answers.
3. SQL generation. With the question understood and the database schema in hand, the model writes the query in the right dialect (PostgreSQL, SQL Server, Oracle, and so on).
4. Read-only execution. The query runs with read-only permission. Any statement that would change data (insert, update, delete) should be blocked before it executes. This is a security requirement, not a nicety.
5. Answer with SQL and reasoning. The result comes back as a number, table, or chart. Serious platforms also show the query that ran and the reasoning behind it, so a technical reviewer can check it and a business user can see where the number came from.

Step five separates an auditable tool from a black box. If a platform hands you a number without showing the query, you are taking its word for it. If it shows the query, you can verify it, copy the SQL, and run it yourself.

The semantic layer deserves extra attention. Two departments at the same company often calculate "revenue" differently, one with taxes and one without. Once the glossary records which definition applies, the answer stops depending on who asked. The definition work is done by people, happens once, and pays off on every question afterward.

These three terms get blended together in sales conversations, but they describe different things.

A general-purpose chatbot answers from what it learned in training or from documents it was given. It can write a convincing paragraph about your sales without ever querying your sales data. For business analysis, that is a risk: the answer sounds right and may be made up.

Conversational BI does not answer from memory. The AI translates your question into a query, the database runs it, and the number comes from your actual data. The language model acts as interpreter and query writer, while the database does the math. That is why the result can be checked line by line.

A BI copilot is usually an assistant embedded in an existing BI tool. It helps build visuals, write formulas, or summarize a report inside an environment that already has a data model, dashboards, and licenses. It helps people who already use the tool, but it typically relies on a semantic model that a specialist built beforehand.

A quick test: ask where the number comes from. If the answer is "from your database, by this query," it is conversational BI. If it is "the model estimated it," it is a conversation, not analysis.

Conversational BI works best on questions whose answers already sit in data the company records. Here are examples by team, phrased the way people actually ask:

• Finance: "Which receivables are more than 30 days overdue, by customer?" "How did actual cash flow compare with forecast this month?" "What did we spend per cost center this quarter?"
• Sales: "Which reps hit their March quota?" "What is average order value by region and channel?" "Which customers have stopped buying in the last 90 days?"
• Operations: "Which products are below minimum stock?" "What is the average time from order to delivery by branch?" "Where are returns highest?"
• HR and payroll: "What is payroll cost by department?" "How many overtime hours did each site pay this month?" "What is turnover by area over the past 12 months?"

HR and payroll questions call for care with permissions, since they touch personal and salary data. A suitable platform lets the company decide who sees what, so the same question returns different answers depending on who is asking.

Notice the pattern: objective questions with a time window, a filter, and a grouping. They usually end up in a request queue for the data team. With conversational BI the queue shrinks, and the data team gets time back for higher-value work.

This is the first thing IT and legal ask, and rightly so. The answer depends on the platform's architecture, and you should ask the vendor to spell it out. The most common setups:

• Data in your own cloud. Managed databases and cloud warehouses. The platform connects over a protected network and queries on demand.
• The ERP database. Many mid-sized companies keep everything in the database behind their ERP, on their own servers or in a data center. Conversational BI connects to that database, ideally to a replica or with a read-only credential.
• An on-prem gateway. When the database is not exposed to the internet, an agent (the gateway) is installed inside your network. It opens an encrypted outbound connection to the platform, so you do not have to open inbound ports in your firewall. The database credential stays on your network, and what travels is the query result.
• Spreadsheets and files. If part of the business still lives in Google Sheets, CSV, or Excel, some platforms read those files as a source.

In none of these designs does your data need to be migrated into a new structure before the first question. Still, each query result travels to the user, and you should understand exactly what moves, over which path, with what encryption, and for how long it is stored. Get those answers in writing.

Use this list during a proof of concept. If the vendor hesitates on any item, you know where to dig.

1. Where the data lives and what travels. Does the platform copy your data or query it in place? What leaves your network: raw data or only results? Is there a gateway for databases that cannot be exposed?
2. Auditable SQL and reasoning. Can you see the generated query and the path that led to it? Is every question logged, with who asked and what ran? Without that, a number cannot be verified.
3. Per-user permissions. Does the answer respect what each person is allowed to see? For multi-company platforms, is there isolation between customers? Is single sign-on available for those who need it?
4. Supported databases and sources. Is your database on the list, in the version you run? Test with your real schema, not a demo dataset. Ask how the platform handles legacy databases.
5. How implementation works. Who handles the connection, the glossary, and the first tests? What is a realistic timeline to the first useful answer? Be wary of promises of instant setup on data nobody has organized.
6. Cost per question and per use. Is pricing per user, per question volume, per AI model? Are there query limits? Who pays for AI consumption? Ask for an estimate at your expected volume.

One bonus question: what happens when the AI gets it wrong? Good platforms keep the error visible (the query is right there to be fixed) and let you adjust the glossary so the same mistake does not repeat.

The technology handles a specific band of problems well. Outside it, it gets in the way or creates false confidence. Think twice in these cases:

• The data does not exist, or nobody knows where it is. AI does not create information. If granted discounts are not recorded in any system, no question will surface them.
• The data is messy and has no owner. Duplicate tables, fields filled in several ways, and no single definition of "customer" produce inconsistent answers. Someone has to own the data and fix the basics first.
• The question needs complex statistical modeling. Hypothesis tests, sophisticated forecasting models, and controlled experiments call for a data scientist. Some platforms offer simple time-series forecasting, which is fine for spotting trends and not for in-depth research.
• The process requires strict compliance and a fixed report. Regulatory financial statements, for example, need standardized, reviewed output. A static, tested report remains the better choice.
• Nobody will check the work. Even with visible SQL, someone needs to look now and then. If the culture accepts any number without question, the tool just spreads errors faster.

None of this is a reason to skip the technology. It is a reason to start with a domain where the data is trustworthy, such as sales or receivables, and expand as confidence grows.

Entendo is the conversational BI platform from Sozo Data, a Brazilian company. Users ask in Portuguese or English and get a number, table, or chart, with the generated SQL and the reasoning in plain view. Execution is read-only, and every question is logged for audit.

It connects to the database behind the ERP (PostgreSQL, MySQL, SQL Server, Oracle, Firebird, and ClickHouse), plus Google Sheets, CSV, and Excel. When the database sits on an internal network, an on-prem gateway installed in the customer's network opens an outbound connection, with no inbound port required. Implementation is assisted by our team.

Technical details, plans, and the partner model are on the Entendo page.