crm
One Record Per Customer, and the Day You Find Out You Had Three
Duplicate customer records are not a tidiness problem. They are how a business loses the history of a job at the moment it needs it most.
Nobody sets out to keep three records for one customer. It happens the way most data problems happen: through entirely reasonable individual decisions made by people who could not see each other's screens.
The estimator meets them at the door and starts a card. The office takes a call about the same address a week later, searches for the surname, spells it the way it sounded, and starts another. The crew lead opens a job on the day of the work with the address as the title. Each of those is the correct thing to do with the information in front of that person. Together they are three partial histories of one relationship, and the complete one does not exist anywhere.
The day it costs money
For months the duplicates cost nothing you can see. A slightly confusing search result. Two reminders where there should have been one. Mild embarrassment.
Then one of these happens.
The customer disputes the scope. They say the quote covered the garage. You say it did not. The quote is attached to one record, the site photos to another, and the text message where it was discussed is on a phone. You are not arguing from a position of strength. You are arguing from three positions.
A warranty call comes in four years later. The crew that did the work is gone. The person who answers the phone searches the name, finds the record that has the invoice but not the materials, and tells the customer you have no record of the job. That answer is false and it sounds like a company that does not keep records.
The job needs to be matched to a claim. Insurance work in particular rewards a single continuous file: the date of loss, the inspection, the scope, the supplement, the completion photos, and the dates each of those happened. Assembled afterwards from three records it is a reconstruction, and it reads like one.
Somebody asks what you have on them. Where a privacy right applies, the question is not "what is in the CRM", it is "what do you hold about this person", and three partial records means three places to look and a real chance of missing one.
Why merging later is harder than it sounds
The instinct is to fix this with a cleanup. Export, find the duplicates, merge them, carry on.
Merging is lossy in a way that is easy to underestimate. Two records with different phone numbers are not obviously one customer and a stale number; they may be a landlord and a tenant. Two records at one address might be a household or might be the previous owner. Merge wrongly and you have not fixed a duplicate, you have created a composite person who never existed, and the mistake is now invisible because it looks like a clean record.
That is the argument for preventing it at the point of creation rather than reconciling it at the end of the quarter. The question "is this somebody we already know" has an answer at the moment the second touch arrives, and almost never has a confident one six months later.
What prevention looks like in practice
Search before you create, and make the search good. Most duplicate records exist because the search was by exact surname and the second entry was spelled differently. A search that also matches phone number, email and address catches most of them, and the cost of the match is one extra second.
Make the address a first-class field, not a line of text. Address is the strongest duplicate signal in field work and the weakest in most contact databases, because it is usually stored as a string somebody typed.
Attach everything to the relationship, never to the event. A quote belongs to a customer who has a quote, not to a quote that mentions a customer. The distinction sounds academic until the second job.
Let the record absorb new touches instead of spawning new ones. A second enquiry from a known number should open the existing record with a new line on it, which is also simply faster for the person answering the phone.
The consent field people forget
One more reason the single record matters, and it is the one with legal weight behind it.
A home improvement sale made at the customer's residence is, under the FTC's cooling-off rule at 16 CFR 429.1, generally subject to a three-day right to cancel, and the seller must give the buyer a dated copy of the contract and a cancellation form that states that right. The rule has exceptions and thresholds, and state law frequently adds more, so the specifics are worth reading rather than remembering: the FTC publishes the rule and its plain-language summary.
What matters here is the shape of the evidence. The question that gets asked later is not "do you have a signed contract", it is "when was it signed, where was it signed, and what was handed over at the time". That is three facts about one event, and they are only usable if they live on one record together with the date. Spread across three partial files, the answer you can prove is weaker than the answer that is true.
The test
Pick a customer you did work for two years ago. Open your system and try to answer, from one screen: who they are, how they first came to you, what you quoted, what you did, what you charged, whether you were paid, and whether anybody has spoken to them since.
If that takes more than a minute, you do not have a record. You have a filing cabinet with the drawers in different rooms.