SaaS Dashboard Metrics: What to Track and What to Ignore

01

A dashboard is not a shelf for numbers

Imagine a B2B SaaS company reaching the end of its monthly operating meeting.

Monthly recurring revenue is up. The growth chart is green. Sales has signed several larger customers and the total number of accounts has increased.

The same month also produced the longest onboarding queue so far. Support tickets rose faster than customer numbers. One large account generated far more processing cost than the pricing model assumed, and two customers stopped using the workflow that originally convinced them to buy.

The dashboard did not lie. It simply answered a narrow question.

That is the main problem with many SaaS dashboards. They collect familiar numbers without showing how the business is actually behaving. Revenue, churn, acquisition cost and product usage appear beside one another, but the team still has to work out what changed and what to do next.

A good dashboard should shorten that conversation. It should help somebody notice a material change, understand where it came from and move into the detail needed to make a decision.

The design starts with those decisions, not with the charts.

02

Start with the question each metric must answer

Klipfolio's SaaS dashboard overview makes a useful distinction: growth, customer success, support and other teams need different measures. One executive screen cannot replace all of those operational views.

The sensible starting point is to write down the questions the business regularly needs to answer. For example:

• Is recurring revenue growing for the reason we expected?
• Are existing customers staying and expanding?
• Are new customers reaching a useful result quickly enough?
• Which acquisition channels recover their cost?
• Which customer segments create healthy revenue and support demand?
• Is one tenant or pricing tier putting unusual pressure on the product?
• Are reliability problems affecting customers before the overall system looks unhealthy?

Each question needs four things behind it: a definition, an owner, a review rhythm and a route into more detail.

If net revenue retention falls, somebody should know who investigates it. If onboarding time rises, the team should be able to split the number by customer segment, implementation type and stage. If a critical job starts failing, the operational view should identify the affected tenants rather than showing one harmless-looking global average.

Without that route from signal to action, a dashboard becomes decoration for a meeting.

03

Recurring revenue needs movement, not just a total

Monthly recurring revenue, usually shortened to MRR, normalises subscription revenue into a monthly figure. Annual recurring revenue, or ARR, expresses the recurring amount over a year.

Both are valuable, but neither explains growth on its own.

Return to the imagined SaaS company. Its MRR rises from £118,000 to £126,000. The net increase is £8,000, which looks healthy. That month actually included £18,000 of new MRR and £7,000 of expansion, offset by £12,000 of churn and £5,000 of contraction.

The ending number is correct. The movement tells the useful story.

A revenue view should separate at least:

• new MRR from first-time customers;
• expansion from upgrades, extra seats or higher usage;
• reactivation from returning customers;
• contraction from downgrades or reduced usage;
• churn from customers leaving;
• one-off implementation or professional-service revenue that should not be treated as recurring.

The definitions must remain stable. Including one-off setup fees one month and excluding them the next can create growth that exists only in the spreadsheet. Annual contracts, discounts, credits, pauses and usage charges also need an agreed treatment.

Once those rules are clear, revenue can be split by plan, customer segment, acquisition source and cohort. The business can then see whether growth comes from the target market or from a collection of accounts that need a different product and service model.

04

Retention shows whether customer value repeats

New sales can hide a retention problem for longer than people expect.

Logo retention counts customers. Gross revenue retention, or GRR, measures how much recurring revenue remains from an existing group after churn and contraction, before any expansion is added. Net revenue retention, or NRR, includes expansion from those retained customers.

Suppose a customer cohort starts with £100,000 MRR. It loses £9,000 through churn and £4,000 through contraction, then gains £16,000 through expansion. GRR is 87%. NRR is 103%.

The business has more revenue from that cohort, but it still lost £13,000 from customers who left or reduced their spend. NRR and GRR belong together because they answer different questions.

Benchmarks can provide context, not a target to copy. SaaS Capital's 2026 survey of bootstrapped private B2B SaaS companies reported medians of 15% growth, 103% NRR and 91% GRR. Customer size, pricing, market, funding and contract length all affect what a healthy result looks like.

Retention becomes more useful when connected to customer behaviour. A company can compare retained and churned accounts by:

• completion of the core workflow;
• time from sign-up to the first useful result;
• number of active accounts, not only active users;
• breadth and depth of feature use;
• support demand and unresolved issues;
• contract size, plan and customer segment.

Login frequency may matter for a daily work tool and mean almost nothing for software used once a quarter. Activation therefore needs a product-specific definition. It should describe the moment a customer has received the first piece of value they bought the product for.

05

Acquisition needs a payback view

Customer acquisition cost, or CAC, adds the sales and marketing cost needed to win new customers, then divides it by the number acquired during the same meaningful period.

The calculation sounds simple. The boundaries are not.

Should the number include salaries, commission, agencies, software, events and the founder's sales time? Which customers belong to the spending period when a B2B sale takes several months? How should referrals or partner channels be treated?

The dashboard needs one agreed method and a clear note when the method changes.

CAC becomes more useful when paired with gross margin and payback time. A customer may add attractive MRR while implementation, support and infrastructure consume much of it. Gross-margin-adjusted CAC payback asks how long the margin from that customer takes to recover the acquisition cost.

Lifetime value can help longer-term planning, but it is an estimate built from assumptions about revenue, margin and retention. For a young product with few completed customer lifetimes, a precise-looking LTV figure can be surprisingly imaginative.

Use it carefully. Compare the forecast with real cohorts as the evidence grows. In the meantime, conversion rate, average contract value, gross margin and CAC payback often give a clearer operating view.

Most importantly, segment the measures. One average CAC can blend an efficient partner channel with an expensive paid campaign. One average contract value can blend self-service customers with enterprise accounts that need months of implementation.

06

Product and operations belong beside the commercial numbers

A SaaS dashboard should not stop at billing and sales data.

The product must repeatedly deliver the service behind that revenue. That means the team needs to see activation, usage, reliability, support demand and the cost created by individual customers or tiers.

AWS's SaaS guidance recommends capturing tenant-aware metrics. A tenant is the customer organisation using the shared SaaS product. Adding tenant context lets the team understand which customers use particular features, create load, experience bottlenecks or generate an unusual cost profile.

That detail matters because global averages can hide local pain. A background job may succeed 99.5% of the time across the platform while failing repeatedly for one important tenant. Overall response time may look acceptable while a lower-priced tier is saturating an expensive service. Total support tickets may look manageable while new customers wait too long for onboarding help.

Useful product and operational measures might include:

• completion rate for the product's core workflow;
• activation and time to first value by segment;
• active accounts and meaningful feature use;
• failed jobs, integration errors and processing delays;
• critical journey success rate and response time;
• onboarding queue, age and completion time;
• support volume, response and resolution by account or tier;
• infrastructure and third-party cost by tenant where it can be measured fairly.

The dashboard does not need every application event. It needs the events that connect customer behaviour to revenue, cost, risk or service quality.

07

Build the dashboard in layers

Trying to fit every useful measure onto one screen creates a wall of small charts. A layered dashboard works better.

The first layer answers whether the business is broadly moving in the intended direction. The second explains which segment, cohort, plan or workflow caused the movement. The third leads to the records or operational view needed to act.

The owners do not need exclusive control of the data. They need responsibility for the question and a clear route to the people who can explain it.

Colour should show meaning, not excitement. A red number needs an agreed threshold. A green number should not imply success when the target or comparison is missing. Trends, prior periods and cohorts are usually more informative than a large isolated total.

08

The data model matters more than the chart type

An attractive dashboard cannot repair disputed definitions or disconnected customer records.

The company may have subscription data in billing, contracts in CRM, product events in analytics, support cases in a helpdesk and infrastructure data in monitoring tools. If each source uses a different customer identifier, combining them becomes guesswork.

Before choosing bar charts and gauges, agree:

• the customer and tenant identifiers shared between systems;
• the definition of an active, new, retained and churned customer;
• how plans, contracts, currencies, discounts and one-off charges are represented;
• which timestamp controls each measure;
• how corrections and late-arriving events change historical results;
• who owns each source and how freshness or failure becomes visible.

Refresh speed should follow the decision. A failed payment queue may need near-real-time attention. Support backlog may need an hourly or daily view. GRR and CAC payback are unlikely to become more useful because they update every few seconds.

Use the slowest rhythm that still supports the action. Real-time data costs more to move, reconcile and monitor. It can also encourage people to react to noise before a meaningful period has passed.

The dashboard should show when data is stale or incomplete. A confident number from a failed import is worse than an honest blank with a warning.

09

Use standard tools until the operation needs something more

Many SaaS businesses can begin with their billing platform, product analytics and a configurable business intelligence tool. That is usually faster and less expensive than building a reporting product from scratch.

A custom dashboard becomes easier to justify when the business needs to join a proprietary workflow across several systems, apply specific permissions, calculate measures that standard tools cannot express or let people act on the result inside the same interface.

Even then, the first job is not development. It is agreeing the questions, definitions, owners and drill-downs.

Return to the imagined SaaS meeting. The improved dashboard still shows MRR, but the team can now see the £8,000 net increase as a set of movements. It can compare 103% NRR with the lost revenue hidden underneath. It can connect onboarding delays with customer segments, support demand and time to value. It can identify the tenant creating unusual product load without waiting for a global incident.

That is what a SaaS dashboard should do. It should not try to prove that the company has plenty of data. It should make the next useful question easier to answer.

If your SaaS reporting is spread across billing, CRM, product analytics, support and infrastructure tools, I can help define the measures, connect the sources and shape a dashboard around the decisions the business actually needs to make.