Build it with AI

Turn pipeline data into a sales dashboard built for the questions your team asks.

Create a dashboard for pipeline value, stage movement, rep activity, forecast, and at-risk deals.

Introduction

What a sales dashboard has to hold.

Most teams end up with a sales dashboard the same way: a weekly export into a spreadsheet, pivoted by hand, pasted into a deck. It works while one person can hold the whole pipeline in their head and check the pivot against intuition. It stops the week that person is on holiday and the deck goes out with an error nobody catches.

By the time the deck is assembled the numbers describe last week, and any question outside the pivot needs the whole exercise repeated. There is no definition of which numbers are authoritative, no lineage from a figure back to the records that produced it, and no way to ask a question the pivot was not built to answer without rebuilding the pivot.

What follows covers building a sales dashboard: the records it holds (pipeline value by stage, movement between stages, rep activity, forecast, and deals flagged at risk), the systems it reads (Salesforce and HubSpot), and what it does not fix.

The problem

A weekly deck that describes last week.

BI tools solve the charting problem and leave the modelling problem, which is why the dashboard project stalls at the point where somebody has to decide what counts as a qualified opportunity. Spreadsheet exports solve nothing but are honest about it, so teams keep returning to them.

The records are pipeline value by stage, movement between stages, rep activity, forecast, and deals flagged at risk, and the authoritative copy of most of them already lives in Salesforce or HubSpot. The number in the deck and the number in the CRM diverge quietly between refreshes, and the first person to notice is usually a board member asking why two slides disagree.

The cost is not the inconvenience: the team manages to a number that was accurate on Monday.

You're likely here because

  • Any question outside the existing pivot means asking someone to rebuild it
  • By the time the deck is assembled the numbers describe last week, and any question outside the pivot needs the whole exercise repeated.
  • When it is wrong, the team manages to a number that was accurate on Monday

What gets built

Launch builds it, Grow operates it.

Built in Launch

  • KPI cards
  • Pipeline funnel
  • Rep scorecards

Operated through Grow

  • Opportunity context
  • Follow-up actions
  • Meeting activity

Systems it reads

  • Salesforce
  • HubSpot
  • Google Sheets

The record model

What the dashboard has to read.

Opportunity amount and its currency
With the conversion date recorded, not applied live. A multi-currency pipeline restated at today’s rate makes last quarter move every time somebody opens the page.
Stage and the date it was entered
Dwell time is derived from this and cannot be reconstructed later. A CRM that overwrites stage history has thrown away the most diagnostic field on the board.
Close date, current and original
Slippage is the difference between them. Keeping only the current value hides the pattern that predicts the quarter better than any confidence rating.
Owner and team
For scoping views by role. A rep scorecard visible to the whole company is a different product from a rep scorecard visible to their manager, and the difference is not a setting.
Last genuine contact
Derived from email and calendar rather than from logged activity, so silence is measured rather than self-reported.
Forecast category
Held separately from stage, because a deal can be at Proposal and not committed. Conflating them is why forecasts move without any deal changing.
Source system and read time
Shown on the view. A number without its age invites an argument that neither side can settle.

How it runs

From export-and-pivot to a live operating view.

01Describe what a sales dashboard has todo02Connect the systems of record03Build the operating surface04Start narrow05Route the exceptions06Measure time from question asked toanswer available, and how often the…

Step 01

Describe what a sales dashboard has to do

Start from the five questions the sales meeting actually opens with. A dashboard built from those is used; a dashboard built from every available metric is admired once and then ignored.

Step 02

Connect the systems of record

The CRM supplies stage, amount, and close date; email and calendar supply the activity that explains movement. Reading them live is what makes the difference between a dashboard and a screenshot.

Step 03

Build the operating surface

KPI cards, a stage funnel with movement over the period, rep scorecards, and drill-through from any figure to the underlying opportunities — so a number can always be challenged by opening it.

Step 04

Start narrow

One stage-movement view answering what changed since the last review and who owns it. Ship that alone and see whether the meeting changes shape before building the rest.

Step 05

Route the exceptions

Deals that slip a close date more than once, or sit in a stage past its normal dwell time, surface to the manager with the history attached rather than waiting for the forecast call.

Step 06

Measure time from question asked to answer available, and how often the answer needs a rebuild

Measure how long it takes to answer a question the dashboard was not designed for. That number, not the number of charts, is what separates an operating view from a report.

Implementation path

Building a dashboard people actually open.

  1. 01

    Write down the questions the sales meeting opens with, in the words people use. Build for those five and resist the twenty that get suggested once a dashboard exists.

  2. 02

    Baseline the analyst hours: how long the weekly pack takes to assemble, and how often a number in it is corrected after the fact.

  3. 03

    Agree which system is authoritative for amount and close date before building anything on top of them. Almost every dashboard disagreement traces back to this being unstated.

  4. 04

    Run the new view beside the existing pack for one reporting cycle and reconcile the headline numbers. Retire the pack only when they agree twice in a row.

  5. 05

    Build the narrowest useful version first: a single stage-movement view answering what changed since the last review and who owns it.

  6. 06

    The five questions the sales meeting opens with take an afternoon to agree and are most of the specification. Connecting the CRM read-first is quick; reconciling the headline numbers against the existing pack is the part that takes real time and is the part that must not be skipped. Budget one reporting cycle running both, and expect at least one definitional dispute to surface that the manual pack had been averaging away.

  7. 07

    After the stage-movement view is in weekly use, add cohorted conversion by entry period — it distinguishes a conversion problem from a mix change, which is the distinction most sales reporting cannot make. Rep scorecards come later and only with the visibility question settled first.

Controls

Controls that matter.

01

Control 01

Every figure drills through to the opportunity records behind it, so a challenged number can be resolved in the meeting rather than after it

02

Control 02

Rep-level and team-level views scoped by role, so a scorecard is not accidentally a public leaderboard

03

Control 03

The refresh time and source system shown on the view itself, so nobody argues from a figure without knowing how old it is

Examples

Three questions that stop needing an analyst.

The question that arrives mid-meeting

Someone asks what the number looks like excluding one large deal. Drill-through and a filter answer it while the meeting is still happening, instead of generating an action item that arrives three days later.

The forecast that moved without explanation

Stage movement over the period is a first-class view rather than a derived one, so the change between two forecasts is attributable to specific deals rather than being asserted.

The Monday morning pack

The assembly step disappears entirely. What remains is the judgement about what the numbers mean, which was always the part worth an analyst’s time.

How it goes wrong

Three ways a sales dashboard fails.

The dashboard ships with forty charts and is opened enthusiastically for two weeks, then not at all.

Build the five questions the meeting actually asks, and refuse the rest until those are being used weekly. A dashboard is judged by whether it changes a conversation, and forty charts distribute attention evenly across things of very unequal importance.

A number is challenged in the meeting and cannot be defended, so the old spreadsheet comes back out.

Drill-through on every figure, from the first version. A number you can open is a number that survives being questioned; one you cannot is one that gets replaced by a number somebody can explain.

Real-time refresh is added and the team starts reacting to daily movement in a metric that only means anything monthly.

Match refresh to the decision cycle and show the read time. Same-day is enough for a sales operating view, and anything faster mostly manufactures anxiety about normal variation.

Limitations and considerations

What a dashboard will not tell you.

  • A dashboard inherits the quality of the pipeline hygiene beneath it. If half the opportunities carry a close date set at creation and never revisited, a live view makes that visible faster but does not fix it.
  • Cross-system attribution — which marketing touch produced which closed deal — depends on identity resolution between systems that were never designed to agree. Treat those figures as directional unless you have verified the join.
  • Real-time numbers change what people argue about, not whether they argue. Expect the first month to surface definitional disputes that the weekly pack was quietly averaging away.
  • If the CRM’s own report builder answers the five questions, use it. The case for building starts where the answer needs data the CRM does not hold — spend, product usage, support load — and the CRM report has become one input to a spreadsheet rather than the destination. Building before that point produces a second place to maintain the same definitions.
  • Connector coverage varies: Salesforce, HubSpot, Google Sheets are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.

FAQ

Build a sales dashboard with AI: common questions.

Why not use the reporting built into our CRM?

Use it if the questions your meeting asks map cleanly onto its report builder. The case for building starts when the answer needs data the CRM does not hold — spend, product usage, support load — and the CRM report becomes one input to a spreadsheet rather than the destination.

How live does live need to be?

For a sales operating view, same-day is almost always enough and anything faster mostly buys anxiety. What matters more is that the refresh time is visible, so nobody argues from a stale figure believing it is current.

Who maintains it when the process changes?

Changing a stage definition or adding a segment is a change to the description rather than a ticket into a BI backlog, which is the practical difference. It does still need an owner — a dashboard nobody owns drifts out of agreement with the process within a quarter.

What if two systems give different numbers?

That is the most useful thing a dashboard finds in its first month. Resolve it by naming one system authoritative for each field rather than by averaging, and keep the drill-through so the next disagreement is a two-minute check.

What should the first version contain?

A single stage-movement view answering what changed since the last review and who owns it. Everything else waits until that one is genuinely used.

How will we know whether it worked?

Measure time from question asked to answer available, and how often the answer needs a rebuild against the baseline taken before anything changed.

Start with ARIA

Ask ARIA to build it.

Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.

  • ARIA acts only through the systems and permissions you connect.
  • Connections use scoped credentials you can change or revoke.
  • Actions are recorded, and consequential ones can require approval.

Goes to UbiGrowth, with the page you asked from attached. We do not sell or share it. Prefer to talk? Call 972-823-1294.

Start here

Build a sales dashboard around the process you actually run.

Build for the five questions the sales meeting opens with, and add the rest only once those are answered live.