Should a multi-location company run one ServiceTitan tenant with business units or separate tenants?
One tenant with business units gives you unified reporting, shared customer history and a single integration surface, at the cost of tighter coupling between locations that may want different processes. Separate tenants give autonomy and clean separation, at the cost of needing an external layer to roll anything up. If you plan to report across locations regularly, one tenant is far cheaper to work with.
The decision is really about who needs the rollup
The technical comparison is less important than the reporting requirement. If ownership looks at consolidated performance weekly, every additional tenant adds a permanent integration cost. If locations are genuinely independent businesses that share only a brand, separation may be honest and the rollup can be occasional.
Companies acquiring their way to scale usually inherit the answer rather than choosing it, and end up with a mix.
What one tenant buys you
- One customer table. A customer who moves across a market boundary is still one customer with one history.
- One set of price books and job types, which means cross-location comparison is meaningful instead of an apples-to-oranges exercise.
- One integration to build and maintain. Credentials, sync jobs, monitoring and mapping are done once.
- Comparable technician and rep metrics, because the definitions are literally the same records.
What it costs you
Shared configuration means shared consequences. A price book change, a new job type or a workflow adjustment affects everyone unless it is carefully scoped to a business unit. Locations with genuinely different service models will feel constrained, and the strongest local manager tends to lobby for exceptions that erode the comparability you built the structure to get.
Permissions also get harder. Keeping one location from seeing another's data inside a shared tenant is a configuration exercise that has to be maintained as people change roles.
If you already have multiple tenants
The rollup problem is solvable, and it is mostly a mapping problem rather than a technical one. Each tenant has its own ids, its own job type names and its own business unit names. The work is building and maintaining a translation table that maps every local dimension to a shared corporate dimension, then normalizing all tenants into one warehouse behind it.
The hard part is not the first mapping. It is governance: someone has to own the corporate taxonomy and approve new job types, or the mapping decays within two quarters. We build that layer as part of ServiceTitan integration work, and it is usually what makes multi-location dashboards possible at all. For companies running several brands, the same layer feeds location-level rollups in intelligence briefs.
Topics: multi-location · business units · architecture · rollup
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.