Skip to content

Conversational BI & Decision Intelligence

Home/Services/Conversational BI & Decision Intelligence

Conversational BI works when it is built on definitions rather than guesses. We put a natural-language layer over a governed semantic model so business users can ask about pipeline, retention, cohorts, spend and margin and get an answer with the query, the assumptions and the caveats attached — measured for accuracy against a golden test set, not just demoed once.

Challenges we solve

Every organisation has tried self-serve. The usual result is a dashboard estate nobody trusts and an analyst queue that never shortens, because the moment a business user builds their own view they get a number that disagrees with someone else’s, and the whole thing loses credibility. Natural language does not fix that on its own — it makes it faster to get a wrong answer. What fixes it is a semantic layer where every metric has one definition, a set of verified query patterns the assistant is allowed to use, and honest refusal when a question falls outside them. That is the part most conversational BI projects skip, and it is the whole job.

What we deliver

Governed semantic layer

Metrics, dimensions, joins, filters and grain defined once in dbt Semantic Layer, Looker, Cube or a platform-native model — with owners, descriptions and business synonyms so the assistant maps everyday phrasing to the right field.

Natural-language querying

Business questions in plain language returning tables, charts and a written interpretation, with the generated query always visible so an analyst can check it. Follow-up questions keep context, so the interaction is a conversation rather than a series of unrelated prompts.

Verified queries and refusal behaviour

A library of approved query patterns for the questions that matter most, and explicit refusal plus routing to a human when a question needs a metric that has not been defined. An assistant that says "I do not have a definition for that" is far more valuable than one that improvises.

Multi-step investigation

Beyond single-answer lookups: funnel and cohort analysis, segmentation to find where a change originated, period comparison, scenario comparison and explainable root-cause — with the chain of reasoning shown.

Executive narrative generation

Turning a set of results into an executive-ready summary: what changed, by how much, what drove it, what is uncertain and what decision it implies — in the register your leadership actually reads.

Delivery where people work

In Slack or Teams, embedded in your BI tool, or as a standalone interface. Most adoption comes from meeting people where they already ask their colleagues, not from another tab they have to remember.

Accuracy measurement and monitoring

A golden question set with known-correct answers, run on every release, tracking answer accuracy, query validity, refusal appropriateness and latency — published so trust is based on evidence rather than impressions.

Access control and row-level security

The assistant inherits your existing permissions. Row- and column-level security is enforced at the data layer, so a user can never see through the assistant what they could not see in the warehouse.

Platforms & Tooling

  • Snowflake
  • BigQuery
  • Databricks
  • dbt Semantic Layer
  • Cube
  • Looker
  • Power BI
  • Claude
  • OpenAI
  • Slack
  • Microsoft Teams

Process

Week 1–2

Assess

Model readiness, question inventory, permission model review.

Week 3–6

Define

Semantic layer, metric ownership, synonyms, verified queries.

Week 7–10

Build

Assistant, interface, security integration, refusal behaviour.

Week 11–12

Evaluate

Golden set, accuracy baseline, tuning, pilot group.

Ongoing

Adopt

Rollout, training, question-log review and model extension.

FAQs

Built-in assistants work well when your model is already governed and your questions are simple. They struggle with cross-source questions, ambiguous business language and anything needing a multi-step investigation — and none of them will build your semantic layer for you. Often the right answer is to use the native feature and spend the effort on the model underneath it; we will say so if that is the case.

It says so, explains what is missing, and offers to route the question to an analyst. That refusal behaviour is designed and tested, not incidental. We track how often it fires, because a rising refusal rate is a useful signal about what to add to the model next.

Yes, provided those sources are modelled into the same semantic layer with a resolved identity and a consistent grain. Cross-source questions are exactly where this pays off, and also exactly where an ungoverned text-to-SQL approach fails hardest.

A golden set of questions with agreed correct answers, run automatically on every change, with the results published. We agree an accuracy threshold before launch and treat a regression as a release blocker.

No. Conversational BI handles the long tail of ad-hoc questions; dashboards remain better for monitoring a known set of metrics. In practice a good conversational layer reduces dashboard sprawl because people stop building a new view for every one-off question.

Named people in your business, one per metric. We set up the model, the review process and the change workflow, but ownership has to sit inside the organisation or the definitions drift again within a year.

Ready To Make Your Data Work Harder?

Let’s build a trusted measurement foundation that drives smarter decisions and measurable growth.

Book A CallBook an audit