Sales Dashboard Examples Reps and Managers Both Use
Watch what happens when a sales dashboard gets opened in a Monday pipeline meeting. The manager scrolls to stage conversion and coverage. The rep sits there waiting, because none of it tells them which of their forty open deals to call today. Then the meeting ends, the manager keeps using the dashboard, and the rep never opens it again. That is the single most common failure mode in this category, and it is not a design failure. It is a failure to admit that a sales rep dashboard and a manager dashboard answer different questions and therefore cannot be the same screen.
The sales dashboard examples below split cleanly along that line. First a rep facing view, built around one person's book of business and what they should do in the next two hours. Then a manager facing view, built around coverage, stage conversion, and forecast risk across a team. Each one gets a layout, a metric definition for every tile, and the CRM fields it depends on, because a tile whose underlying field is never filled in is decoration.
Why one sales dashboard cannot serve both audiences
The reason the merged dashboard keeps getting built is that it looks efficient. One artifact, one refresh schedule, one place to maintain. The reason it fails is that the two audiences differ on every dimension that determines layout.
Scope. A rep cares about roughly thirty to eighty records they personally own. A manager cares about the aggregate of five to fifteen reps and almost never about an individual record until it is large enough to matter for the number.
Time horizon. A rep works in hours and days. Who is going cold, who did not reply, what is due today. A manager works in weeks and quarters. Whether the quarter lands, and which stage is leaking.
Unit of analysis. The rep's atom is the deal. The manager's atom is the stage transition and the cohort.
Action on the other side. A rep's dashboard should terminate in a click that opens a record or drafts an email. A manager's dashboard should terminate in a conversation with a specific rep about a specific pattern.
Tolerance for aggregation. A manager is happy with medians and rates. A rep is actively harmed by them, because the median deal in their pipeline is not a deal they can call.
When you merge these, you get the worst of both. The rep gets a chart of team win rate they cannot influence today, and the manager gets a scrollable table of one rep's activities they do not have time to read. Build two. They share a data model and most of the underlying fields, so the marginal cost of the second one is small. The general discipline of writing down a formula, a source system, a timestamp, and an owner for every tile is covered in depth in KPI Dashboard Examples for Sales, Finance, and Ops, and everything below assumes you are doing that.
| Dimension | Rep facing dashboard | Manager facing dashboard |
|---|---|---|
| Scope | One owner's records | Team aggregate, drill to rep |
| Primary object | Opportunity, contact, task | Stage transition, cohort, forecast category |
| Refresh expectation | Near real time, at least hourly | Daily is fine, weekly for cohorts |
| Default filter | Owner equals me, open deals | All reps, current quarter |
| Success test | Rep opens it unprompted before calls | Manager can name the leaking stage without asking |
| Worst failure | Shows rates instead of records | Shows a record list instead of a pattern |
Sales rep dashboard example: the daily working view
The purpose of a salesperson dashboard is to answer one question in under ten seconds: what do I touch next. Everything else is secondary. If a rep has to filter, sort, or think before acting, they will go back to whatever list view or notebook they were using instead.
Layout that works, in a single column so it survives on a phone between meetings.
Row one, three numbers, no charts. Quota attainment this period as a percentage with the absolute gap next to it, closed this period, and open pipeline with a close date inside the period. Three numbers. That is the entire status section. Reps do not need a gauge chart to know whether they are behind.
Row two, the action queue. This is the heart of the salesman dashboard and the part that most templates get wrong by omitting it. It is a ranked list of records, not a chart. Each row shows the account name, the deal value, the stage, days since last logged activity, and the next step text pulled straight from the CRM. Sort by a simple priority score, not by value alone.
Row three, at risk deals. Open opportunities where the close date is in the past or inside seven days and the stage is below the second to last stage. These are the deals that will silently slip and turn a good forecast into a bad one.
Row four, this week's calendar and follow up debt. Meetings booked, and count of records where the rep committed to a follow up date that has passed.
Here is the tile definition table. Notice how many of these depend on activity logging, which sets the ceiling on the whole view.
| Tile | Definition | CRM fields it depends on | How it goes wrong |
|---|---|---|---|
| Attainment | Closed won amount in period divided by rep quota, shown with absolute gap | Opportunity amount, stage, close date, rep quota record | Quota stored in a spreadsheet instead of the CRM, so the tile silently uses last quarter's number |
| Open pipeline in period | Sum of amount for open opportunities with close date inside the period | Amount, close date, stage, owner | Close dates that reps push a week at a time forever |
| Action queue | Ranked open deals by priority score, see formula below | Last activity date, next step, next step date, amount, stage | Next step field is free text and half empty, so the most useful column is blank |
| Days since last touch | Today minus max date across logged calls, emails, meetings, notes | Activity object with a reliable timestamp | Email sync off for some reps, making them look inactive |
| At risk deals | Open, close date in the past or within seven days, stage below commit | Close date, stage, forecast category | Nobody defines which stage counts as commit, so the list is either everything or nothing |
| Follow up debt | Count of records with next step date in the past | Next step date | Field is optional in page layout, so adoption is uneven |
| Meetings this week | Count of calendar events linked to an open opportunity | Calendar integration, event to opportunity relation | Internal meetings counted as customer meetings |
A workable priority score, which you can compute as a formula field or in the dashboard layer: rank by days since last activity, then break ties by amount, then push down anything with a next step date in the future. In plain terms, a large deal nobody has touched in twelve days outranks a small deal touched yesterday, and a deal with a scheduled next step tomorrow drops off the queue because the rep already has a plan for it.
Three things to deliberately leave off a sales rep dashboard. Team leaderboards, unless your culture genuinely runs on them, because for the bottom half of the team they are demotivating noise. Win rate, because a single rep's win rate over a quarter is a small sample and the rep cannot act on it today. Any chart of historical trend longer than the current period, because it belongs in a coaching conversation, not the daily view.
Sales manager dashboard example: coverage, conversion, forecast risk
The manager view has a different job: explain whether the number lands, and if not, which stage or which rep is causing it. Three sections, in this order.
Section one, does the quarter land. Closed to date, weighted forecast, committed forecast, and quota. Show the gap explicitly. Then pipeline coverage, defined as open pipeline with a close date in the quarter divided by remaining quota. Coverage is the single most abused metric in sales dashboard software, because it is trivially inflated by reps dragging close dates forward. Always pair it with a stale close date count so the inflation is visible on the same screen.
Section two, where is the funnel leaking. Stage conversion by creation cohort, not by close date. This distinction matters more than any visual choice on the page. If you cohort by close date, deals that never closed are invisible, and your conversion looks better than reality. If you cohort by creation date, you see every deal that entered, including the ones that quietly rotted. Creation cohorts lag, which is the price of honesty. Show both if you must, labelled clearly.
Section three, risk. Aging by stage, deals with no activity in fourteen days weighted by value, single threaded deals where only one contact has been engaged, and forecast movement since last week. The last one is the highest signal item on the entire dashboard and the most commonly missing: a diff of what changed since the last snapshot. Deals added to commit, deals removed from commit, deals whose close date moved out.
| Tile | Definition | CRM fields it depends on | Failure mode |
|---|---|---|---|
| Pipeline coverage | Open pipeline with close date in quarter divided by remaining quota | Amount, close date, stage, team quota | Inflated by close date dragging. Pair with stale date count |
| Stage conversion | Count entering stage N plus one divided by count entering stage N, by creation cohort | Stage history or opportunity history table | Not all CRMs keep stage history by default, and it cannot be backfilled |
| Weighted forecast | Sum of amount times stage probability for open deals in quarter | Amount, stage probability, close date | Default probabilities nobody has recalibrated in three years |
| Committed forecast | Sum of amount where forecast category equals Commit | Forecast category | Reps and managers commit different sets. Show both roll ups |
| Forecast movement | Diff of committed set versus the same set seven days ago | Requires a weekly snapshot table | No history table means no diff. This must be designed in from day one |
| Deal aging | Median days in current stage, by stage | Stage entry timestamp | Median hides the tail. Add a count over ninety days |
| No activity value | Sum of amount for open deals with no logged activity in fourteen days | Last activity date, amount | Activity logging gaps make healthy deals look dead |
| Single threaded deals | Open deals with one engaged contact above a value threshold | Contact roles, engagement or activity per contact | Contact roles are the least maintained object in most CRMs |
| Win rate | Closed won divided by closed won plus closed lost, by creation cohort | Stage, close date, created date | Stalled deals never marked lost sit open forever and inflate this |
The dependency worth internalizing: five of those nine tiles need history, not just current state. Stage entry timestamps, a weekly forecast snapshot, and last activity dates. Current state alone gives you a photograph when the manager needs a film. If you are building on Salesforce, the specifics of what is retained, what needs a custom object, and where the platform's own reporting limits bite are covered in Salesforce Dashboards: Setup, Limits, and Better Answers.
On chart choice, be boring. Bars for stage funnels, lines for trend against a target line, tables for anything a manager will read row by row. No donuts, no gauges, no dual axes. The reasoning behind that restraint, with examples of visuals that actually changed a decision versus ones that just filled space, is in Data Visualization Examples That Change a Decision.
The CRM fields both sales dashboards depend on
Every sales dashboard example in this article is downstream of about a dozen fields. If those fields are not maintained, no tool fixes it. This is the audit to run before you build anything.
| Field | Used by | Owner discipline required |
|---|---|---|
| Amount | Both | Standardized currency and a rule for multi year contracts |
| Close date | Both | Locked after quarter end, changes logged |
| Stage | Both | Exit criteria written down per stage, not vibes |
| Stage entry timestamp | Manager | Enabled in history tracking from day one |
| Forecast category | Manager | Defined mapping from stage, with rep override allowed |
| Owner | Both | Reassignment on rep departure, or metrics break |
| Last activity date | Both | Email and calendar sync on for every rep |
| Next step and next step date | Rep | Required on page layout past stage two |
| Contact roles | Manager | At least two roles on any deal above threshold |
| Lead source | Manager, marketing | Single source of truth, no free text |
| Quota | Both | Stored as a record in the CRM, not a spreadsheet |
| Loss reason | Manager | Picklist, required on close lost |
Two of those deserve extra attention. Stage exit criteria, because without written criteria stage conversion measures rep optimism rather than deal progress. And loss reason as a required picklist, because it is the cheapest source of pattern in the whole system and almost every team leaves it optional and therefore empty.
If your pipeline data lives across several systems, a CRM plus a billing tool plus a product usage database, the integration work is its own project with its own failure modes. Integrating APIs: A Practical Guide for Business Teams walks through the parts that surprise non engineers, including rate limits, incremental syncs, and what happens when a field is renamed upstream.
How to choose sales dashboard software without overbuying
Commercially, the choice comes down to where your data already sits and how much modelling you need on top of it. Here is the honest comparison.
| Option | Best when | Real cost driver | Where it falls down |
|---|---|---|---|
| Native CRM reports and dashboards | All the data is already in the CRM and definitions are simple | Usually bundled, sometimes an analytics add on | Cross system joins, retained history, and complex cohort logic |
| General BI platform | You need to blend CRM with billing, product, and finance data | Per user licences plus capacity plus the data engineering to feed it | Total cost is rarely the sticker price. See the breakdown in the Power BI piece below |
| Revenue specific analytics tools | You want forecast intelligence and conversion analysis out of the box | Per seat, often priced near the CRM itself | Opinionated data model that may not match your stages |
| Spreadsheet exports | Fewer than ten reps, one system, low complexity | Someone's Friday afternoon, every week | Breaks the moment two people edit it, no history |
| Warehouse plus BI layer | Multiple systems, real analytics team, long horizon | Warehouse compute, transformation tooling, and headcount | Overkill for a ten person sales team |
Three selection criteria that predict satisfaction better than feature lists.
Does it retain history you are not already keeping? If your CRM does not snapshot the forecast weekly, whichever tool you pick needs to, or the highest value manager tile is impossible.
Can a non engineer change a definition? Stage definitions change. If every change is a ticket, definitions rot.
What is the real total cost at your seat count? Per user pricing on a BI platform looks cheap until you add capacity, gateways, and the person who maintains models. Power BI Cost in 2026: Licenses, Capacity, and Extras itemizes the parts that do not appear on the pricing page, and the same arithmetic applies to most enterprise tools, including per seat knowledge products like the ones priced out in Glean Pricing: What Enterprise Search Costs Per Seat.
One more note on the AI assisted options currently marketed as instant dashboard builders. Some genuinely help with exploratory analysis on a clean single table. Most struggle the moment your question requires a join across objects with business specific rules. The realistic boundary is mapped in Free AI Data Analysis Tools: Where They Help and Stop.
Where Skopx fits, and where it does not
Direct statement first, because this article is about dashboards and the honest answer matters more than the pitch. Skopx is not a CRM, not a BI tool, and not a dashboard builder. It will not draw the two layouts above. If you need pixel level control over a sales dashboard, use your CRM's native reporting or a BI platform, and build the tables in this article.
What Skopx does is the layer next to the dashboard. It is an AI workspace that connects nearly 1,000 tools a company already uses, including HubSpot, Gmail, Slack, Stripe, and Google Analytics, and it does three things that dashboards are structurally bad at.
It answers the question the dashboard raised. A manager sees stage two to three conversion drop and wants to know which deals stalled and what the last email said. That is not a dashboard interaction, it is a question. In chat you ask it in plain language and get an answer with citations back to the CRM records and the email threads it read, so you can check the source rather than trusting a number.
It surfaces risk without anyone opening a tab. The insights engine watches connected systems and flags anomalies, including deals going quiet: no logged activity, no inbound reply, a close date inside the period. That reaches a rep as a notification or a morning brief rather than as a chart nobody scrolled to.
It turns the recurring check into an automation. Workflows are built by describing them in chat, no builder canvas required.
Quiet deal alert
Weekday 07:30
Runs before the first calls
Read open pipeline
Open opportunities with a close date in the current quarter
Filter quiet deals
No logged activity in 14 days, value above threshold
Pull last thread
Most recent email and meeting note per deal
Message the owner
Ranked list with the suggested next step
Post team summary
Aggregate value at risk to the sales channel
Boundaries, stated plainly. Skopx does not replace pipeline reporting, it does not model or warehouse your data, and it does not write records back into a system of record unless you explicitly configure a workflow to do so. Answer quality is bounded by field hygiene exactly like a dashboard is: if last activity date is not populated, nothing downstream can tell a quiet deal from a busy one.
On cost, Solo is $5 per month and Team is $16 per seat per month, listed on the pricing page. AI usage runs on your own key for any major model with zero markup, so model spend goes to the provider directly rather than through a resale margin.
If your next question is about the other half of the funnel, the same rep versus manager split applies to demand generation, and Marketing Dashboards That Answer the Spend Question covers the attribution traps that make marketing sourced pipeline the most argued about number in any sales dashboard.
A four week rollout that survives contact with the team
Building both views is a week of work. Getting them used is the rest of the month.
Week one, audit fields. Run the dependency table above against your CRM. Count population rates for last activity date, next step, contact roles, and loss reason. Fix the page layouts and the sync settings before building anything. Every hour here saves three later.
Week two, build the manager view. Start here, not with the rep view, because the manager will define the stages and the forecast categories, and the rep view inherits those definitions. Ship it with a written definition for every tile.
Week three, build the rep view with two reps in the room. Not a survey, not a requirements doc. Sit with a strong rep and a struggling rep, watch them work, and cut every tile they do not look at. The action queue ordering will be wrong on the first try and they will tell you exactly how.
Week four, wire the notifications and delete something. The dashboard nobody opens is worth less than the alert that arrives where people already are. Then remove at least two tiles from each view. A dashboard that only gets added to eventually becomes a wall of numbers, and the wall is where attention goes to die.
One durable habit after rollout: every time someone asks a question the dashboard cannot answer, write the question down. After a month, that list tells you what to build next, and it usually reveals that half the questions were never dashboard questions at all. They were one off investigations that needed a join across the CRM, the inbox, and the billing system, which is exactly the kind of thing worth answering in a conversation rather than by adding a twelfth tile.
Frequently asked questions
How many tiles should a sales dashboard have?
Seven or fewer for a rep, twelve or fewer for a manager. The constraint is not screen space, it is attention. Every tile you add lowers the probability that any single tile gets read. A practical test: ask someone to name what changed since last week after ten seconds of looking. If they cannot, the dashboard is too dense regardless of how correct each number is.
Should reps see each other's numbers on the sales dashboard?
Show team closed and team attainment, and make individual detail available on request rather than by default. Full leaderboards work in high volume transactional teams with short cycles and public culture, and they demoralize complex enterprise teams where one deal per quarter is normal. If you do run a leaderboard, rank on something within a rep's control, like meetings booked or pipeline created, not just closed revenue, which is partly a function of territory.
Why does pipeline coverage look healthy while the forecast keeps missing?
Almost always stale close dates. Coverage counts every open deal with a close date inside the period, and a deal pushed forward one week at a time stays in that count indefinitely while never closing. Add two tiles next to coverage: count of deals whose close date has been changed more than twice, and the value of deals with no activity in fourteen days. When those two are large, treat coverage as fiction.
What is the difference between a rep dashboard and a sales activity report?
A rep dashboard is prospective and ordered by what to do next. An activity report is retrospective and ordered by what was done. Both are useful, but do not put the activity report on the rep's daily view, because it is a management artifact. If a rep needs to see their own activity counts, it belongs in a weekly one to one, not in the screen they open before dialling.
Do we need BI software, or is native CRM reporting enough?
If every number you need lives in the CRM, your stage history is tracked, and your definitions are simple, native reporting is enough and you should stop there. You need BI when you must blend CRM data with billing, product usage, or finance data, or when you need retained snapshots the CRM does not keep. Buying a BI platform to build a report your CRM already supports adds licence cost and a maintenance burden without adding an answer.
Can an AI tool build these sales dashboards for us?
Not really, and be suspicious of anything that claims it can from a cold start. AI assistants are genuinely useful for drafting the query behind a tile, explaining a movement in a number, and pulling context from records and email threads once the definitions exist. The hard part of a sales dashboard was never the SQL or the chart. It is agreeing on what a stage means, keeping fields populated, and deciding what to leave out. That is human work, and the tooling is downstream of it.
Skopx Team
The Skopx engineering and product team