Twenty dashboard cards, four leadership views, and no plan upgrade

Leadership wanted real visibility: pipeline health for sales, a revenue picture for the executive team, client load for the coaching side, and reach for marketing. The CRM offered exactly that — on the tier above the one already being paid for. We built four role-specific dashboards, 20 cards in total, inside the existing plan instead. Nothing was upgraded, and no separate reporting tool was bolted on.

Different people wanted different numbers, and none of them had a home for those numbers.

Sales wanted to see where deals sat and whether the pipeline was moving. The executive team wanted the top-line: what had actually closed, what was still open, how the contact base and meeting cadence looked. The coaching side of the business wanted operational load — who was being onboarded, how many active clients each coach carried. Marketing wanted its own reach and activity view.

The requests were reasonable, but they were arriving as ad-hoc questions answered by hand. Someone would open the CRM, filter a list, count rows, and paste the result into a message. That is slow, it is inconsistent between people, and it does not scale to four audiences who each want a standing view they can glance at.

The obvious place to put standing views is a dashboard. And the dashboards leadership had in mind — multiple, role-based, always current — were associated with a higher plan tier than the one in use.

Both fixes assumed the requested metrics were beyond what the current tier could compute. That assumption is the thing worth testing before spending anything. Most of what leadership asked for — counts, sums, groupings, rates — are exactly the aggregates a CRM already calculates to run its own list views and record rollups.

We inverted the usual order. Instead of designing the ideal dashboard and then finding a tool that could render it, we started from what the CRM's native reporting already produced and designed the dashboards to fit inside that.

Every requested metric was checked against a native aggregate. If the platform already computed it — or could compute it from a native grouping or rollup on the current tier — it became a card. Where a request would have needed a metric the native layer could not express, we reshaped the request toward the nearest thing it could. That scoping discipline is what kept the whole thing on the existing plan.

The result was four dashboards, each aimed at one audience, 20 cards total.

Sales dashboard — 5 cards. Deal stages, pipeline value, deals over time, win/loss rate, and average deal size. This is the pipeline-health view: where deals sit, what they are worth, whether they are moving, how often they close, and how big they are on average.

Executive dashboard — 5 cards. Closed revenue, open pipeline, contacts, meetings, and lifecycle stages. The top-line: money booked, money in flight, the size of the relationship base, activity, and how contacts are distributed across their lifecycle.

Coaching dashboard — 4 cards. Active clients, onboarding status, clients per coach, and revenue per coach. This is the operational-load view for the service side — who is active, who is mid-onboarding, and how clients and revenue split across coaches.

Marketing dashboard. Further cards for the marketing audience, built the same way — from native reporting the current tier already produced — to give that team its own standing view rather than borrowing someone else's.

Each card is fed by the CRM's native reporting, not by an external pipeline. The platform already aggregates its own records to run the product: it groups deals by stage, sums values across records, counts contacts, rolls activity up per owner. A dashboard card is a saved presentation of one of those aggregates, pointed at the slice a given audience cares about.

So "deal stages" is the platform's own grouping of deals by their stage field. "Pipeline value" is a sum over open deals. "Clients per coach" is a count grouped by the owner relationship. "Revenue per coach" is that same grouping applied to a revenue field. None of these required a new data model. They required choosing the right native aggregate and framing it for the right viewer.

Grouping the cards by role is what turns 20 aggregates into four useful tools. The same underlying numbers, cut and captioned for one audience, become a view that person can read at a glance without wading past someone else's metrics. Sales does not scroll through coaching load; the executive team does not hunt for its revenue line inside a pipeline board.

The constraint did real work. Because every card had to map to something native, requests that sounded simple in a meeting got tested against what the platform could actually compute — and a few had to be reshaped toward the nearest native aggregate rather than built as imagined. That is a feature of the approach, not a failure of it: the scoping is exactly what held cost flat.

The genuine surprise was how little was missing. Going in, the working assumption was that "proper" role-based dashboards would need the upgrade. In practice the native reporting layer already computed the large majority of what four separate audiences asked for. The gap between "what leadership wanted to see" and "what the current tier already calculates" was much smaller than the upgrade path implied.

Four leadership dashboards now exist on the existing CRM plan — sales, executive, coaching, and marketing — carrying 20 cards between them, with no tier upgrade and no separate BI tool. Each audience has a standing, role-specific view instead of hand-counted answers pasted on request. The measurement here is direct: the dashboards were built and delivered on the current tier, so the recurring cost of both the plan upgrade and a parallel reporting system was avoided outright.

• Match the report to what native tooling already computes before reaching for an upgrade. Counts, sums, groupings, and rates are usually already being calculated by the CRM to run itself.
• Scope the request to the tool, not the tool to the request. Starting from native aggregates and designing dashboards to fit them is what kept everything on the current plan.
• A tier upgrade and a BI tool are answers to real problems — just not this one. Reach for them when you need blended sources, custom metrics, or history the CRM cannot express; not for counts it already produces.
• Group by audience to turn raw aggregates into tools. The same numbers, cut and captioned per role, become four views people actually read instead of one board nobody owns.
• Test the "we need the upgrade" assumption before you buy it. The gap between what leadership wants to see and what the current tier already computes is often smaller than it looks.