Should I report on business units or job types in ServiceTitan?
Both, because they answer different questions. A business unit says who owns the result — which crew, trade, division or location carries the profit and loss. A job type says what the work was. Campaign says where it came from. Problems start when one dimension is asked to carry two meanings, which is what happens when business units get created to track a promotion or a marketing source.
Three dimensions, three questions
Think of it as ownership, nature and origin. Business unit answers ownership: whose number is this, who gets credit, whose budget absorbs the cost. Job type answers nature: was this a maintenance visit, a diagnostic, a replacement, a warranty return. Campaign answers origin: what produced the demand.
Kept clean, these three combine into almost every report an owner asks for. Muddled together, none of them work, and no amount of dashboard building recovers the lost distinction.
How the taxonomy usually goes wrong
- A business unit created for a promotion. Now the unit means both a crew and a marketing offer, and year-over-year comparison for that crew is broken permanently.
- Job types encoding priority. Emergency versus standard is a scheduling attribute, not a kind of work. When it lives in job type, you cannot count how many replacements you performed without summing several variants.
- Location baked into job type. This makes multi-location rollups require a mapping table forever.
- Retired options left active. Old values stay selectable, so the same work continues to be logged under labels the business stopped using two years ago.
The rule of thumb
A dimension should be something you would still need if the business had no marketing department and no promotions. Business units survive that test. Job types survive it. Anything created because of a campaign, a season, a spiff or an experiment does not, and belongs in tags or in the campaign field instead.
Tags exist precisely for the transient and the cross-cutting. They cost nothing to add, they can overlap, and retiring one does not corrupt history the way retiring a business unit does.
Reporting across a messy taxonomy
If the taxonomy is already tangled, do not start with a cleanup project — start with a mapping layer. A simple lookup table that maps every existing business unit and job type to a clean reporting category lets you produce coherent reports today while the operational cleanup happens on its own schedule.
That mapping table is a small piece of engineering with an outsized return, and it is standard practice in any serious ServiceTitan integration. It also becomes the place where multi-location operators reconcile locations that named things differently. See custom reporting for how those mappings feed the finished views.
Topics: business units · job types · taxonomy · reporting
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.