The short answer
What matters most
Plan a business dashboard by defining its users, decisions, metric definitions, source systems, and refresh needs before choosing charts. Validate totals against agreed records and test access by role. A dashboard is ready to use when people understand what its figures mean, how current they are, and what action to take when the data is incomplete.
- Agree on definitions before resolving apparent reporting discrepancies.
- Show data freshness and source failures explicitly.
- Make validation and permission testing part of the delivery scope.
Compare before you commit
Decision at a glance
| Planning decision | What to write down | What to validate |
|---|---|---|
| Business purpose | User, question, and action for each view | Whether the view supports an actual decision |
| Metric definition | Formula, period, exclusions, and source of truth | Worked examples and reconciliation with approved reports |
| Refresh behavior | Schedule, latency, and failed-source handling | Whether stale or incomplete data is clearly identified |
| Access | Role, territory, account, and export permissions | Attempts to access another user’s restricted data |
What should your first dashboard include?
Choose one audience and the decisions it makes repeatedly. Include only the metrics needed for those decisions, with agreed definitions and a visible refresh time. Test the numbers against an approved source report before expanding to more departments.
Discuss your reporting challengeStart with decisions and users
Write down who will use the dashboard and what they should do differently after reading it. A sales representative may need an account follow-up list; a manager may need territory comparisons; leadership may need revenue and profit trends. These views can share data without sharing every chart.
For each proposed metric, ask what action follows a change. If nobody can describe an action or a useful monitoring purpose, reconsider its place in the first release. Focus the initial dashboard on a few connected decisions and leave less important views for later.
Agree on metric definitions
Revenue, active customers, and churn can mean different things to different teams. Define the formula, time period, filters, exclusions, and source of truth for each important measure. Decide how returns, cancellations, duplicates, and late entries affect the result.
Create a metric dictionary that a business owner can review. Include worked examples using approved sample records. If finance and sales report different totals, explain whether they are measuring different things before treating the difference as a software defect. A dashboard cannot resolve an unsettled business definition by itself.
Map sources and refresh needs
List each source system, its owner, available exports or APIs, access rules, and refresh constraints. Identify a shared key for customers, products, and locations. Decide how unmatched or conflicting records should be handled. Cleaning and joining data often needs explicit business decisions.
Choose freshness based on the decision. A daily sales planning view may have different needs from a live operations screen. Show when the data was last refreshed and what happens if a source fails. An attractive dashboard can mislead people if yesterday’s values appear to be current.
Validate totals and permissions
Compare dashboard totals with approved source reports over selected periods. Trace individual records through the calculation. Include unusual cases such as negative amounts, missing categories, changed account ownership, and partial periods. Assign someone to resolve discrepancies and sign off on definitions.
Test what each role can see and export. A representative might have access to their accounts while a manager sees a wider territory. Filters that hide records visually are not a substitute for enforcing access in the application. Record the intended boundaries before implementation.
Roll out around a real workflow
Ask a small group of intended users to complete actual tasks: identify accounts needing attention, explain a movement in a KPI, or prepare a territory review. Observe whether they can find the answer and understand the definitions. Their questions can reveal missing context more clearly than feedback on chart colors.
Salt’s sales intelligence project combines account health, buying history, territory search, and product trends. It gives sales users a connected workspace for reviewing accounts and planning follow-up. For your project, agree how adoption and decision quality will be assessed; the presence of similar charts alone does not establish a financial return.
Illustrative example · not a client result
Sales and finance disagree about revenue
Sales includes accepted orders while finance reports invoiced revenue after adjustments.
- Record the definition and source behind each number.
- Decide which business question each metric answers and name it accordingly.
- Reconcile selected records and document timing differences.
The decision
Keep both metrics if they serve distinct decisions. Do not silently change one calculation to force the totals to match.
Planning with a US team
When US teams work across regions, make the reporting time zone, fiscal periods, and currency treatment explicit. Agree how late entries affect closed periods and which owner approves restated figures.
Use this in your next discussion
Your planning checklist
Work through these points with your stakeholders or shortlisted partner. Record the owner of any unanswered question.
- Assign a business owner to every important metric.
- List source systems, join keys, and unresolved data gaps.
- Specify refresh timing and visible failure states.
- Approve sample calculations and reconcile selected periods.
- Test role access and export behavior before rollout.
Common questions
Do we need real-time dashboards?
Only if the business decision requires that freshness and the source systems can support it. A scheduled refresh may suit planning and management reports. Define acceptable delay and show the last successful refresh.
Should we clean all historical data before starting?
Not necessarily. Identify which records and fields the first decisions require, inspect their quality, and agree on handling exceptions. Disclose coverage limits so a partial dataset is not presented as a complete picture.
Can one dashboard serve every department?
Different users may need different definitions, detail, and access. Shared data can support multiple views, but each view should have a clear purpose. A single crowded screen is rarely a substitute for resolving these differences.
What should I share with Salt to start this discussion?
A short description is enough: the decision and the users who need to make it; current reports and the systems behind them; where totals disagree or data arrives too late. You can leave confidential documents out of the initial enquiry. We will clarify the requirements and agree whether a project, team, or assessment is the appropriate next step.
Explore Salt’s work
Relevant project experience
The sales intelligence dashboard brings account health, buying history, territory search, and product trends into a sales workspace. It is relevant when your reporting needs to guide an action, rather than simply display additional charts.
Your next step
Are your teams working from different numbers?
Salt builds dashboards and data applications around business workflows. Start with a decision your team struggles to make and the reports they use today. We can discuss the data connections and definitions needed to make that decision clearer.
A useful starting point
- The decision and the users who need to make it
- Current reports and the systems behind them
- Where totals disagree or data arrives too late
A few sentences are enough. You do not need a finished specification or confidential documents to start.
Discuss your reporting challengeRead client reviews