63 Dashboards, 9 Decisions: The Audit That Kills the Rest

Sixty-three dashboards, and the forecast ran off a spreadsheet somebody rebuilt by hand every Monday. I pulled the view logs on that Salesforce org and eleven dashboards had been opened in the last 30 days. Four had been opened by more than one person. We had spent months building visibility that changed no decision, and the one number the CRO forecasts on lived in a side artifact outside the system entirely. That is the normal state of GTM reporting, and it is not a build problem. It is a decision problem wearing a build problem’s clothes.

For years the reporting playbook had one move: someone asks a question, you build a permanent view to answer it, the question stops mattering, and the view lives forever because deleting things feels risky. Multiply that by every VP who ever asked “can I see X by region” and you get 63 tiles nobody trusts. The fix is not another dashboard. It is an audit built on a single rule: a dashboard exists to change a decision, and if you cannot name the decision, the dashboard dies. Watch the whole pile collapse to what gets decided on.

6363 dashboardsEvery ad-hoc request became a permanent tile. Nobody can name what half of them decide.

←

→

A dashboard is a decision-support tool or it is noise

Every dashboard should be able to finish this sentence: “We look at this to decide ______, and when the number crosses ______ we do ______.” If it cannot, it is not a dashboard. It is decoration that costs trust. When someone opens a screen of twelve charts and none of them tells them what to do differently, they learn to distrust the screen, and that distrust spreads to the charts that would have told them something. A CRO forecasts on four or five numbers. Everything past that is scenery the CRO scrolls past on the way to the spreadsheet.

The reflex that builds too many dashboards is the same one that builds too many required fields. Someone asks a question once, you build a permanent view to answer it, the question stops mattering, and the view lives forever because deleting feels risky. I wrote about the sibling version of this on the engineering side in stop building dashboards nobody opens. This piece is the audit method that clears the graveyard, and its unit of measure is the decision, not the tile.

Map decisions before you touch a single report

There are only so many recurring decisions a GTM org makes, and each one has an owner and a rhythm. Write them down first, because the map, not the dashboard list, is the thing you are building. This is the artifact the whole audit runs against.

Recurring decision	Owner	Cadence	The number that triggers action
Where to add or cut pipeline generation	CRO / VP Sales	Weekly	Weighted coverage below required by segment
Which deals to inspect this week	Frontline manager	Weekly	Deals slipped or stalled 21+ days
Whether to press or fix the acquisition motion	CRO / Finance	Monthly	Magic number, CAC payback trend
Which accounts are at churn risk	CS lead	Weekly	Health-score drop, no touch 30+ days
Whether the quarter’s forecast is defensible	CRO / Finance	Weekly	Commit vs weighted vs closed gap

Five decisions. A healthy org needs roughly one dashboard per row, plus one or two self-serve exploration surfaces. Everything beyond that is a duplicate, a decoration, or a report masquerading as a dashboard. Salesforce dashboards run 87% higher win rates when RevOps owns the definitions behind them (Ebsta and Pavilion, 2024 RevOps benchmarks), and the audit is how you earn that ownership: one decision, one owner, one triggering number per surviving screen.

The decision-owner-per-tile audit

This is the framework. Five steps, run in order, cheapest first, so the evidence gates kill the most before you ever spend judgment. Each step either removes tiles for free or forces a survivor to justify itself against the decision map above.

1. 1

   Pull the 90-day view log for every dashboard

   Opinions about which dashboards matter are worthless next to the run logs. Salesforce records every dashboard and report run, so sort ascending by run count. This one query does more culling than any meeting.

2. 2

   Kill zero-view tiles on evidence alone

   Anything nobody opened in 90 days is a free deletion, no debate required. On this org that was 41 of 63 dashboards gone before a single judgment call. The log gives you cover and catches the tile that is quietly load-bearing for someone you never talk to.

3. 3

   Demote single-viewer tiles to personal reports

   A dashboard one person opens forty times is a personal crutch, not a team decision surface. Move it to that person's home page as a saved report. Shared dashboards carry a maintenance tax; personal reports do not.

4. 4

   Make each survivor name its decision, owner, threshold, and action

   For every tile still standing, fill the four blanks: the decision, who owns it, the number that fires it, the action that follows. If any blank stays empty, the dashboard dies or merges into one that serves a real decision on the map.

5. 5

   Rebuild the survivor around that one decision, then set an expiry

   Trigger number top-left where the eye lands, supporting detail below in the order you would investigate. Tag each with a review date and a viewer floor. At review, re-run the log. This is what stops the pile from regrowing to 63.

Steps one and two are the whole reason the audit is cheap. By the time a human has to make a judgment call, the log has already removed two-thirds of the pile.

Run the usage query first

Start with evidence, because evidence has no feelings about your favorite chart. Pull actual dashboard runs over the last 90 days and sort ascending. The tiles at the top of that list, the ones with zero or one runs, are your kill list.

SELECT Dashboard.Title, Dashboard.DeveloperName,
       COUNT(Id) runs, COUNT_DISTINCT(CreatedById) distinct_viewers,
       MAX(CreatedDate) last_run
FROM DashboardMetadata
WHERE CreatedDate = LAST_N_DAYS:90
GROUP BY Dashboard.Title, Dashboard.DeveloperName
ORDER BY runs ASC

If your org does not surface dashboard runs directly, the underlying report runs live in the setup audit trail and in Lightning Usage data. The pattern is the same: sort ascending by run count and start deleting from the top. Pair run count with viewer spread, because a tile one person opens forty times is a personal crutch, not a team surface.

The kill funnel

The audit is a funnel. Each dashboard enters at the top and either survives to the next gate or dies. Most die at the first two gates, which is the point, because those gates cost you no judgment, only evidence.

View as table

Item	Value
All dashboards	63
Opened in 90 days	22
More than one viewer	14
Maps to a named decision	11
Decision has no better home	9

Nine dashboards survive out of 63, and those numbers reconcile straight back to the dissolve up top: 63 tiles, 22 ever opened, 9 that name a decision. That ratio measures what happens when you apply a decision test to a pile that grew by accretion, nothing more. The nine survivors are worth ten times what the 63 were worth, because a team that trusts nine dashboards acts on them, and a team facing 63 acts on a spreadsheet.

The four gates, cheapest first

Run the gates in sequence. The order matters because each gate is cheaper than the next, so you want the cheap gates to kill the most before you spend judgment on the rest.

Gate 1 and gate 2 come straight from the usage query. Gate 3 asks the decision sentence: name the decision, the owner, the threshold, and the action. If any of the four blanks stays empty, the dashboard dies or merges into one that serves a real decision. Gate 4 catches the dashboard that maps to a real decision but where a report, an alert, or a single number on a home page would serve that decision better than a full screen of tiles. A weekly “is anything stalled” check is an alert, not a dashboard you have to remember to open.

The worked example, tile by tile

Here is where the 63 went, mapped against the decision map. Every row is a bucket, and every bucket resolves to keep, demote, or kill.

Bucket	Count	Gate that caught it	Disposition
Zero views in 90 days	41	Gate 1 (log)	Killed
Opened, single viewer	8	Gate 2 (log)	Demoted to personal report
Shared, no nameable decision	3	Gate 3 (judgment)	Killed or merged
Maps to a decision, better as an alert or report	2	Gate 4 (judgment)	Converted to alert
Maps to a decision, needs a full screen	9	Survives	Rebuilt

Nine survivors, and they line up one-to-one against the five recurring decisions plus a handful of segment splits (coverage by segment counts as two screens, not one). The 41 that died had a combined zero human hours of value in the quarter and a nonzero maintenance cost every time a field changed underneath them. Killing them is pure margin.

The rebuild rule for the survivors

Killing dashboards is half the work. The nine that survive usually need a rebuild, because a dashboard that grew to serve five vague questions serves none of them well. The rebuild rule is one decision per dashboard, the triggering number top-left where the eye lands first, and the supporting detail below in the order you would investigate once the top number crosses its threshold. To keep the definitions honest, register each survivor as data, not as tribal knowledge:

# dashboard-registry.yml: one entry per surviving dashboard
- name: Coverage by Segment
  decision: Where to add or cut pipeline generation
  owner: vp-sales
  trigger_metric: weighted_coverage_vs_required
  threshold: "< 1.0x for any segment"
  action: Redirect SDR capacity to the short segment
  cadence: weekly
  review_date: 2026-10-01
  viewer_floor: 3

Every field maps to a blank in the decision sentence. When the review date arrives, re-run the usage query and check the registry: any dashboard under its viewer floor gets demoted, and any decision that changed owners gets its entry updated. The registry is what turns a one-time cleanup into a standing rule.

Before and after

The audit changes what a dashboard is for, not only how many exist. Here is the same reporting layer before and after the cut.

	The 63-dashboard org	The 9-dashboard org
What the forecast runs on	A hand-rebuilt spreadsheet nobody can audit	One coverage dashboard the team trusts
Opening a dashboard feels like	Twelve charts, no instruction	One decision, one trigger number, a drill path
When a VP asks for a new view	A permanent tile is born	Priced against the decision map, usually a report
Maintenance load	63 screens to keep from breaking	9 screens with owners and expiry dates
Trust in the numbers	Low, so people build side artifacts	High, so decisions happen in-system

The audit is a habit, not an event

You will not do this once and be done. Dashboards regrow the same way required fields and flows do, one reasonable request at a time. What separates an org with 9 trusted dashboards from one with 63 ignored ones is a standing rule: every dashboard names a decision in the registry, and a quarterly re-run of the usage query demotes anything nobody opens.

Run the usage query this week and sort ascending. Everything with zero views in 90 days is a free deletion. For the survivors, make each one finish the sentence “we look at this to decide ______,” register it, and rebuild it around that single decision. You will end up with fewer dashboards and more decisions made inside the system, which was the whole point of building any of them. One of those nine decisions is whether the quarter’s forecast is defensible, and the coverage number behind it lies more than any other. For that one, see why 3x coverage lies to you, and for the target the whole reporting layer aims reps at, see why reps sell blind for six weeks.