KPI Dashboards Are Broken. Here's What Replaces Them.
KPI dashboards show stale numbers that nobody trusts. Governed metrics served through a semantic layer give every consumer the same live data, from dashboards to AI agents.
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: governed metrics that serve every surface
Instead of building KPI dashboards per tool, define your KPIs once in a semantic layer and serve them to every consumer.
Define your KPIs as code
cubes:
- name: business_kpis
sql_table: analytics.daily_metrics
measures:
- name: total_revenue
sql: "CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END"
type: sum
description: "Total revenue excluding refunds and trials (finance-approved definition)"
- name: active_users
sql: user_id
type: count_distinct
description: "Users with at least one event in the period"
- name: churn_rate
sql: "CASE WHEN churned = true THEN 1.0 ELSE 0.0 END"
type: avg
description: "Percentage of customers who churned in the period"
- name: mrr
sql: monthly_amount
type: sum
description: "Monthly recurring revenue from active subscriptions"
- name: nps_score
sql: score
type: avg
description: "Net promoter score from latest survey responses"
dimensions:
- name: plan
sql: plan_name
type: string
- name: region
sql: region
type: string
- name: created_at
sql: created_at
type: time
These definitions live in Git. Finance reviews the revenue definition in a pull request. When the definition changes, every consumer gets the update on the next bon deploy. No dashboard patched. No query rewritten. One diff in your schema repo.
Cache for instant load times
The reason dashboards load slowly: every chart queries the warehouse on render. With pre-aggregation, the semantic layer pre-computes your most common KPI queries:
pre_aggregations:
- name: daily_kpis
measures:
- total_revenue
- active_users
- mrr
- churn_rate
dimensions:
- plan
- region
time_dimension: created_at
granularity: day
refresh_key:
every: 1 hour
KPI queries hit the cache. Single-digit millisecond responses. Your dashboard loads instantly because it's not scanning raw tables on every render.
Serve every surface from one definition
The same KPI definitions serve:
Dashboards. Author in markdown, deploy with bon dashboard deploy. Each dashboard queries the same governed metrics. No separate BI tool needed.
React components in your product. For B2B products, embed customer-facing KPIs with BigValue, LineChart, BarChart, and other components from @bonnard/react. Each customer sees their data through the same metric definitions.
AI agents. Connect any MCP-compatible agent (Claude, Cursor). The agent calls explore_schema, discovers your KPIs, and answers questions like "why is churn up this month?" using governed data. Run bon mcp to get connection configs.
REST API. Backend services, scheduled reports, Slack integrations. Query KPIs programmatically with the same definitions.
TypeScript SDK. Type-safe KPI queries from @bonnard/sdk for custom applications.
One definition of total_revenue. Five surfaces. Same number everywhere.
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 |
| Semantic layer (Bonnard) | YAML (versioned, portable) | Dashboards + React SDK + API + AI agents | MCP native | Structural | Pre-aggregation cache |
The traditional tools define metrics inside the dashboard tool. The semantic layer defines metrics outside any tool and serves them to all of them.
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
Replace your static KPI dashboard with governed metrics:
Cloud:
npm install -g @bonnard/cli
bon init
bon deploy
Self-hosted:
npm install -g @bonnard/cli
npx @bonnard/cli init --self-hosted
docker compose up -d
bon deploy
bon init generates agent configs for Claude Code, Cursor, and Codex. Define your KPIs in YAML. Run bon deploy. Use bon mcp to connect AI agents, bon dashboard deploy for markdown dashboards, or @bonnard/react for embedded charts. Use bon diff to preview changes and bon schema to explore deployed metrics from the CLI.
Full tutorial: How to Connect an AI Agent to Your Data Warehouse. For background: What Is a Semantic Layer?.
Self-host free under Apache 2.0, or use Bonnard Cloud for managed infrastructure.
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.
Ready to ship a customer-ready MCP?
Turn your semantic layer, dbt, or warehouse into a governed, per-customer MCP for your customers' agents.