Home services and trades
Illustrative workflow data package: a home services company's job histories
By SourceX Editorial · Updated
Short answer
A workflow data package for a home services company is a scoped, de-identified set of linked job histories: inquiries, estimates, jobs, dispatch events, invoices, equipment and callbacks, joined by protected keys. The illustrative manifest below shows record families, fields, removal rules and Evidence Packet items, so an owner can see what would be shared and what never leaves.
Key takeaways
- A workflow data package is a defined slice of history for a licensed use, not a copy of your field service database.
- Linkage keys are replaced with pseudonymous IDs, and the mapping back to real customers stays with the supplier.
- Removal rules are written before export and applied to free text, attachments and structured fields alike.
- The SourceX Evidence Packet travels with the package and records provenance, rights, permitted use, privacy steps and release authorization.
What a workflow data package is, and what it is not#
A workflow data package is a curated set of records that shows how a business handled real work from request to outcome, prepared for one licensed use. It is not a database dump, a login to your systems or a transfer of ownership; the company keeps its records and licenses a defined copy.
AI developers use packages like this to train and test systems that book, triage, dispatch and follow up on service work. They need the sequence more than the volume: a call that became an estimate, a job, a callback and a renewal teaches an agent what a whole piece of work looks like.
Every package is described by a manifest: the record families included, the fields kept in each, the keys that join them, the years covered, the removal rules applied and the documentation that travels with it. The example below is entirely fictional and exists to show the shape of that manifest.
Illustrative: the company behind this package#
Illustrative: a fictional residential HVAC and plumbing company has run the same field service platform since moving off paper tickets. It also uses a cloud phone system with call logs, a photo app for job documentation and QuickBooks for accounting.
The owner wants to understand what licensing its job histories would involve before agreeing to anything. A metadata-only fit check shows that inquiries, estimates, jobs, invoices, equipment records and callbacks all link through job and customer IDs in the field service platform for every year since the migration. Earlier paper-era records are out of scope. The manifest opens with a short header before any record family is listed.
- Supplier: the operating company that holds the records, named as the legal entity that signs.
- Source systems: the field service platform, the phone system's call logs and the photo app, with export dates.
- Years covered: every full year since the platform migration, with any month-level gaps listed.
- Licensed use: training and evaluating service booking, dispatch and follow-up agents, as defined in the license.
- Refresh: none in the first term, with an option to add later years under the same rules.
- Exclusions summary: call audio, payment data, HR records, confidential commercial accounts and paper-era records.
Record families and fields in the manifest#
The record families in this illustrative manifest follow the life of a service job, from first call to repeat visit. Each family keeps the fields that show decisions and outcomes and drops fields that only identify people.
| Record family | Fields kept | Fields removed | Linkage key |
|---|---|---|---|
| Inquiries | Date, channel, call reason, booked or not, reason if not booked | Caller name, phone number, email, call audio | Inquiry ID, pseudonymous customer key |
| Estimates | Options presented, option chosen, equipment model, accepted or declined | Customer signature, financing application details | Estimate ID, job ID |
| Jobs | Job type, priority, booking notes, technician notes after cleaning | Street address, access codes, names in notes | Job ID, location key |
| Dispatch events | Dispatched, arrived and completed times, technician pseudonym, skill tags | Technician name, raw GPS trail | Job ID, technician pseudonym |
| Invoices | Pricebook codes and line types; amounts banded or removed as the owner chose | Card and bank details, billing address | Invoice ID, job ID |
| Equipment | Equipment type, make, model, install year, service history | Serial numbers that trace to a household | Equipment ID, location key |
| Callbacks and warranty | Link to original job, reason, resolution | Customer comments that name people | Callback job ID, original job ID |
| Memberships | Plan type, visit cycle, renewal or lapse | Payment method, auto-renew card details | Membership ID, pseudonymous customer key |
How linkage keys are protected#
Linkage keys are what make a workflow package worth licensing, and they are also the main re-identification risk. In this illustration every customer ID, location ID and technician ID is replaced with a pseudonymous key generated by the supplier, typically with a keyed hash whose secret stays in-house, so the same customer stays consistent across records without the original ID ever leaving.
The mapping table that connects pseudonymous keys to real customers never leaves the company. Pseudonymized records can still count as personal information under some privacy laws, which is why the license also bars re-identification and onward sharing. Addresses become broad regions, so climate and housing patterns survive without pointing to a house. Dates are kept to the day only where seasonality or response time matters, and are checked against small regions where rare combinations could single someone out.
Free-text fields get the same treatment. When a technician note mentions the customer by name or refers to the house next door, the name is replaced with a placeholder and the reference is generalized, so the note still explains what was found and fixed.
Removal rules written before export#
Removal rules are agreed before anything is exported, so the same rules apply across every record family and every year. In this illustration the rules cover structured fields, free text and attachments.
- Remove customer names, phone numbers, email addresses and street addresses from every field.
- Remove gate codes, lockbox codes, alarm codes and pet or access instructions from booking and technician notes.
- Remove payment details and financing information entirely.
- Replace technician and CSR names with consistent pseudonyms; exclude HR and payroll records.
- Exclude call audio; include call reasons and dispositions only.
- Exclude photos that show faces, house numbers, vehicles or interiors with personal items.
- Exclude commercial accounts whose contracts carry confidentiality clauses.
- Review a sample of cleaned free text by hand before the package is approved.
Quality checks before the package is approved#
Quality checks confirm that the package says what the manifest promises before anyone signs. In this illustration they run on the prepared copy, after removal rules are applied and before the owner reviews a sample.
Any check that fails sends the affected records back through preparation rather than into the package with a note.
- Every job joins to its inquiry, dispatch events and invoice, or is listed as a known gap.
- Callbacks point to an original job that exists in the package.
- Each year in the stated range has records for every month, with gaps explained.
- Duplicate customers created by data entry are merged under one pseudonymous key.
- An automated scan for names, phone numbers, emails and addresses finds nothing left in any field.
- A person reads a sample of cleaned notes and confirms they still make sense.
Evidence Packet items for this package#
The SourceX Evidence Packet is the documentation that travels with the package and lets the buyer, the supplier and SourceX see the same record of what was approved. In this illustration each of its five items is filled in as shown below.
| Evidence Packet item | What it records in this illustration |
|---|---|
| Provenance | Source systems, export dates and methods, record families and years covered |
| Licensing rights | Confirmation the company owns the records, plus the software, customer and franchise terms reviewed |
| Permitted use | The uses the license allows, restrictions on re-identification and onward sharing, and the term |
| Privacy record | Removal rules, pseudonymization method, sample review results and items excluded |
| Release authorization | Who approved the final package for the company, and when |
What the owner approved, and what stayed home#
The owner approved the package only after reviewing the manifest, a cleaned sample and the Evidence Packet draft. Call audio, invoice amounts for commercial accounts, all photos showing interiors and every record from the paper era stayed out.
Delivery followed the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Because the package was large, it stayed in the company's own storage until release and then shipped on an encrypted drive rather than through a hosted platform. The company keeps ownership of every record; the buyer receives a license for the defined use.
Frequently asked questions
How many years of history does a package like this need?
There is no fixed minimum. Several years of continuous, linked history usually tells a fuller story, because it covers seasons, staff turnover and equipment aging. A shorter span can still fit a specific buyer request if the records are well linked and the outcomes are recorded.
Can we leave pricing out entirely?
Yes. Pricing is a supplier choice. Invoice amounts can be removed, banded into ranges or kept, and pricebook codes can stay without dollar values. Leaving prices out still preserves the record of what was recommended, chosen and completed, which is often what developers need most.
Who creates the pseudonymous keys?
The supplier creates them, or a preparation step run under the supplier's control, so the mapping back to real customers never leaves the company. The method is documented in the privacy record of the Evidence Packet without revealing the mapping itself.
Can we add later years to the package?
Often, yes. Some licenses include scheduled refreshes, which add new periods under the same removal rules and keys. A refresh still goes through review and approval, and the Evidence Packet is updated each time with the new date range.
Does the buyer get access to our systems?
No. The buyer receives a prepared copy of the agreed records, never a login to your field service platform, phone system or accounting. Everything that leaves is listed in the manifest and approved by you first.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.