Conversational analytics is the promise of asking your data a question in plain language and getting the answer without opening a dashboard, without asking an analyst for a report, without waiting in the BI team's queue. Tableau, Looker, Power BI, Snowflake and Databricks have all shipped some version of it, and the question decision-makers now ask — including to an LLM — is direct: can I just ask my data and skip the dashboard?
The honest answer depends on the kind of question. Chat wins in one category and loses badly in another, and most projects we've seen fail treated the two as the same thing. This piece separates the categories and offers a decision criterion that fits in a thirty-minute meeting.
What chat delivers that the dashboard never did
A dashboard is a prefabricated answer: someone anticipated the question, built the chart and published it. It works as long as the question is the expected one. The moment the sales director wants to know "how much of October's pipeline has been stalled for more than 30 days in accounts that also opened a support ticket?", nobody built that chart — and the traditional path is a request to the data team and a few days of waiting.
That is the gap chat fills. The marginal cost of a new question drops from hours of analyst time to seconds of model time. Three uses stand out:
- Ad hoc questions from decision-makers. A one-time question whose result guides a conversation and then disappears. It isn't worth building a dashboard for.
- Exploration before modeling. The analyst uses chat to understand a new dataset, test a hypothesis, and only then decide what deserves to become a permanent visualization.
- Access for people who never opened the BI tool. Sales reps, account managers and operations ask the question in Slack or in the CRM, where they already are, instead of learning one more interface.
The third point weighs most for companies running Salesforce: Tableau Next, built on the Agentforce platform, brings the question into the CRM workflow instead of requiring a switch of application. When customer data already lives in Data Cloud, the gain is real.
Chat removes the queue for the question nobody anticipated. It doesn't remove the need for a number everyone sees the same way.
Where the dashboard still wins
A dashboard isn't just a way to show data: it's a contract. The quarter's revenue on the board panel is the same number that appears on finance's panel, because the metric was fixed once, reviewed and published. Chat generates the answer anew for every question, and every generation is another chance to diverge.
Four situations where swapping the dashboard for chat is a mistake:
- Recurring tracking metrics. Revenue, churn, SLA, pipeline: the value lies in comparing the same yardstick week after week. A yardstick that changes shape with every query destroys the comparison.
- Numbers going to the board or the auditor. A wrong answer is expensive, and you need to know exactly how the number was calculated and by whom.
- Decisions many people make looking at the same data. The dashboard acts as a shared reference. Five people asking chat the same thing and getting five slightly different answers is the scenario self-service BI already produced with each department's "final draft", only now faster.
- Executive glance-reading. A well-designed panel communicates in seconds what otherwise takes careful reading; a chat answer has to be read, questioned and redone.
Vendors often advertise text-to-SQL accuracy between 85% and 95%, but that figure rarely says which query types were tested. A 90% accuracy sounds high until you do the math: out of every ten board questions, one comes back wrong and doesn't warn you. That's the underlying argument, and it's our own estimate based on what vendors publish, not an independent measurement.
What decides whether chat is reliable: the semantic layer
The difference between a chat that answers well and one that answers with wrong conviction is almost never the model. It's what sits between the model and the database. Without a central metric definition, the model infers what "revenue" means by looking at a column name — and infers it again, possibly differently, on the next query.
The semantic layer is what fixes each metric's definition for the agent and the dashboard at once. A 2026 benchmark over 522 queries showed that combining a semantic layer with explicit context tripled accuracy, reaching more than 95% reliability; and Gartner projects that 60% of agentic analytics projects relying only on MCP, without a consistent semantic layer, will fail by 2028. Those are the two numbers we use most to explain why a chat pilot impresses in the demo and disappoints in week three.
The practical conclusion is that chat and dashboard don't compete: both are interfaces over the same definition layer. Whoever invests in the layer first gets both. Whoever starts with chat discovers the missing layer when two executives compare answers.
How to decide per question, not per tool
Instead of asking "chat or dashboard?", ask per type of query. Five criteria settle most cases:
- How often does this question repeat? Weekly or more: dashboard. One-off or rare: chat.
- What does a wrong answer cost? If it goes to the board, a contract or an audit, the number must come from a governed metric with an owner and a calculation trail. If it guides an internal conversation, chat is enough.
- Is there a central definition for the metric in question? If not, chat will invent one. Define the metric before opening the question.
- Can the person asking evaluate the answer? An analyst notices the odd number. Someone who has never seen the dataset doesn't. For that audience, restrict chat to metrics that are already governed.
- Can someone else reproduce the answer? If two identical questions return different numbers, the interface isn't ready for that use.
The prompt, validation and logging discipline that separates AI-augmented analytics from productivity theater still applies here, now to the chat interface: schema context, business definitions in the prompt, a read-only connection and a record of every question and answer.
Chat as the front door, dashboard as institutional memory
The arrangement that works in the companies we follow uses chat for the new question and the dashboard as institutional memory. A question asked five times in chat is a natural candidate to become a panel: the interaction log shows what the business actually asks, which is a better input for the BI backlog than any survey of departments.
The cycle is simple. The question is born in chat, answered in seconds, and repeats until it becomes a governed metric in the semantic layer and a fixed visualization on the panel. Chat shortens the path to discovery; the dashboard preserves the result. The mistake is using one to do the other's job.
Questions that keep coming back
To close, the most common questions about conversational analytics and the future of the dashboard.
What is conversational analytics?
Conversational analytics is querying data in natural language: the user writes a question, a language model translates it into SQL or a call to a defined metric, and the system returns the answer as text, a table or a chart. It differs from the dashboard because the answer is generated on demand, rather than prebuilt by someone who anticipated the question.
Will chat replace dashboards?
Not entirely. Chat replaces the dashboard for ad hoc, one-off or exploratory questions, where building a panel isn't worth it. It still loses on recurring metrics, numbers going to the board, and any situation where several people need to see the same number. The two coexist as interfaces over the same semantic layer.
Is conversational analytics reliable for business decisions?
Only when a semantic layer defines what each metric means. Without one, the model infers the definition on every query and two identical questions can return different numbers. Accuracy of 85% to 95% advertised by vendors means one in every ten to twenty answers comes back wrong, which is unacceptable for a board number without validation.