Your first sales dashboard should answer a few practical questions: what needs attention, who owns it, and which opportunities changed? Start with unassigned enquiries, overdue next actions, active opportunities and won work. Define every measure before choosing charts, so the team can trace a number back to its underlying records.
A dashboard is useful when it changes a decision. If a tile cannot tell somebody what to check or do next, leave it out of the first version. This approach keeps a small business from spending its reporting time maintaining numbers nobody uses.
Choose one reader and one meeting
For this fictional specification, the reader is a sales coordinator running a weekly work review. The dashboard supports assignment and follow-up decisions. It is not a financial report or a performance ranking of employees.
Microsoft's dashboard design guidance recommends designing around the audience and its decision-making needs. That principle applies before selecting a reporting platform: ask what this reader must notice, then choose the smallest useful set of measures.
Write a metric dictionary
| Measure | Definition and source | Owner and action |
|---|---|---|
| Unassigned enquiries | Open, validated intake records with no accepted owner; enquiry register | Coordinator assigns or investigates |
| Overdue next actions | Incomplete actions whose agreed due time has passed; task register | Task owner updates or completes |
| Active opportunities | Distinct scoped opportunities not marked won or lost; opportunity register | Sales lead reviews stalled records |
| Won work this period | Distinct opportunities meeting the team's recorded won criterion during the selected period | Sales lead checks supporting evidence |
For each measure, also document excluded records, timezone, reporting period and refresh owner. Test and duplicate records should have an explicit treatment. Do not rely on everyone remembering which rows to ignore.
Define “won” in language appropriate to your process, with the evidence required. Do not label a proposal as won because someone sounds enthusiastic. Equally, avoid presenting won opportunity counts as payments received. Those are different events and need different sources.
Work through the counting problem
Suppose a fictional register contains twelve submissions during the week. Two are test records and two are repeat submissions relating to already recorded enquiries. Eight submissions remain after those exclusions. This is a made-up arithmetic example, not a business result.
Of those eight, five relate to potential new work. Three are existing-customer service questions that go to a support queue. If your dashboard labels all eight as new sales opportunities, the label overstates what the records show.
Even the five sales enquiries should not automatically become five opportunities. A coordinator may still need to confirm the scope. Keep enquiry count, qualified opportunity count and won-work count separate, with a written rule for each transition.
This week's won work may originate from enquiries received months earlier. Dividing wins this week by enquiries this week would mix different groups. If you later report conversion, define a cohort and allow for unresolved records instead of presenting an attractive but misleading percentage.
Design the first screen around action
Place the attention queue first: unassigned records and overdue tasks. Below it, show opportunity stages with readable labels. Let the user reach the relevant records from each summary, subject to their access permissions.
Display the last successful data refresh time and the selected date range. An empty tile should distinguish “zero matching records” from “data unavailable.” Give unresolved source problems a visible note rather than quietly replacing missing values with zero.
Use a short list when the answer is “which records?” and a simple comparison when the answer is “which stage has more?” Decorative chart variety can wait. Test the screen at the size the coordinator actually uses, including a phone if that is part of the workflow.
Run a reconciliation before release
Choose a small fictional dataset and calculate each expected result manually. Compare it with the dashboard. Then change one owner, complete one task and close one opportunity, checking only the intended measures move.
Include a duplicate, a missing date and a delayed refresh in the test. Record who can correct each problem. For help turning this specification into a scoped build, discuss web portals and dashboards with Tralionex, bringing the definitions and sample records rather than just a visual reference.
Separate the work queue from the trend report
The coordinator's immediate question is usually which records need attention. A trend report answers a different question: how the pattern is changing across periods. Keep these purposes recognisable. A current overdue-task count should not be compared casually with a chart of tasks created last month, because the measures describe different groups of work.
For the fictional dashboard, use an attention list showing the owner, next action and due time. Put the historical view behind a clearly named route, such as “Enquiries received by week.” Explain whether each historical point represents records created during that week or the number open at its end. A snapshot and a flow measure can both be useful, provided their labels make the difference clear.
Specify filters before someone misreads a number
Write down how filters interact. If the coordinator selects one team, should the unassigned queue include all new enquiries or only those already routed to that team? There is no universal answer; choose the behaviour that supports the task and label any measure that deliberately follows a different scope.
Include the reporting timezone and define date boundaries. When an opportunity is closed near the end of a reporting period, its recorded timestamp determines which period includes it. Agree how a corrected closure date affects prior reports. Otherwise two people can generate different totals while believing they selected the same week.
Keep “not supplied,” “not applicable” and a genuine zero separate where they have different meanings. An opportunity with no assigned owner is a problem to investigate. An empty optional description is a different kind of gap. A single generic missing-data count may obscure which correction matters.
Trace a disputed tile back to evidence
Imagine the fictional coordinator expects four active opportunities but sees five. Start with the records included in the measure. Check the selected date range, stage rules and duplicate treatment before changing the chart. One old opportunity may have been reopened; another may have a blank closure status. Record the explanation and update the definition if the team discovers an unresolved policy.
A useful reconciliation sheet has four entries: expected result, displayed result, included record references and explanation. It is a small debugging aid for business users, rather than a second permanent source of truth. Once the issue is corrected, return ongoing maintenance to the named source owner.
Decide what the dashboard must not decide
A dashboard can highlight work for review, but a low count does not explain why it happened. Absence, delayed source updates, different assignment patterns and unresolved definitions can all affect the picture. Avoid treating a small set of operational tiles as a complete assessment of an employee or customer relationship.
If the source updates require repeated copying, review the transfer process separately through Tralionex's business automation service. Fixing the movement and ownership of records may be more valuable than adding charts. Keep the first reporting release tied to agreed decisions, then add a measure only when a named reader can explain how they will use it.
Frequently asked questions
How many metrics should the first dashboard contain?
Use only the measures needed for the first reader's decisions. The four here are an example, not a required quota.
Should the dashboard refresh live?
Only if the task needs it and the source supports it. Agree an appropriate refresh schedule and make freshness visible.
Can leads and opportunities mean the same thing?
Your team can choose its terminology, but it must use it consistently. Record the criteria rather than assuming software labels match your process.
What should happen when the data is wrong?
Show the issue, identify its source owner and correct the source. A prettier chart cannot fix an undefined or unreliable measure.
Plan your next project with Tralionex
Bring your metric definitions, anonymised sample records and the decisions your coordinator needs to make. Discuss a first dashboard scope with Tralionex that prioritises understandable measures, source ownership and a practical review process.
