Guide · Planning, buying and running AI
AI for Multi-Location Operations That Fixes the Vocabulary Before the Dashboard
McGuire Flanigan · Updated October 30, 2026 · 7 min read
A rollup across locations fails at the words, not the charts. The same job has two names, the same field is used two ways, and one site is quietly missing. Map the dialect, check that the numbers are comparable, then rank the differences that matter.
The Rollup Is Wrong Before Anyone Reads It
A multi-location business does not usually have a data problem at the top. Each location, on its own, runs fine and reports fine. The failure appears the moment those reports are added together, and the reason is almost always the words.
One location calls a maintenance visit a tune-up. Another types the technician name into a notes field instead of the assigned field. A third opens its day in a different timezone. Add those three together and the total is not a rollup. It is a number with no meaning, and it is exactly the number an owner makes decisions with.
The fix is not a better chart. It is a translation and a check that comes before the chart: what does this word mean at this site, and are these two figures actually the same kind of thing. Only then does a comparison mean anything.
The reframe
The hard part of multi-location is not aggregating the data. It is knowing which rows are comparable and which are two different words for two different things.
What the Dialect Costs You
Move the sliders to match your locations. The model counts the jobs that cross a location boundary in a form that is not comparable, and the manual reporting hours the translation replaces.
Jobs crossing a location boundary
97
of 880 per week, in a form something else has to interpret
Reporting hours back
72
per month across all locations
Annual value
$47,520
in recovered reporting time
Where the comparison breaks
Job type and status labels per location against the shared reporting map
Location A calls it a tune-up and location B calls it a maintenance visit. Roll them up without a map and the total is wrong before anyone reads it.
Where each location types the technician, the source, and the priority
One location puts the technician in the assigned field, another types the name into notes. Reporting reads the field, so a whole location reads as unassigned.
Local minimums, service areas, and pricing rules per location
A job that is strong at one location is marginal at another because the drive and the minimum differ. One threshold across all of them is wrong for all of them.
Timezone, tax, and price book per location
A nightly total that crosses a timezone boundary sums rows from two different days and nobody notices until a number looks impossible.
The absence of rows from a location that should have produced them
The quietest failure. A location with no data looks like a location with no problems, which is the exact opposite of the truth.
Illustrative estimate from the inputs above. Your own numbers will differ; this is not a measured result or client data.
One Rollup, Six Stages
Each stage names the system it touches, the payload it leaves behind, and the concrete failure it prevents.
Target System
Each location's operational platform
Source Read Per Location
Every location is read from its own system, in its own vocabulary, without assuming the fields mean the same thing. The agent starts by learning each location's dialect rather than imposing a schema on it.
The agent assumes a shared schema and silently drops the locations whose fields are named differently.
Stage payload
What Should Be Shared and What Must Stay Local
The mistake in multi-location reporting is forcing everything into one shape. Some things have to be common to be comparable. Everything else should stay local.
Shared
The definition of a job that is done
Local
The job types and labels a location actually uses
If done means something different at each site, no comparison is possible and no rollup is honest.
The service area rule as a check, not a constant
The actual boundary each site covers and the drive it implies
The rule is the same. The map is not. Applying one boundary to all sites misreads every site but one.
The response-time clock and its start point
The hours, the channels, and the on-call pattern
You can only compare response times if the clock starts at the same event, even when the hours differ.
The alert threshold for a job that has stalled
The baseline window per service type
A baseline that is right for a fast repair is wrong for a two-day install, and installs cluster by location.
The Rollup Reads. A Local Owner Acts.
Multi-location work runs into every local manager's autonomy, so the boundary matters. The agent reads, translates, and surfaces. It never rewrites a location's system or changes a local rule.
Autonomous
- Read every location in its own system and its own vocabulary
- Maintain the translation map between local labels and the shared shape
- Check that compared figures are actually comparable
- Rank the divergences that matter rather than the averages
- Mark incomplete locations rather than filling the gap
Supervised
- Route a divergence to a named local owner for action
- Draft the local exception note for a manager to send
- Propose a threshold or mapping change for approval
- Flag a location whose data has gone quiet for a person to check
Never
- Change a location's configuration, price book, or thresholds on its own
- Rewrite a local record to match the shared schema
- Report a rollup that hides a non-reporting location
- Compare figures across a timezone or currency boundary without normalizing
- Publish a location's numbers to another location's manager
Two Things We Will Tell You to Buy Elsewhere
Not a data warehouse project
A warehouse is where comparable data should eventually live, and if you already have one, this sits in front of it. But buying a warehouse first, with locations still using different words for the same job, gives you a faster way to read a number that is confidently wrong. Fix the vocabulary, then warehouse it.
Not a reason to centralize every decision
Comparable numbers do not mean identical operations. A location that serves a rural route and one that serves a dense metro should not share a threshold, a schedule, or a price book. The rollup gives you a fair comparison. What each location does with it stays local.
Straight Answers
Where This Fits in Operations
This page owns the comparison across locations. The operations pages around it own the single-location day.
Find Out Which Locations Are Not Comparable
Send us your locations and your last weekly rollup. In thirty minutes we will show you where the words diverge, which numbers cannot be compared, and how much of the report is actually a translation problem. You keep the analysis whether or not you hire us.
Questions operators ask
Do all my locations have to run the same platform?
- No, and that is usually the reason the rollup is broken. Locations grow by acquisition, so one site is on ServiceTitan, another on Jobber, and the newest on Housecall Pro. The agent reads each in its own system and maps the differences onto a shared shape. It does not require you to migrate anyone, because a migration is a year-long project that does not fix the reporting gap this quarter.
Why not just build one dashboard across all the data?
- Because a dashboard assumes the data is already comparable, and the whole problem is that it is not. Two locations calling the same job by different names will roll up into a number that is confidently wrong. The translation and the comparability check come before any dashboard, and a dashboard without them is a faster way to read a bad number.
How does it handle a location that is not reporting?
- It says so, plainly, and it does not fill the gap. A location with no rows is the most dangerous kind of missing data, because it looks like a location with no problems. The agent marks it as incomplete in the rollup and flags it for a person, rather than treating absence as a zero.
Does the rollup replace the local reports?
- No, it follows them. The local exception goes to the local owner first, and the rollup is produced after, with the incompleteness marked. A rollup that arrives before anyone local has seen their own numbers trains managers to wait for headquarters to tell them what is wrong at their own site.
What is the first thing to fix?
- The mapping of job types and status labels, because almost every other number depends on it. Once the same word means the same thing across locations, response time, completion rate, and revenue per job all become comparable. Most rollup failures trace back to that one layer.
See where AI fits in your operation
Thirty minutes on how the work actually moves. No pack of agents. No obligation to build. If we can help, we will show you the first paths. If we cannot, we will say so.
Sources
- api.getjobber.com/api/graphql, api.getjobber.com
- api.tekmetric.com/api/v1, api.tekmetric.com
More guides on planning, buying and running ai
An AI Agent for Stalled Jobs That Names the Owner, Not Just the Problem
Monitoring finds the stall. The agent works it: reads the reason, names the owner, drafts the unblocking message, and waits for real motion before the job leaves the list.
AI Job Monitoring for the Work That Stopped Without Telling You
A job does not fail loudly, it sits. The monitor holds an expected next state and duration per job type, watches for the motion that should have happened, and raises the jobs that stopped.
Automate Internal Handoffs Before the Job Falls Between Two People
A handoff is an owner, a trigger, a due time, and an escalation. Model where your handoffs stall and watch for the one that never completed.
Automate Job Status Updates Without Teaching Customers to Ignore You
A generic status message is worse than silence. Decide what changed, whether this customer cares, and say it once, plainly, in time. Your platform stays the record.
Automate Task Creation from CRM for Service Businesses
One record change, one owner, one due time, one proof of done. Model how many tasks your CRM should actually create, and how many should close from evidence.