Back to case studies
B2B Analytics

From analyst queue to self-serve analytics for operators

A 22-person B2B SaaS had a warehouse that 30 operators could not query without help from two analysts. We built a natural-language layer on top of a governed semantic model and shipped it inside the existing product.

Timeline:8 weeks · semantic foundation to production handover
Delivery:Production handover
Charts and metrics in an analytics workspace

Project snapshot

The small-team operating context

The delivery and value signals below are anonymized and rounded so the operating scale is visible without exposing the client.

Client context

B2B SaaS company · 22 employees · 2 analysts · ~30 non-technical operators

Delivery team

2 engineers + 1 product lead with the data lead and operator representatives

Sponsor

Head of Operations

Analytics adoption

4× in a quarter

Weekly active analytics users

Project-reported

Analyst capacity

~15 hrs/week

Directional repeat-question capacity

Directional model

Answer boundary

Governed first

Semantic definitions before generation

Project-reported

Production signal

  • Operators asked questions inside the product instead of opening a new analyst request for every follow-up.
  • Generated SQL and metric definitions stayed visible for review.
  • Ambiguous, sensitive, or high-impact questions continued to route to the data team.

What we learned

  • Build the semantic layer before adding natural-language generation.
  • Treat metric ownership as a product workflow, not a data-cleanup task.
  • Measure answer quality and business action separately from query volume.
Delivered: Governed semantic model · Embedded natural-language analytics workspace · SQL review and metric-governance runbook

Actual process teardown

How the operating process changed

The important change is not a model in isolation. It is the full operating path around the model: inputs, orchestration, controls, review, and the system of record.

The challenge

Two analysts were translating repeat questions from sales, support, and operations into SQL while the people closest to the business waited for answers. Metric definitions lived in dashboards and tribal knowledge, so every follow-up risked creating a different version of the truth.

The production response

We inventoried the questions and definitions first, built the semantic layer in dbt, and added a natural-language query loop that shows the generated SQL, source metrics, and result context. Ambiguous or high-impact questions still route to an analyst.

Before · manual baseline

  1. 01

    Ask the data team

    Business user

    Operators submitted questions to two analysts instead of querying the warehouse directly.

  2. 02

    Interpret the request

    Analyst

    Analysts translated informal language into SQL and clarified which metric definition the request meant.

  3. 03

    Build and validate the report

    Analyst

    A one-off query or dashboard was created, checked, and shared back through a channel or document.

  4. 04

    Wait for the next question

    Business user + analyst

    Follow-ups created another queue item and repeated the same context gathering.

After · AI-assisted production

  1. 01

    Ask in business language

    Business user

    Operators ask a question inside the existing product workspace.

  2. 02

    Ground in governed definitions

    System

    The semantic layer constrains metrics, dimensions, joins, access rules, and allowed data domains.

  3. 03

    Generate and explain the query

    AI

    AI translates the question into traceable SQL and presents the result with metric context and citations.

  4. 04

    Review and act

    Human user + analyst

    Users validate the insight, ask follow-ups, or route an ambiguous answer to an analyst before acting.

Phase-by-phase delivery

What was delivered, in order

Each phase turns the process teardown into a concrete production deliverable, with a clear value created before the next layer is added.

  1. 01Delivery phase

    Inventory the questions

    Understand what operators ask, where analysts spend time, and which definitions cause rework.

    Delivered

    • Question and analyst-queue inventory
    • Metric ownership map
    • Access and data-quality constraints

    Value created

    The system targets repeatable decisions and clarifies where natural language is safe to use.

  2. 02Delivery phase

    Build the semantic foundation

    Make business definitions explicit before allowing AI to generate queries.

    Delivered

    • dbt-backed metric and dimension model
    • Approved joins and access policies
    • Definition tests and sample questions

    Value created

    Answers become grounded in the organization’s language rather than inferred from raw column names.

  3. 03Delivery phase

    Ship the query-and-explain loop

    Translate questions into traceable queries and make the result understandable to the operator.

    Delivered

    • Intent and domain routing
    • SQL generation and execution
    • Result explanation, citations, and follow-up handling

    Value created

    Users can move from question to action without creating a new analyst ticket for every iteration.

  4. 04Delivery phase

    Govern adoption

    Measure usage and quality while routing ambiguous or high-impact questions back to analysts.

    Delivered

    • Embedded analytics workspace
    • SQL and answer review path
    • Feedback loop for definitions and data quality

    Value created

    Self-service expands without creating a second, invisible reporting layer.

How to read this teardown: the delivery sequence combines the existing public-safe project narrative with a practical view of the production work around it. It does not add client names, confidential implementation details, or unverified performance claims.

Measured and modeled impact

Separate the outcome from the value hypothesis

Project-reported outcomes are shown alongside directional models. Public benchmark figures are kept in their own evidence section below.

Analytics access

Project-reported

Weekly active users grew 4×

Before

Two analysts triaging repeat questions

After

Natural-language workspace with governed definitions

Interpretation boundary

Anonymized and rounded project-reported adoption outcome supplied for this case study; independently unverified in the public view.

Value model
Directional model

Decision velocity and analyst capacity

For a small SaaS, the value comes from letting roughly 30 operators answer common questions while the two-person data team focuses on durable analytics work.

Model

Decisions accelerated × value per decision + analyst hours released × loaded analyst cost − workflow operating cost

Assumptions to validate

  • The ~15-hour weekly capacity estimate is validated through queue and time sampling.
  • Users take a measurable action from the insight.
  • Released analyst capacity is redeployed rather than removed from the model.

ROI scorecard

Value across time, money, resource, output, and error

Each teardown shows the practical ROI lens for the transformation. Existing project signals stay labeled; financial impact remains a transparent model until baseline volumes, costs, and quality data are verified.

Time
Directional model

~15 hrs/week potential

Directional model: repeat questions move out of the two-analyst queue and into a governed workspace.

Money
Directional model

Analyst capacity + decisions

Model analyst hours released plus the value of decisions made sooner from trusted operational data.

Resource
Directional model

Two analysts refocused

The data team can spend less time translating repeat questions and more time on durable models, quality, and planning.

Output
Project-reported

Adoption grew 4×

Weekly active analytics users grew fourfold in a quarter in the existing project report.

Error
Directional model

Less metric drift

Governed definitions, traceable SQL, and analyst routing reduce inconsistent answers across teams.

ROI should be finalized against the client baseline: loaded labor cost, transaction volume, unit economics, throughput, and measured error or denial rates. The directional model is a value pathway—not an invented client result.

System blueprint

The production system around the AI

The tool list shows what each component is responsible for across the application, data, AI, integration, orchestration, and governance layers.

Tools used

Application + AI

TypeScript

Analytics workspace, question routing, and query explanation

Workspace

Next.js

Embedded natural-language analytics experience

Semantic layer

dbt

Metric definitions, dimensions, approved joins, and data tests

Warehouse

BigQuery

Governed query execution and warehouse access boundary

Governance

SQL guardrails

Allowed domains, access policies, generated-query checks, and limits

Operations

Answer feedback loop

Analyst review, definition corrections, and quality instrumentation

Orchestration

  1. 1Natural-language question
  2. 2Intent and domain routing
  3. 3Semantic metric grounding
  4. 4SQL generation
  5. 5Query execution
  6. 6Result explanation and citation
  7. 7User follow-up or action

In-house data and boundary

The system is grounded in the client’s existing operational data rather than an unbounded external corpus.

Warehouse tables and dbt modelsGoverned metric definitionsProduct and customer dataRole-based access policies

Human in the loop

  1. 1Define and approve business metrics.
  2. 2Review generated SQL and edge-case answers.
  3. 3Correct semantic definitions and data-quality issues.
  4. 4Route ambiguous, sensitive, or high-impact questions to an analyst before action.
AI capabilities
Natural-language query translationSemantic retrievalInsight explanationFollow-up question handling

Public benchmark evidence

What the wider market is showing

These sources support the transformation pattern. They are not client-specific outcomes and should not be read as such.

Public benchmark

Snowflake — AI Data Analytics

Snowflake describes semantic context as necessary for reliable natural-language analytics and cites a public example with thousands of monthly analysis queries and analyst-capacity savings.

Why it matters here

Supports the requirement for governed definitions and traceable query generation rather than an unbounded chatbot over raw tables.

External research provides context and benchmarks. It does not verify the anonymized client, implementation, or project-specific results described above.

Names, logos, and specific numbers are redacted in this public view. Full references are available under NDA on request.

Build the next one

Have a workflow that needs a closer look?

Start with the friction you already see. We will help you determine what is worth solving and how to move it safely into production.

Assess my workflow Talk to us