Skip to content

Private equity and portfolios

Home services roll-ups: combining job records across acquired brands

By SourceX Editorial · Updated

Short answer

Home services roll-up data integration works when every brand's job records are mapped to one shared structure while each record keeps a tag for its brand, owning entity and source system. Map systems first, then job types and outcomes, then customers and equipment, then rights. Combined views serve operations; licensing still clears brand by brand.

Key takeaways

  • A combined job model needs brand, owning entity, source system and source ID on every record.
  • Crosswalks translate each brand's job types and cause codes into one platform vocabulary without overwriting the original labels.
  • Customers served by two brands should be cross-referenced, not merged, because each brand's notices and opt-outs still apply.
  • Combining adds value when brands share outcome definitions and comparable record quality; unlabeled thin records dilute rich ones.
  • Rights travel with each brand's records, so tags must make any brand removable from a combined set.

What does combining job records across brands involve?#

Combining job records across brands means translating each acquired company's history into one shared structure, so a no-cool call in one market and a no-heat call in another can be compared. It is not a single export poured into one database, and it does not require every brand to be on the same software first.

The shared structure is usually small: customer, service location, equipment, call or booking, estimate, job, visit, invoice, membership and callback. What makes it work is the set of extra fields every record carries: the brand, the legal entity that owns the record, the source system and the original ID. Those fields let the platform trace any combined row back to where it came from.

Combining also exposes what each brand never recorded. A brand that did not capture equipment details, or kept photos outside the job record, shows up as empty columns in the shared model. That is useful in itself: the platform learns where to fix data capture going forward, not only where history is thin.

The mapping sequence, in order#

The mapping sequence runs from systems to meaning to rights, because each step depends on the one before it. Skipping ahead, for example comparing callback rates before job types are aligned, produces numbers that look precise and mean little.

Assign each step an owner. Systems and structure usually sit with platform IT or a data lead, vocabulary and outcomes with experienced service managers from the brands, and rights with counsel and the platform CFO.

  • Systems: list each brand's current and legacy field service platforms, accounting, phone system and photo storage, and how much history is still accessible.
  • Structure: map each system's tables and fields to the shared model, keeping the original ID on every record.
  • Vocabulary: build crosswalks for job types, cause codes, outcomes and equipment categories.
  • Identity: match customers, locations and equipment across brands with cross-references, not overwrites.
  • Outcomes: define a callback, a warranty claim and a completed job the same way for every brand.
  • Rights: attach each brand's deal structure, notices, contracts and restrictions to its records.
  • Quality: score each brand's records for linkage, completeness and depth of technician notes.

Build crosswalks for job types and outcomes#

Crosswalks for job types and outcomes translate each brand's labels into a platform vocabulary while keeping the original label beside the new one. Brands describe the same repair in different words, and technicians in one shop use cause codes another shop never adopted.

Keep the crosswalk as a maintained table with an owner, not a one-off script. Each new add-on extends it, and each change is logged so past reports can be reproduced. Where a brand's label cannot be mapped with confidence, map it to an unclassified category rather than forcing a guess.

Outcome definitions need the same discipline. One brand counts any return visit as a callback, another only returns on the same equipment, a third only the visits it did not charge for. Agree one definition, apply it to every brand's history and keep each brand's original flag beside it, so comparisons and any later package say exactly what a callback means.

Build crosswalks for job types and outcomes
Brand A labelBrand B labelPlatform category
No cool, replaced capacitorAC not cooling, cap swapCooling failure, capacitor replacement
Water heater leak, replaced unitWH replacement, tank failureWater heater replacement, tank leak
Breaker trips, panel inspectionPanel issue, diagnosticElectrical panel diagnostic
Return visit, same issueRecallCallback on a prior job

Customers, locations and equipment that appear in more than one brand#

Customers, locations and equipment that appear in more than one brand should be linked through a cross-reference table rather than merged into one record. A household may have used the HVAC brand for a furnace and the plumbing brand for a water heater, each under its own privacy notice and marketing permissions.

Address matching does most of the work, with equipment serial numbers and phone numbers as supporting signals. The cross-reference gives operations a whole-home view, while each brand's original records, opt-outs and restrictions stay intact. If a brand is later sold or a customer asks for deletion, the platform can act on exactly the right rows.

Keep rights and provenance attached to every record#

Rights and provenance stay attached to every record through tags set at intake, because the combined model will outlive the people who remember how each brand arrived. A minimal tag set covers brand, owning entity, acquisition, deal type, source system, date range and known restrictions.

Restrictions are what make tagging worth the effort. A franchised brand, a brand with property management contracts that limit data use, or a brand whose pre-closing records stayed with the seller should be filterable in one step. Licensing reviews, lender questions and exit diligence all start with which brand's records can be used for what, and tags answer that without a new project.

Keep rights and provenance attached to every record
TagExample valueWhat it answers later
BrandA short brand codeWhich brand's history a row belongs to
Owning legal entityThe subsidiary that holds the recordsWho signs for any use beyond operations
Acquisition and deal typeClosing date; stock or asset purchaseWhich agreement transferred the records and what stayed with the seller
Source system and original IDLegacy platform name and its job numberHow to trace a combined row back to the archive
Date rangeFirst and last record datesWhich years each brand covers and where gaps sit
Known restrictionsFranchise terms, client confidentiality, opt-outsWhich rows to exclude with one filter
Preparation statusNot reviewed, redacted or clearedWhether personal details have been removed and checked

When a combined dataset is worth more, and when it is not#

A combined dataset is worth more when brands share outcome definitions and comparable record quality, so breadth across trades, regions and equipment adds information instead of noise. It is worth less when one brand's thin records are blended with another's rich ones without labels.

For licensing, combination is a packaging decision made late, not a precondition. Each entity's records clear their own rights review and approval, and a combined package is assembled only from brands that cleared.

When a combined dataset is worth more, and when it is not
SituationEffect of combining
Brands share crosswalked job types and callback definitionsComparable history across markets and trades
Every record keeps brand and source tagsAny brand can be included or removed cleanly
One brand has notes and photos, another only invoicesUneven depth that must be labeled, not averaged
Rights differ by brandCombined use limited to what every included brand allows
Legacy history was lost for some brandsGaps in coverage that must be disclosed in any package

Illustrative: one job model for HVAC, plumbing and electrical brands#

Illustrative: a fictional platform owns five brands across HVAC, plumbing and electrical work. Three run ServiceTitan, one runs Housecall Pro and one still uses a legacy system kept in read-only mode. The value creation lead wants one view of callbacks across brands.

The team builds the shared model and a crosswalk first, and finds that two brands logged callbacks as new jobs with no link to the original visit. Rather than guessing, they rebuild links using address, equipment and a return window agreed with the service managers, and mark those links as inferred. The cross-reference also shows that many households were served by more than one brand.

Operations get a callback view by brand, trade and technician. When the platform later screens its records for licensing, the tags let counsel clear three brands, hold back the franchised brand and park the legacy brand until its archive is verified, without rebuilding anything.

How SourceX works with combined brand records#

SourceX treats a combined set as several suppliers' records rather than one, so Supply, Rights, Preparation, Approval and Delivery in the SourceX five-step transaction each run for the entity that owns the records, even when a final package spans several brands. Assessment begins with metadata, not files.

The tags described above line up with the SourceX Evidence Packet: provenance, including the acquisition chain and source system, licensing rights, permitted use, the privacy record and release authorization. Platforms that tag at intake already hold most of the facts those sections ask for.

Frequently asked questions

Should we combine records before we know whether we will license them?

Yes, if operations will use the combined view, which platforms commonly want for pricing, callback and technician analysis. The tagging that keeps licensing options open costs little when done at intake and a great deal when reconstructed long after the people who knew each brand's systems have left.

Do we need a data warehouse to combine job records?

Not necessarily. A warehouse helps if the platform already runs reporting on one, but a structured archive store, a shared model and maintained crosswalk tables can be enough to start. What matters is that original IDs and tags survive whichever tool you use.

Can brands still on different field service platforms be combined?

Yes. Combining works from exports or connectors, so brands do not have to share software first. Many platforms combine history before software consolidation finishes, which also checks that each brand's legacy archive is complete before its old system is retired.

What happens to combined records if we sell one brand?

If every record carries brand and entity tags, that brand's records can be separated and handed over or retained as the sale agreement requires. Without tags, separation becomes a forensic exercise, and the buyer's diligence team will ask how the platform knows it handed over everything.

Related resources

See if your company qualifies

A short company assessment. No data uploads are needed.

See if you qualify