The DMS and the CRM each believe they own the customer
In short
Take 20 customers who both bought a car and had it serviced, and try to link each pair using one identifier that exists in both systems. If more than two or three fail, the dealership has no customer master — the systems were never designed to share one, and no matching logic downstream fixes that until somebody decides which system is authoritative for which field.
Key takeaways
- Sample 20 buyers who also serviced: the count that links on a shared identifier tells you drift from absent design.
- Neither system was built to be the customer master, so the master has to be declared rather than discovered.
- Household, business and individual are three different entities, and most stores model only one of them.
- Survivorship is decided per field, not per system — consent is the field that never merges.
- Own the cross-reference table yourself. Adopting either system's id as the global key repeats the problem.
Take 20 customers who both bought a car and had it serviced, and try to link each pair using one identifier that exists in both systems. If more than two or three fail, this is not drift you can clean up. The dealership has no customer master, the two systems were never designed to share one, and matching logic bolted on downstream will keep producing near-misses until somebody decides which system is authoritative for which field.
The symptoms all look like separate bugs. Service history does not appear against a sales customer. An equity list misses the owners most likely to trade. Two people from the same store call the same household on the same afternoon. Somebody who opted out in one system keeps receiving reminders from the other. They are one problem, and the check below tells you how deep it goes before anyone writes matching code.
The check: twenty customers, one identifier, counted
- Pull 20 customers from the DMS who have both a delivered vehicle and at least one closed repair order in the last 24 months. Spread them across different months so you are not sampling a single campaign or a single advisor's habits.
- For each one, record the DMS customer id, mobile number, email, surname, postcode and the VIN of the vehicle involved.
- Find the same person in the CRM. Write down which field you used to find them, and whether you had to make a judgement call to be sure it was the same person.
- Score each of the 20 into exactly one bucket: linked by an identifier both systems store; linked only by your own judgement; or not linked at all.
- Before drawing any conclusion, confirm the extract you sampled from parsed cleanly. A single shifted column produces exactly this symptom across a whole file, which is the failure taken apart in the export gained a column and the parser did not notice.
- Repeat with 10 business or fleet customers. They fail differently and at a higher rate, and a sample of retail customers alone will tell you the problem is smaller than it is.
Two housekeeping checks stop you diagnosing the wrong thing. Re-run the sample against a different night's file: if the population itself moved, you may be chasing a feed problem rather than an identity one, and yesterday's export does not match today's copy separates those. And confirm every sampled record still exists upstream, because a customer deleted at the source lingers forever in a snapshot-fed mirror — the mechanism in the deal was voided and it is still open in your app.
Four causes, and the evidence that confirms each
| Cause | What you see | Confirming evidence | Where the fix has to sit |
|---|---|---|---|
| No shared identifier | Every link you made was by hand, on name and phone | Neither record stores the other system's id anywhere | A cross-reference table you own, not a field in either system |
| Household versus individual | Service sits against a spouse; the buyer looks like a non-customer | One system holds one record per address, the other one per person | A model that separates person, household and vehicle |
| Business versus retail | Fleet vehicles link to a company, service to whoever dropped the car off | The contact on the order is a driver, not the account holder | A contact-to-account relationship the CRM often does not have |
| Different creation doorways | Duplicates cluster by channel or by time of day | Records created by the booking flow carry no CRM id at all | A creation policy: who may create a customer, and what they must check first |
No shared identifier is the default state, not a fault
The DMS keys a customer to deals, vehicles and a ledger. The CRM keys a customer to enquiries, activities and a salesperson. Both are internally coherent and neither was built to be the other's authority, so the absence of a shared key is the expected outcome of installing two systems rather than evidence that somebody was careless.
It matters because a shared identifier and a matching rule are different things. A matching rule guesses; a shared identifier asserts. Normalising phone numbers to their last 10 digits and lower-casing email will raise your link rate, and it will still leave the pairs that share nothing comparable. Enquiry-side duplication is its own separate problem with its own separate fix, worked through in one shopper, three CRM records.
Household, business, and the two modelling mistakes
- One record per address collapses a household into a person. The car is serviced in one name and financed in another, and every retention list built on the service record targets the wrong adult.
- One record per person loses the household entirely. Two vehicles at one address get two independent reminder streams, which reads to the customer as a store that does not know them.
- A business customer is an account with contacts, not a person with a company name in the surname field. The driver who books the service is not the person who authorises the spend, and modelling them as one record means approvals go to the wrong inbox.
- Vehicle ownership is an event with a date, not an attribute of a person. A VIN does not carry an owner, which is the argument in the VIN identifies a vehicle, not an owner, so ownership belongs on a dated relationship rather than on the vehicle row.
Declaring the master: a resolution order you can write down
- Name the master per entity, not per system. Person, household, vehicle, deal and service visit each get one authoritative source, and it is normal for those to be different systems.
- Mint your own identifier for each mastered entity, held in your own store. Adopting either system's id as the global key means a system change becomes a data migration.
- Write the resolution order as an ordered list of rules — exact identifier match, then normalised mobile, then normalised email, then surname with postcode — and record which rule fired on every link. A merge nobody can explain is a merge nobody will trust.
- Send disagreements to a review queue rather than to an automatic merge. Two records that match on surname and postcode but differ on mobile are a father and son roughly as often as they are a duplicate.
- Publish survivorship per field, sign it off with the general manager, and put it somewhere the next developer will find it.
| Field | Which value wins | Why | The exception |
|---|---|---|---|
| Mobile number | Most recently confirmed, whichever system holds it | Recency beats provenance for contactability | A number the customer asked you to stop using |
| Postal address | The system that captured a signed document | An address on paperwork was verified by somebody | Any later recorded change of address |
| Marketing consent | Never merged: the most restrictive value applies | Consent is a permission, not an attribute | There is no exception |
| Name spelling | The system that issued the invoice | Legal documents drive the ledger and the finance file | An obvious keying error, corrected once at source |
| Vehicle ownership | The dated deal record | Ownership is an event, and events have dates | A recorded sale, transfer or trade-in |
Two systems do not disagree about who the customer is. They were each asked a different question, and both answered correctly.
Rules that stop the same history splitting again next month
Merging is the easy half. Every merge you perform is undone by the next record created outside the rules, so the durable work is in creation and in what a merge is allowed to touch.
- Creation rules first. If the booking flow and the service scheduler can each create a customer without checking, matching is a treadmill. Give every doorway one search-before-create step and log what it found.
- Suppression is global. A stop request recorded anywhere applies everywhere, which is why consent needs its own record with its own evidence — what a consent record has to prove sets out the fields.
- Re-run the 20-customer check monthly against a fresh sample and chart the link rate. It is the only number that tells you whether the fix held.
- Staff identity has the same shape and the same failure — a leaver rehired becomes two people — and is handled in mapping staff identity across three systems.
- If a system is being replaced, the dedupe question changes completely, and belongs to moving VIN-keyed history without duplicates rather than here.
Standing up an identity layer that both systems feed, with a review queue a manager can actually work, is a small product rather than a script — the shape of the work we scope under MVP and product builds. The rest of this silo sits under DMS, CRM and shop-system integration, inside our automotive retail and aftermarket work.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Which system should be the customer master, the DMS or the CRM?
Neither, as a whole. Declare the master per entity: the DMS is usually authoritative for the deal, the vehicle and anything on signed paperwork, while the CRM is usually authoritative for enquiry history, consent capture and contact preferences. Then hold your own identifier over both, so replacing either system does not force a re-key of everything downstream.
Why does service history not show against a sales customer?
Because the two records were created independently and nothing links them. The service side usually creates a customer at check-in from whoever is standing there, and the sales side created one at enquiry, so both are correct records of different events. Until a cross-reference exists, joining them by name and phone is a guess that fails most often on households and businesses.
Is it safe to merge duplicate customer records automatically?
Only where an identifier both systems store matches exactly. Anything softer — surname plus postcode, similar emails, a shared landline — belongs in a review queue, because a false merge is far harder to undo than a missed one. Keep every merge reversible, keep the source identifiers on the row, and never let a merge rewrite the contents of a repair order or a signed document.
How many duplicates are normal in a dealership customer file?
There is no safe published number to aim at, and any figure quoted without a definition of what counted as a duplicate is worthless. Measure your own instead: the 20-customer link check gives you a rate that is comparable month to month, and the trend after you fix creation rules is the number worth reporting.
- customer data
- dms integration
- identity resolution
- data quality
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- Three salespeople are texting the same shopperOne shopper with three CRM records is either a matching failure or an ordering failure, and the fix for one makes the other worse. Here is the check that tells them apart in an afternoon.diagnostic
- Data brokers in the dealership stack: who is actually sending you the fileBetween the dealership's system of record and your build sits a party with its own schema, its own cadence and an authorisation only the dealer can sign or revoke.definition
- Four times a repair-order number changes, and what to key on insteadAn RO number identifies a document at one store on one day. Four ordinary events renumber, duplicate or supersede it, and a fifth problem makes it repeat outright.definition
- The CRM says sixty-two, the DMS says fifty-eight, and the manager trusts neitherA 4-unit gap between two systems almost never means 4 lost records. Reconcile one month at record level into four buckets and the shape of the result names the cause before anyone has to argue about it.diagnostic
- The deal was voided in the DMS and it is still open in your appA voided deal or a deleted repair order never announces itself. It simply stops appearing in tonight's file, which looks identical to a truncated transfer — so the inference needs a health check before anyone trusts it.diagnostic
- The export gained a column overnight and the parser did not noticeThe vendor adding a column is normal. A loader that trusts field position is the defect, and the fix is three assertions that run before the first row is parsed.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation