A weekly review gets easier when everyone can start with the same numbers. The harder part is deciding which numbers deserve that place. Revenue might be ahead of plan while margins slip, or a support team's typical reply time might look healthy while some customers wait much longer.
A KPI dashboard brings those measures together with the targets and context needed to judge them. We use it to decide where to look next, then return to the underlying analysis when something needs explaining.
Below, we’ll work through eight KPI dashboard examples, from sales and marketing to engineering and executive reporting. Each has a specific audience, four defined KPIs, and charts chosen around a decision. We’ll then show how to use Codex with Deepnote MCP to build a dashboard from a connected data source.
The eight dashboard examples use fictional data and illustrative targets for July through September 2026.
They demonstrate dashboard design, not industry benchmarks or Deepnote's business performance. Finance and executive views share financial figures; the other examples represent separate scenarios.
What is a KPI dashboard?
A KPI dashboard is a focused view of key performance indicators: measures a team uses to judge progress toward its goals. It combines current results with enough context to interpret them, usually a target, a previous period, or a trend.
The word key does some work here. A database can contain thousands of metrics. The dashboard should help its audience answer a smaller question, such as whether sales are on plan or whether releases are becoming less reliable.
A report usually develops an explanation for a particular period or question. A dashboard supports repeated checks as the figures change. A report can include a dashboard, and a spreadsheet tab can function as one. Putting several charts on a tab, however, does not automatically give them a shared purpose.
We look for a clear connection between the result and the next decision. “Conversion is 4%” leaves us guessing. “Conversion is 4%, below our 5% target for completed September cohorts” gives us somewhere to start.
1. Sales KPI dashboard
The sales leader needs to know whether the team is closing enough business and whether the next month has sufficient opportunities. Bookings and pipeline belong together, but they measure different things.
- Bookings and win rate: Bookings are the signed contract value closed during the month. Win rate divides won deals by all won and lost deals closed in that month.
- Pipeline coverage and sales cycle: Coverage divides month-end open pipeline scheduled for next month by next month's bookings target. Sales cycle is the median number of days from opportunity creation to close among won deals.
We use a line graph for monthly bookings and grouped bars for regional bookings against targets. The open pipeline is unweighted: its full value is not a forecast of what will close.
In September, bookings rise again, but win rate falls and the typical winning deal takes longer to close. Pipeline coverage also remains below its illustrative target. The upward bookings line alone would make this a more comfortable review than the full dashboard supports.
The next question is which regions and opportunity stages need attention, not whether the team can add more activity to a tile.
2. Marketing KPI dashboard
A marketing KPI dashboard should connect acquisition spending to the demand it produces. For this example, we follow qualified leads through sales acceptance and opportunity creation.
- Qualified leads and cost per qualified lead: Count distinct leads meeting the team's agreed qualification rule, then divide tracked campaign spending by that count. This cost is not customer acquisition cost.
- Sales acceptance and opportunities created: Acceptance is the share of qualified leads accepted by sales. Opportunities count the distinct sales opportunities created from that month's qualified-lead cohort by month-end.
The lead trend shows volume. A bubble chart comparing regional campaigns adds a market map: position shows spending and sales acceptance, while bubble area represents estimated addressable accounts. Each bubble is one regional campaign, not one customer.
September produces more qualified leads, but each costs more and a smaller share is accepted by sales. The largest estimated market also has the lowest acceptance rate in the regional view. Market size supplies context; it does not establish that more spending there will pay off.
Before changing budgets, check the qualification rule, campaign mix, and follow-up timing. Month-end opportunity counts also give late-arriving leads less time to progress, so a fixed follow-up window is better for a formal cohort comparison.
3. Product KPI dashboard
For a product team, account growth can conceal a weaker onboarding experience. We put activity beside measures of whether new accounts reach value and return.
- Seven-day activation and four-week retention: Activation is the share of eligible new accounts that create a first project within seven days. Retention is the share of eligible activated accounts completing a core action in week four.
- Weekly active accounts and task success: Active accounts complete a core action in the last full Monday-through-Sunday week of the month. Task success counts successful attempts across a small scripted usability study.
Activation and retention cohorts are assigned to the month their observation window ends. An account still waiting to complete four weeks is not counted as a retention failure.
We pair the activation trend with a radar view of task success. Its four spokes all show percentages on the same 0-to-100 scale, with 20 attempts per task. The scores have a defined denominator; they are not unexplained ratings of “UX” or “quality.”
Weekly activity rises while activation and retention fall. Export is the weakest task in the small usability study, giving the team a place to investigate. It does not prove that export difficulties caused the retention decline. We would inspect affected cohorts before joining those findings into one explanation.
4. Finance KPI dashboard
Finance needs to distinguish growth from the cash and margin available to sustain it. This example keeps recognized revenue separate from sales bookings and cash receipts.
- Revenue and gross margin: Revenue is recognized during the month. Gross margin is revenue minus cost of revenue, divided by revenue.
- Closing cash and overdue receivables: Cash is the month-end balance. Overdue receivables divide overdue outstanding invoice dollars by all outstanding invoice dollars at month-end.
A revenue line sits above an operating-expense heatmap. The grid shows percentage variance from budget by department and month, with positive values meaning overspending. Those operating expenses are separate from the cost of revenue used in gross margin.
Revenue reaches its September target, but gross margin declines, cash falls below the example's management floor, and a larger share of receivables is overdue. Revenue growth has not translated into an equally strong cash position. The dashboard identifies the tension; a cash-flow reconciliation would explain its causes.
5. Customer support KPI dashboard
Support managers need to see both completed replies and customers still waiting. A dashboard based only on answered tickets can look better while an unreplied backlog grows.
- Median and 90th-percentile first reply: Both measure elapsed minutes from ticket creation to the first human response, among tickets receiving that response during the month. The median describes a typical wait; the 90th percentile helps reveal longer waits.
- Replies within 30 minutes and unreplied backlog: The first is the share of replied tickets meeting that threshold. The backlog counts open tickets without a human reply at month-end, including older arrivals.
We use a median trend and box plots of reply times by queue. Each queue contains 10 replied tickets in this deliberately small example, with individual observations shown. The backlog remains separate because unreplied tickets have no completed first-response time.
September's median still meets the 15-minute target, but the longer waits and backlog need attention. The technical queue has a wider spread and several long waits. A single median would understate that difference in customer experience.
The 30-minute measure is not an overall service-level agreement compliance rate. That would also need a rule for tickets still waiting after the deadline, business hours, and any agreed exclusions.
6. Operations KPI dashboard
Our operations example follows order fulfillment. The audience is deciding where to investigate dispatch delays and quality problems, rather than simply celebrating more throughput.
- On-time dispatch and dispatch cycle: On-time dispatch is the share of orders due in the month sent by their promised date. The cycle measures median days from acceptance to dispatch among dispatched orders.
- Defect rate and open backlog: Defect rate divides orders with a recorded defect by inspected orders. Backlog counts accepted orders not yet dispatched at month-end.
The on-time trend shows whether service is holding up. Bars comparing late orders by warehouse locate the largest contribution to the month's missed deadlines.
September combines lower on-time dispatch with a larger backlog and more defects. The South warehouse contributes half the late orders. That makes it a useful starting point for investigation, but the count alone does not establish that its performance is worst: a busier warehouse can have more late orders and a better rate.
For a fair warehouse comparison, add the number of orders due at each location and calculate its late-dispatch rate. The example's bars answer where the late orders are concentrated.
7. Engineering KPI dashboard
For one application, we want to know whether delivery is getting faster without becoming less reliable. Counting deployments alone misses the second half of that question.
- Production deployments and change lead time: Count completed production deployments during the month, and measure median hours from code commit to successful production deployment.
- Change fail rate and recovery time: Fail rate is the share of deployments requiring immediate remediation. Recovery measures median hours to restore service after failed deployments resolved during the month.
These measures draw on DORA, short for DevOps Research and Assessment, a research program that studies how teams deliver software. Its delivery metrics help teams assess how quickly changes reach production and how reliably those changes run.
The dashboard pairs a deployment trend with monthly change fail rates. It covers four delivery measures; DORA’s current five-metric model also includes deployment rework rate, the share of deployments made unexpectedly in response to production incidents. The deployment target here is an illustrative planning baseline, not an individual developer quota.
Deployments increase and lead time falls, but failure rate and recovery time worsen. The team is shipping faster while taking longer to recover from failed releases. We would examine the failures and release process before treating deployment volume as a success on its own.
Keep these measures at a meaningful team or application level. They do not measure an individual engineer's productivity.
8. Executive dashboard
An executive dashboard should help leadership choose where to spend attention. Copying every department's tiles into one page usually makes that harder.
We retain the finance view's definitions for recognized revenue, gross margin, and closing cash. The fourth KPI is customer retention: the share of customers paying at the start of the month who are still paying at its end. New customers are excluded from that denominator.
A line graph tracking revenue against plan provides the growth view. Separate bars compare margin and retention with their respective targets. Both are percentages, but they describe different populations and should be judged against their own goals.
Revenue is growing while margin, cash, and retention weaken. The dashboard gives leadership a reason to review the quality of that growth. It does not tell us whether one problem caused the others.
In a working company dashboard, each measure should lead to its owning team's analysis. We keep the shared financial definitions intact so leadership and finance can discuss the same number without reconciling two versions first.
How to choose KPIs for a dashboard
Start with the decision and the person responsible for it. A metric belongs on the main view when a change could lead that person to investigate, act, or revise a plan.
We usually start with five to seven KPIs per view, then cut further when the question allows it. The examples use four. This is a design starting point, not a rule that every dashboard must reach a particular tile count.
Pair leading and lagging indicators
Lagging indicators describe outcomes already achieved, such as bookings or customer retention. Leading indicators track conditions or activity expected to influence later outcomes, such as qualified pipeline for next month's sales.
The relationship depends on the question. Activation is an onboarding outcome, but it may be a leading indicator for later retention. That relationship still needs evidence; labeling something “leading” does not make it predictive.
Pair an outcome with a measure the team can act on, then check whether the relationship holds in your data.
Write the definition before designing the tile
A useful KPI definition names the calculation, eligible population, time window, and owner. It also states the target and what happens when it is missed.
For example, “win rate” needs a denominator. Won deals divided by all closed deals answers a different question from won deals divided by every opportunity created that month. Both might be useful, but they cannot share a label without an explanation.
For rates, keep the underlying counts available. Calculate a combined rate from combined numerators and denominators; averaging regional percentages can give small regions too much influence.
Which chart type should you use for each KPI?
We choose the chart around the comparison, not around a desire to make every tile look different.
What the reader needs to judge | Chart choice | Context to retain |
|---|---|---|
Current result against a target | Number with target and status, or a bullet chart | Unit, period, target direction |
Change across periods | Line graph | Date order, comparable periods, gaps |
Differences between teams or regions | Bar graph | Common scale and relevant group sizes |
Typical values and variation | Box plot | Sample size, whisker rule, excluded records |
A relationship with a third quantity | Bubble chart | Axis units and area-scaled bubbles |
A small profile of comparable scores | Radar chart | Consistent scale and scoring definitions |
Patterns across a matrix or portfolio | Heatmap | Defined color scale and values on inspection |
Our line graph guide, bar graph guide, and box plot guide cover those choices in more detail. For a broader comparison, use the guide to types of graphs.
A target should also have a direction. Higher bookings may be desirable; higher recovery time usually is not. A green upward arrow applied to every KPI gets that wrong.
How to build a KPI dashboard with Codex and Deepnote MCP
A dashboard starts with a question and a data source. With Deepnote MCP, Codex or Claude can inspect connected data, write and run notebook calculations, and build an application in Deepnote. The analysis stays in the project, where the team can review the queries and refine the definitions.
For this walkthrough, we use a pizza-sales dataset with order dates, product categories, quantities, and line-item prices. The dashboard tracks revenue, orders, pizzas sold, and average order value. Counting distinct orders matters here: an order containing several pizzas can occupy several rows.
Connect the data and the assistant
The data source connects to Deepnote through an integration. Codex connects to that workspace through Deepnote MCP, giving it access to the projects and integrations allowed by the connection’s permissions. Claude can use the same MCP server.
With both connections available, give the assistant the source, metric definitions, and dashboard requirements:
Build a pizza-sales KPI dashboard in Deepnote using the connected Pizza Sales source.
Inspect the order data and its date range first. Calculate revenue, distinct orders, pizzas sold, and average order value for a selected month. Count each order once, even when it contains multiple line items, and calculate average order value as revenue divided by distinct orders.
Show four KPI cards, a daily revenue trend, and revenue by pizza category. Add month and category filters that update every view consistently. Compare results with the previous month when the data cover comparable periods.
Keep the SQL, calculations, and checks in a Deepnote notebook. Run the analysis, reconcile the totals, and build a dashboard hosted in Deepnote. Label the reporting period and data freshness, then return the notebook and dashboard links.
For November 2015, the dashboard shows 1,792 orders, 4,266 pizzas sold, and revenue of 70,395.35, giving an average order value of 39.28. Revenue and average order value use the source’s unconfirmed currency. The daily and category revenue totals reconcile with the revenue card, and independent SQL checks matched the notebook calculations across all 60 month-and-category selections.
The month and category filters update all four KPIs and both charts from a saved data snapshot. Refreshing the source data requires rerunning the notebook and reloading that snapshot. November’s prior-month comparisons are unavailable because October has four dates without records, and the source does not establish whether those gaps represent closures or missing data.
Review the calculations and refine the dashboard
The review should cover both the figures and the interface:
- Check the totals. Daily revenue and category revenue should reconcile with the revenue card. Order counts should use distinct order IDs.
- Check the controls. Changing the month or category should update the cards and charts together, including their labels and comparisons.
Follow-up requests can extend the analysis without rebuilding the dashboard. For example:
Add a view comparing revenue growth with order growth. Keep the existing KPI definitions and show the calculations behind both percentage changes.
The notebook lets you inspect how each number was calculated, while the dashboard gives readers a focused view of the results. Deepnote supports hosting and sharing custom Streamlit apps, including interfaces built with an external coding agent. You can also publish notebook outputs as an interactive data app.
Common KPI dashboard mistakes
Tracking activity without an outcome
Visits, signups, and deployments can be useful, but they become vanity metrics when you treat growth as success without considering the goal. Pair acquisition volume with qualification or retention, and delivery speed with reliability.
Showing a number without a target or comparison
A value needs a reference. Use an agreed target, a comparable previous period, or a meaningful baseline. If no defensible target exists, say so and show the trend; an invented red-green threshold adds certainty the team does not have.
Adding every requested tile
A dashboard becomes hard to use when every follow-up question gets another permanent chart. Keep the main view focused and put detailed investigation in a linked analysis or a separate view. Different audiences can share definitions without sharing the same page.
Losing the date and population context
“September retention” is ambiguous until we know which accounts were eligible and how long they were observed. Partial months, immature cohorts, and stale sources can all produce plausible numbers that answer the wrong question.