Property-Based vs Contact-Based Customer Records
Almost nobody asks a vendor this question, and it quietly determines whether your service history survives the next twenty years of house sales in your territory.
A contact-based system organises everything around the person. A property-based system organises it around the address.
In HVAC this is not a preference. Your service history belongs to the equipment installed at a location — and when the house sells, the furnace stays and the customer leaves. A contact-based system loses the thread at exactly that moment.
The two data models
Both systems store the same facts. The difference is which fact is the anchor — and that determines what survives when the relationship between person and place changes.
Why HVAC cares more than other trades
Three characteristics make this distinction sharper in heating and cooling than in most service businesses.
The asset is fixed and long-lived. A furnace installed in 2019 will still be there in 2039, and it will need service every year in between. Very few trades have a twenty-year relationship with a specific piece of equipment at a specific address.
Occupancy turns over faster than the equipment. Typical residential tenure runs well under the service life of a heating system. Over the life of one furnace, an address may see two or three different households.
Install age drives your replacement pipeline. Knowing which addresses in your territory have equipment approaching end of life is the most valuable list a shop can own. That knowledge is a property attribute, not a person attribute.
What breaks with contact-based records
The house sells
The most common failure, and the most expensive. The new owner calls for a no-heat visit. Your system has no record of the address, so your technician arrives blind to a system they have serviced eleven times. And your replacement pipeline just lost an entry it should have flagged.
Landlords and property managers
A property manager with forty units is one contact with forty addresses, each with its own equipment and history. Contact-based systems handle this by nesting addresses under the contact — which works until the management contract moves to a different company and all forty histories go with the old contact.
Two names, one house
The husband books the maintenance visit, the wife books the repair, and you now have two contacts with two partial histories for one furnace. Nobody notices until someone asks when the system was last serviced and the answer depends on who you look up.
Multi-unit and commercial
A four-plex has four furnaces at one street address. A small commercial building has three rooftop units. Contact-based systems flatten these into a single customer record with a pile of undifferentiated service notes.
What property-based records enable
| Capability | Why it needs a property anchor |
|---|---|
| Equipment history at arrival | The technician sees what is installed and what has been done to it, regardless of who called |
| Replacement targeting by install year | Query addresses with equipment over fifteen years old — the single most valuable list you can build |
| Warranty tracking | Warranties attach to equipment at a location, not to a person |
| Multi-unit management | Four units at one address are four equipment records, each with its own history |
| Recurring agreements that survive a sale | The plan can be offered to the new owner with a documented service record as the pitch |
| Access and site notes that stay useful | “Crawl space entrance behind the water heater” is true no matter who lives there |
The reality: most systems do both, but one is primary
Very few platforms are purely one or the other. Most store people and places and link them. The question that matters is which one is the primary record — because that determines what happens at the awkward moments.
Trade-built field service platforms generally treat the property as primary. General-purpose CRMs almost always treat the contact as primary, because they were built for industries where the customer is a person or a company rather than a building.
Open your system and try to answer this without knowing anyone’s name:
“What equipment is installed at 412 Oak Street, and when was it last serviced?”
If you can search the address and get a straight answer, you have property-based records. If you have to find the customer first and then locate the address underneath them, you have contact-based records with addresses attached.
What to ask a vendor
Four questions, and ask for the answer demonstrated rather than described:
1. “Show me a property record with two different owners over time.” The response tells you everything. If they cannot produce one, the model is contact-first.
2. “A house sells. Walk me through what you do.” Good answer: you add a new occupant to the existing property and the history stays. Weak answer: you create a new customer and can link to the old one.
3. “Can I search for all addresses with equipment installed before 2012?” This is your replacement pipeline. If the answer involves exporting to a spreadsheet, it is not a real capability.
4. “How do you handle four units at one street address?” You want separate equipment records under one property, not four customers with the same address or one customer with four sets of notes.
If you are already on a contact-based system
Switching platforms for this reason alone is rarely worth the disruption. Three things help without migrating:
Standardise address entry now. Most of the pain in any later migration comes from the same house existing as “412 Oak St”, “412 Oak Street” and “412 Oak St.” Agree a format and enforce it.
Put equipment details in a structured field, not in notes. Make, model, serial and install year in dedicated fields are migratable. The same information buried in a free-text note is not.
Record occupancy changes as a change, not a new customer. When a house sells, note it on the existing address rather than starting fresh. It is manual, and it preserves the thread.
If you do eventually migrate, be realistic about what transfers. Customer names, addresses and basic job history usually move. Photos, attachments, custom fields and detailed equipment records frequently do not — which is covered further in moving from paper to software.
Frequently asked questions
How do I tell whether my system is property-based or contact-based?
Does this matter for a small residential shop?
Can a contact-based system handle property managers?
Is it worth switching platforms just for this?
What is the most valuable thing property-based records unlock?
What should I do today if I am on a contact-based system?
What to do next
- Run the address test on your current system. Search an address without a name and see what comes back.
- Check whether install year is a structured field. If it lives in notes, your replacement pipeline is not queryable.
- Agree an address format with whoever enters data, today. It costs nothing and it is the single biggest factor in any future migration.
- In any vendor demo, ask to see a property with two owners over time. Ask to see it, not hear about it.
- How HVAC scheduling software works — where property records feed the dispatch process
- Moving from paper to software — what transfers and what does not
- Capacity planning — protecting slots for replacement opportunities
This guide describes two data models as documented in vendor materials and industry sources. Individual platforms implement them differently and several offer hybrid approaches — confirm how any specific system behaves by asking for a demonstration rather than a description.