Engineering and delivery

How to Design Dashboards for Multi-Location Organisations

How can teams compare locations fairly while preserving permissions and score meaning? Define reporting populations before designing charts.

Define the question behind the comparison

A dashboard comparing locations should help you decide what to investigate next. A low score may reflect a different questionnaire version, a small sample or incomplete assessments rather than worse performance. Before choosing charts, write down the decision the report needs to support.

For example, an operations manager deciding where to review service quality needs the reporting period, eligible locations, completed assessments and scoring rules. Put those conditions within reach of the score. If a manager cannot tell which assessments contributed to a result, a league table gives them little basis for acting on it.

Make the reporting population visible

Define how region, organisation, date and assessment status affect the result. Show an empty result as “no completed assessments” when that is what it means; displaying zero would suggest measured performance. Preserve historical questionnaire and scoring versions so a rule change does not silently rewrite an old comparison.

Benchmarks need a stated population: the locations and assessments included in the comparison. Comparing one location with every location in a group may be inappropriate when their operations or assessment criteria differ. We would settle those inclusion rules before offering a benchmark selector, then show enough context for someone reading an exported report to understand the comparison too.

Apply access to detail and aggregate views

A regional manager may be entitled to aggregate information without access to individual responses. Decide what they can see at each step: the regional total, a location’s score and the responses behind that score. Apply the same policy to exports, direct report URLs and cached results, so opening a saved link does not reveal detail the dashboard withholds.

Organisational changes need attention too. If a location moves to another region, decide whether historical results follow its current assignment or the assignment at the time of assessment. The first choice lets a manager review the locations they manage today; the second preserves the reporting structure for that period. Label the choice clearly so readers know why a historical regional total includes a particular location.

Test the dashboard against a small known dataset

Create an illustrative dataset with two regions, several locations, an incomplete assessment and a not-applicable answer. Calculate expected results independently, then test filtering and export behaviour. Include a user who must not see one of the regions.

For a hypothetical scoring check, give one completed assessment four equally weighted questions: three earn 1 out of 1 and one is not applicable. If the agreed rule excludes not-applicable questions, the expected result is 3 out of 3, or 100%. Counting that answer as zero produces 3 out of 4, or 75%. Neither the chart nor its colour can resolve that difference: the scoring definition must say which calculation applies. Check separately whether the incomplete assessment should contribute at all.

Use these hand-calculated results to check the summary, drill-down and export. A filtered regional view should contain only the assessments permitted by both the filter and the user’s access. Keep the calculation definitions with the report handover so a later change can be checked against the same examples. A smaller set of views that people can explain is more useful than a large collection of unexplained metrics.

Apply this to your project

Bring a sample questionnaire, the reporting roles and a comparison you need managers to make. Those give us a practical starting point for discussing scoring, access and what the dashboard should explain.

Explore assessment mystery shopping platforms and the related anonymised project account. Discuss your implementation question.

Planning guidance from Webvelopment Editorial. Confirm platform requirements and project assumptions before committing budget.

Let’s move things forward

Start a conversation

Tell us what you are working towards. We’ll help you find a practical next step.

Discuss This Planning Question