KPI Dashboards Are Broken. Here's What Replaces Them.

Your company has a KPI dashboard. It was built six months ago by someone who has since moved teams. It shows revenue, churn, and a few product metrics. It loads slowly. The numbers don’t match what finance reports. Nobody trusts it, but everyone screenshots it for the Monday standup.

This is the state of KPI dashboards at most companies. Not because the tools are bad, but because the approach is wrong. A dashboard is a static view of a dynamic system. The moment someone builds it, it starts drifting from reality.

What is a KPI dashboard?

A KPI (Key Performance Indicator) dashboard is a visual display of an organization’s most important metrics. Revenue, customer count, churn rate, conversion rate, average order value, NPS. The metrics that tell you whether the business is healthy.

Traditional KPI dashboards live in a BI tool: Power BI, Tableau, Looker, Metabase, Grafana. An analyst builds the dashboard, connects it to a data source, and shares a link. People visit the dashboard (or receive a scheduled screenshot) to check the numbers.

The concept is sound. The execution breaks for predictable reasons.

KPI dashboard examples

Before diving into what’s broken, here’s what teams typically build:

SaaS executive dashboard. MRR, ARR, net revenue retention, churn rate, new customers this month, average contract value. Updated daily. Viewed by the CEO and board. The numbers must match the finance team’s report exactly.

Product analytics dashboard. Daily active users, feature adoption rates, conversion funnel stages, time to value. Updated hourly. Viewed by product managers. Often the first dashboard built and the first to drift from reality.

Customer health dashboard (B2B). Per-customer usage metrics, support ticket volume, NPS, renewal risk score. Updated daily. Viewed by customer success. In embedded analytics use cases, the customer sees this too.

Engineering operations dashboard. API error rates, p95 latency, deployment frequency, uptime. Updated real-time. Viewed by engineering leads. Often built in Grafana rather than a BI tool.

Sales pipeline dashboard. Open deals by stage, weighted pipeline value, win rate, average deal cycle. Updated daily. Viewed by sales leadership. Usually lives in Salesforce or a connected BI tool.

Each of these follows the same pattern: connect to a data source, write queries, build charts, share a link. The problems start when multiple dashboards need the same metric (revenue, active users, churn) and define it differently.

Why KPI dashboards fail

The metrics drift

Revenue is defined in the dashboard as SUM(amount) WHERE status = 'completed'. Finance defines it as SUM(amount) WHERE status != 'refunded' AND type != 'trial'. The CFO looks at the dashboard, compares it to the finance report, and stops trusting the dashboard. This happens every quarter at companies without a shared metric layer.

The root cause: business logic is defined in the dashboard, not in a governed layer. Every dashboard that shows revenue re-implements the calculation. Each implementation drifts independently.

Nobody opens them

Dashboards that load in 8 seconds don’t get used. Dashboards behind a BI tool login don’t get used. Dashboards that require navigating to a separate tool don’t get used. The data team builds 50 dashboards. Three get regular traffic. The rest are abandoned.

The data team keeps building new ones because stakeholders keep asking. Each request means a new dashboard, a new query, a new maintenance burden. The team becomes a dashboard factory instead of building the metrics layer that would make dashboards unnecessary.

They only serve one surface

A KPI dashboard in Looker serves people who open Looker. What about:

• The product team that wants metrics in their React app?
• The customer success team that wants account health in Slack?
• The AI agent that needs to answer “how’s revenue trending?”
• The B2B customer that wants their own usage dashboard inside your product?
• The executive who wants a weekly email summary?

Each of these requires a different integration. The dashboard metric definitions don’t transfer. You end up rebuilding the same KPIs in every tool, with each copy drifting independently.

Stale data, stale insight

Most KPI dashboards refresh on a schedule: hourly, daily, sometimes manually. Between refreshes, the numbers are stale. For operational KPIs (active users right now, orders this hour, API error rate), stale data is useless data.

Even with real-time refresh, the dashboard is a passive display. It shows numbers. It doesn’t answer questions. “Revenue is down 12% this week” is visible on the dashboard. “Why?” requires a human to open the BI tool, write a query, drill into dimensions, and figure it out. An AI agent could answer that question in seconds, but the dashboard can’t feed an agent.

The alternative: a KPI chart the agent renders on demand

The static dashboard is a snapshot someone built once. The agent path is different: instead of opening a tool and reading a chart someone else laid out, you ask “how’s revenue trending?” and the agent runs the query and draws the chart in the conversation.

That last step (drawing the chart) is what @bonnard/mcp-charts adds: a visualize tool you add to your MCP server that renders interactive charts from your query results. The agent already has access to your data. The visualize tool turns the rows it gets back into a chart the person can actually read.

Add the visualize tool

npm install @bonnard/mcp-charts

import { addCharts } from "@bonnard/mcp-charts";

// runSql runs against your warehouse and returns typed rows
addCharts(server, { runSql });

addCharts registers a visualize tool (plus a visualize_read_me companion) on your MCP server. Bonnard never touches your database. Your runSql does, against Postgres, BigQuery, Snowflake, Databricks, DuckDB, or any source you wire up.

How a KPI request flows

1. Someone asks the agent “how’s MRR trending this quarter?”
2. The agent calls visualize with a query, and your runSql returns the rows.
3. Bonnard infers the chart from the typed result: a line chart for MRR over time, a bar chart for revenue by plan, a funnel for a conversion sequence.
4. Claude or ChatGPT renders an interactive ui:// widget right in the conversation.

The chart types cover the KPI cases you’d reach for on a dashboard: line, bar, and area for trends, bar variants (stacked, grouped, horizontal, 100%) for breakdowns, pie for shares, scatter for distributions, funnel and waterfall for staged metrics, and a table when the answer is a table. Axes, number formatting, and gap-fill come from the typed schema, so the same KPI query renders the same chart every time.

No dashboard to patch. The KPI gets drawn the moment someone asks, from whatever query answers the question.

KPI dashboard tools compared

Approach	Metric governance	Surfaces	AI agent support	Multi-tenant	Performance
Power BI dashboard	DAX (locked to PBI)	Power BI only	Copilot (internal)	Complex	Import mode or DirectQuery
Tableau dashboard	Semantic model (locked)	Tableau only	Limited	Enterprise	Extract or live
Looker dashboard	LookML	Looker + embed	No	Enterprise	PDTs
Metabase dashboard	None	Metabase + embed	No	Enterprise only	No caching
Grafana dashboard	None	Grafana only	No	Basic	Query-level
Superset dashboard	None	Superset + embed	No	Limited	No caching
Bonnard	Inherits your runSql	Claude and ChatGPT (MCP apps)	MCP native (visualize tool)	Inherits your runSql	Inherits your warehouse

The traditional tools render KPIs inside the dashboard tool. Bonnard renders them as interactive charts via the MCP visualize tool, from query results, inside Claude or ChatGPT.

When to keep your KPI dashboard

KPI dashboards aren’t always wrong. They work when:

• One team, one tool, one audience
• The metrics are simple and stable
• Nobody else needs the same numbers in a different format
• You don’t need AI agent access or embedded analytics
• The dashboard builder is still on the team and maintains it

They break when:

• Multiple teams need the same KPIs in different tools
• Customers need to see their metrics inside your product
• AI agents need to query KPIs
• The dashboard shows different numbers than finance reports
• The data team spends more time maintaining dashboards than defining metrics

Getting started

Add a visualize tool to your MCP server so an agent can render a KPI chart on demand:

npm install @bonnard/mcp-charts

import { addCharts } from "@bonnard/mcp-charts";

addCharts(server, { runSql });

That registers the visualize tool on your server. Someone asks the agent for a KPI, your runSql returns the rows, and Bonnard renders an interactive chart inside Claude or ChatGPT. Adapters ship for Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql.

Full walkthrough: Add Interactive Charts to Your MCP Server. For the design choices behind the tool: How Bonnard Builds Agent-Friendly MCPs.

Source is on GitHub.

Frequently asked questions

What is a KPI dashboard?

A KPI dashboard is a visual display of key performance indicators: revenue, churn, active users, conversion rate, and other metrics that measure business health. Traditional KPI dashboards live in BI tools like Power BI, Tableau, Looker, or Grafana. Modern approaches define KPIs in a semantic layer and serve them across dashboards, AI agents, and embedded analytics simultaneously.

What KPIs should be on a dashboard?

The KPIs depend on your business. Common B2B SaaS KPIs: MRR, ARR, churn rate, net revenue retention, active users, customer count, NPS, average contract value. The specific metrics matter less than the governance: every KPI should have one canonical definition that every consumer references.

What is the best KPI dashboard tool?

For internal-only dashboards: Power BI (Microsoft ecosystem), Tableau (Salesforce ecosystem), Looker (Google Cloud), or Metabase (open source). For governed KPIs served to multiple surfaces including AI agents and embedded analytics: a semantic layer approach. The right choice depends on how many consumers need the same metrics.

How do I make my KPI dashboard load faster?

Most dashboard slowness comes from querying the warehouse on every render. Pre-aggregation caching pre-computes common KPI rollups. The dashboard queries the cache instead of the warehouse. Response times drop from seconds to single-digit milliseconds.

Can AI agents query KPIs?

With a semantic layer and MCP support, yes. AI agents discover available KPIs via explore_schema and query them via query. The agent gets governed, multi-tenant data scoped to their access level. Without a semantic layer, agents generate ad-hoc SQL and return inconsistent numbers. See What Is an Agentic Semantic Layer?.

What is the difference between a KPI dashboard and analytics dashboard?

A KPI dashboard focuses on a small set of headline metrics that measure business health. An analytics dashboard provides broader exploration: filtering, drilling, and ad-hoc querying. In practice, both benefit from governed metric definitions. The KPI dashboard shows the numbers. The analytics dashboard lets you investigate why they changed.

How often should a KPI dashboard refresh?

Depends on the KPI. Revenue and churn: daily or hourly. Active users and API metrics: real-time or near-real-time. Strategic KPIs (NPS, retention cohorts): weekly or monthly. With pre-aggregation, refresh frequency is configurable per metric. Set aggressive refresh for operational KPIs and relaxed refresh for strategic ones.