When Chat Becomes the Interface to Business Data

Most business software screens exist for one of two reasons. Either the user genuinely needs to see that information laid out visually, or the software had no better way to answer the question the user was asking.

That second category is larger than most teams admit. Filters, date pickers, drill-downs, and export buttons are often not interfaces at all. They are compensations for the fact that you could not simply ask the system something.

When Kingsley and I built Workforce, and specifically its embeddable conversational layer, we spent a lot of time on this question: when should someone inspect a dashboard, and when should they be able to ask the system directly? The answer turned out to be less about technology and more about the shape of the question being asked.

Dashboards are good at what they were built for

Let me be clear about what I am not arguing. Dashboards are not dead, and they are not going away.

A dashboard earns its place when someone needs to scan, explore, compare, or monitor a stable set of metrics visually. If you check the same five numbers every morning, a well-designed screen beats a chat box every time. You do not want to type a question to see a number you already know you need. You want it in front of you, with trend lines, comparisons, and the ability to spot an anomaly at a glance.

Recurring visual monitoring is a solved problem. The mistake would be tearing that down.

The problem is everything around it. The irregular questions. The ones that do not fit the filters someone designed two years ago.

Where conversational access actually wins

Think about the questions that land in an analyst's inbox or a Slack channel. Why did churn spike in that segment last month? Which accounts expanded after the pricing change? What did we decide about that supplier, and who signed it off?

These questions share a shape. They are irregular. They cross boundaries between systems. Answering them means navigating filters that were not designed for this exact question, reconstructing context from memory, or asking someone who knows where the bodies are buried.

This is where conversational access earns its keep. Not as a replacement for the morning metrics check, but as the interface for the long tail of operational questions that never justified their own screen.

The value is not the novelty of typing instead of clicking. It is that the question can be answered with context: the data itself, plus what the organisation already knows, plus what happened last time someone asked something similar.

A useful answer is more than generated SQL

The naive version of this product is a text box that writes a query and returns a table. That version fails fast, and it fails in ways that erode trust.

A real answer needs several things working together. The system needs metric definitions, so that "revenue" means the same thing to the software as it does to the finance team. It needs user permissions, so the answer respects what this person is allowed to see. It needs historical context, so a follow-up question builds on the last one rather than starting cold. And it needs access to organisational knowledge, not just rows in a database.

This is the architecture we built into the Workforce layer: memory, a knowledge graph, and integrations into existing workflows, so that retrieval comes with context from prior work rather than a naked query result. The technical companion to this piece explains how that agentic interface is structured.

There is a second requirement that gets less attention. The output has to be structured and inspectable, not only prose. A confident paragraph that cannot be checked is worse than no answer. Users need to see the numbers, the sources, and the logic well enough to trust or challenge the result. Conversational input does not excuse sloppy output. If anything, it raises the bar, because the user gave you a vague instruction and expects a precise response.

The hard part is none of the visible parts. The chat box is easy. Connecting that interface to governed data, actions, memory, and permissions is the actual product. That is where the engineering effort goes, and it is where most attempts at this pattern quietly fall apart.

A design question worth asking of every screen

Once you accept that conversation can handle irregular questions, an uncomfortable audit follows. Look at each screen in your product and ask: does this exist because users need to see it, or because we previously had no better interaction model?

Many settings pages, report builders, and search interfaces fail this test. They exist because, at the time, a form was the only way to collect intent. If a user can state what they want in a sentence, and the system can deliver a structured, permission-aware, inspectable answer, the form is overhead.

Other screens pass easily. Monitoring views, visual comparisons, exploratory analysis: these serve a need that conversation does not.

The practical rule

Here is the rule I use when deciding what stays as UI and what becomes conversational.

If the question is recurring, stable, and visual, build or keep the screen. If the question is irregular, crosses systems, or would otherwise require reconstructing context or interrupting a colleague, make it answerable by conversation. And for anything conversational, hold the output to the same standard as any other interface: structured, grounded in governed data, and inspectable.

The interface was never the point. The point is how quickly someone can get from a question to an answer they can trust. Chat is simply the first interaction model that matches how those questions actually arrive.