Should a CRM record be a person or a household?
For residential service work, the account should be the property and the people should attach to it. A husband books the appointment, a wife signs the estimate, and the tenant is the one who lets the technician in — that is one job and three humans. Systems that force a single contact per job either lose the other people or create duplicate accounts for the same address.
The work happens at an address, not to a person
Almost everything a home service business sells is attached to a physical location: the furnace, the panel, the sewer line, the roof. The people come and go. The equipment stays.
That is why field service platforms model location separately from customer, and why marketing tools that assume one contact equals one customer feel wrong the moment you use them for residential work. If you organize around the person, you fragment the service history of the house.
Where a person-only model breaks
- Two decision makers. One books, the other approves the price. If only one is on the record, half your follow-up goes to someone who cannot say yes.
- Property changes hands. The new owner inherits equipment you installed and warranty you owe, and has no relationship with the prior contact.
- Rentals. The landlord pays, the tenant schedules, and the property manager is copied on everything. Three roles, one job.
- Marketing suppression. Two records at one address means the same house gets the same postcard twice, which looks careless and doubles the cost.
A model that survives contact
The workable shape is three layers: an account or household, one or more properties beneath it, and contacts with roles attached. Roles matter more than people think — billing contact, scheduling contact, on-site contact and decision maker are genuinely different, and knowing which is which changes who you call.
Not every platform supports this natively. When it does not, the usual approach is to keep the operational hierarchy in the field service system, keep the conversational record in the marketing system, and resolve them in an integration layer that holds the household identity. That resolution layer is what lets a report say “households served” rather than “records touched.”
Commercial customers need the same idea, one level up
For commercial work the equivalent hierarchy is parent company, sites and contacts. A restaurant group with fourteen locations is one relationship, fourteen service histories and possibly one accounts-payable contact for all of them.
Getting this wrong shows up first in reporting: revenue by customer either lists fourteen small accounts or one giant one, and neither answers the question you asked. Deciding the hierarchy early is far cheaper than restructuring it later, which is why it belongs in the customer data design conversation before any dashboard gets built.
Topics: household · contacts · data model · residential
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.