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.
| Brand A label | Brand B label | Platform category |
|---|---|---|
| No cool, replaced capacitor | AC not cooling, cap swap | Cooling failure, capacitor replacement |
| Water heater leak, replaced unit | WH replacement, tank failure | Water heater replacement, tank leak |
| Breaker trips, panel inspection | Panel issue, diagnostic | Electrical panel diagnostic |
| Return visit, same issue | Recall | Callback 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.
| Tag | Example value | What it answers later |
|---|---|---|
| Brand | A short brand code | Which brand's history a row belongs to |
| Owning legal entity | The subsidiary that holds the records | Who signs for any use beyond operations |
| Acquisition and deal type | Closing date; stock or asset purchase | Which agreement transferred the records and what stayed with the seller |
| Source system and original ID | Legacy platform name and its job number | How to trace a combined row back to the archive |
| Date range | First and last record dates | Which years each brand covers and where gaps sit |
| Known restrictions | Franchise terms, client confidentiality, opt-outs | Which rows to exclude with one filter |
| Preparation status | Not reviewed, redacted or cleared | Whether 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.
| Situation | Effect of combining |
|---|---|
| Brands share crosswalked job types and callback definitions | Comparable history across markets and trades |
| Every record keeps brand and source tags | Any brand can be included or removed cleanly |
| One brand has notes and photos, another only invoices | Uneven depth that must be labeled, not averaged |
| Rights differ by brand | Combined use limited to what every included brand allows |
| Legacy history was lost for some brands | Gaps 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.