Multi-location business reporting combines information from different branches into a consistent view of performance while preserving the detail needed to explain differences. Start with shared definitions, comparable reporting periods, and metrics that account for location size and service mix. A ranking of revenue alone cannot tell you which branch needs help or which practice another location should adopt.
The useful question is not simply, "Which location is winning?" It is, "What explains the difference, and what should we do about it?"
What belongs on a multi-location dashboard?
Build the first scorecard around decisions rather than every available field. For a service business, consider four questions: Is demand changing? Can we deliver the work? What does the work contribute? Where do customers encounter delays?
| Decision | Starting measure | Context needed | | --- | --- | --- | | Where should we investigate demand? | Completed jobs and qualified inquiries | Service type, period, and operating days | | Where is capacity constrained? | Ready-to-work backlog and available labor | Required skills, staffing, and blocked jobs | | Which work deserves a closer review? | Revenue and consistently defined job contribution | Assigned cost categories and job mix | | Where are commitments being missed? | On-time completion for jobs due in the period | Original promise dates and overdue open work |
These are starting measures, not universal targets. Choose the measures that support the decisions your managers actually own. A branch manager should be able to move from a headline number to the records that explain it.
Agree on the definition before comparing locations
Imagine one branch counts a job when work is completed, another when an invoice is issued, and a third when payment arrives. Combining those counts produces a number, but not a consistent measure of completed work.
For each KPI, document the event being measured, date field, included statuses, exclusions, source system, and responsible owner. Separate job completion, invoicing, and payment collection instead of treating them as interchangeable.
Also distinguish a location from a legal entity, department, and service area. A company can operate several branches, and a technician can perform work for more than one branch. Decide whether a job belongs to the selling location, performing location, or both through separately labeled views.
Retain the original identifiers from each system. A repair order numbered 1042 at one branch must not accidentally match order 1042 at another. Use a key that includes the source and relevant company or location context.
Microsoft's star-schema guidance explains the modeling distinction between business events, such as sales, and dimensions, such as locations and dates. Applied here, that separation gives each branch the same reporting structure without erasing its identity.
Why should you avoid averaging branch averages?
Calculate a group average from the combined numerator and denominator, rather than taking an unweighted average of branch averages. Otherwise, a small branch can influence the result as much as a large one.
Consider this illustrative example, not a client result:
| Location | Completed jobs | Revenue for those jobs | Average revenue per job | | --- | --- | --- | --- | | Branch A | 900 | $90,000 | $100 | | Branch B | 100 | $30,000 | $300 | | Combined | 1,000 | $120,000 | $120 |
Averaging $100 and $300 gives $200, which is not the group's revenue per job. The correct calculation is $120,000 divided by 1,000 jobs: $120.
Use the same discipline for percentages: combine the underlying counts or amounts before calculating the group rate. Display the denominator so readers can distinguish a result based on ten jobs from one based on a thousand.
Compare similar operations, then investigate differences
A branch handling major repairs should not automatically be judged against a location focused on quick maintenance. Break results down by relevant service categories before attributing a difference to management or employee performance.
Use same-location comparisons for growth, with a clearly stated inclusion rule. Show newly opened locations separately until they have comparable history. For a partial month, compare equivalent periods and consider differences in operating days rather than placing partial results beside a full prior month.
Keep shared expenses visible. A branch-level operating contribution before central overhead answers a different question from a result after allocated overhead. Label the view and document the allocation rule. A management dashboard should not present an informal rollup as a formal consolidated financial statement.
Make missing information visible
A branch that failed to refresh should not look like a branch with zero activity. Show the last successful data refresh by source, flag missing feeds, and distinguish unavailable values from genuine zeros.
Check branch totals against agreed source reports before using the scorecard in a management meeting. When a result changes, preserve enough detail to determine whether operations changed or the reporting definition did.
For the underlying causes of conflicting totals, see why business reports show different numbers.
Turn the scorecard into a management routine
Assign each meaningful exception an owner, a next action, and a review date. "Backlog increased" is an observation. "Review the oldest parts-blocked jobs and confirm supplier dates before Friday" is an action.
Start with a small set of comparable measures and expand when they support real decisions. The purpose of multi-location BI is not to create a more elaborate leaderboard. It is to help the business distinguish a local issue, a shared constraint, and a practice worth repeating.
Ferguson BI provides fractional business intelligence and reporting support. To discuss a branch scorecard, contact Caleb Ferguson with your location count, main systems, and one comparison you cannot currently make with confidence.