Three systems in a dealership each behave as though they are authoritative, and the question of which one actually is has usually never been answered in writing. Adding AI does not resolve the ambiguity — it acts on it, which is how a store discovers that two systems disagreed about a customer's phone number.
This guide covers why the conflict exists, how to assign ownership per object, the precedence rules, where it breaks, and what to measure.
Why does the conflict exist?
Because each system was designed to be complete on its own.
A DMS holds deals, service history, inventory and customers because it needs all of them to do accounting. A CRM holds customers, activities and vehicles of interest because it needs all of them to manage a pipeline. An inventory tool holds vehicles, pricing and photos. Every object a dealership cares about exists in at least two of them, and none was built assuming it was secondary.
That was tolerable when people mediated between them. A rep who saw two different phone numbers picked the right one. Automation does not: it picks whichever system it was connected to, acts on it, and the disagreement becomes a customer experience.
Assign ownership, per object
The exercise is one afternoon and it is the prerequisite for everything else.
| Object | Usually owned by | Why |
|---|---|---|
| Deal and financial data | DMS | Accounting depends on it; nothing else may write it |
| Service history | DMS | Same |
| Vehicle, physical and status | DMS | It is the record of what you own |
| Vehicle pricing and merchandising | Inventory tool | It is the one making the decision |
| Customer contact details | Contested — decide | The most common conflict |
| Consent and opt-out state | Whichever is authoritative — decide, and enforce | The most consequential |
| Lead and activity history | CRM | It is the pipeline system |
| Appointments | Contested — decide | Sales and service frequently differ |
The two contested rows are where the damage happens, and the second one is not merely a data question — an opt-out recorded in one system and not the other is an obligation failure, per SMS compliance.
The precedence rules
Four rules, written down once
Rule Statement 1. One owner per object Named system, in writing. No exceptions and no "both" 2. Others read, do not write Non-owners may display it and may not change it 3. Conflicts resolve toward the owner Automatically, and logged 4. Consent is union, never intersection An opt-out anywhere applies everywhere. Permission requires the owner Rule four is the one that is not symmetric with the others, deliberately. For every other object the owner wins. For consent, the most restrictive state wins regardless of which system holds it — because the cost of contacting someone who opted out is of a different kind from the cost of not contacting someone who did not.
Where does AI make this worse?
Three ways, and they are all versions of acting on an ambiguity a person would have mediated.
1. It picks a side silently. Connected to the CRM, it uses the CRM's phone number. Nobody decided that; it was a consequence of which integration was built first.
2. It writes back into the ambiguity. A system that writes a corrected contact detail into the non-owning system deepens the divergence — the write-scoping problem in read, write and what breaks.
3. It acts at volume. A person encountering a conflict resolves one record. A sequence encounters it four hundred times before anyone notices.
Where does this break?
1. Nobody wrote it down. The default state, and everything else follows from it.
2. "Both are authoritative." Not a rule. Two owners means no owner.
3. Consent treated like any other field. The owner-wins rule is wrong for this one object, and applying it uniformly creates the exposure.
4. Precedence decided by integration order. Whichever system was connected first wins by accident, which is how most stores actually operate.
5. No conflict logging. Divergence is invisible until a customer reports it — the same blind spot as CRM data decay, and it compounds the integration scope question.
6. Ownership assigned to a system that cannot be written to. If the owner is read-only for a field, corrections have nowhere to go and the rule is unimplementable — the read-versus-write distinction in AI and the DMS. Resolving conflicts in practice is the matching-rules problem.
What should you measure?
| Metric | How to compute | What it catches |
|---|---|---|
| Objects with a written owner | Count ÷ shared objects | Should be all of them |
| Conflict rate, per object | Records where systems disagree ÷ records | Where ownership is failing |
| Contact-detail divergence | Phone or email differing across systems | The most common conflict |
| Consent-state divergence | Opt-out in one system and not another | The obligation metric |
| Writes by non-owners | Count, by system and field | Rule two, tested |
| Conflicts resolved automatically | Resolved ÷ detected | Whether the rules are implemented |
Row four should be zero, and it is the one worth running first. A single customer who opted out in service and is still receiving sales messages is both a complaint and an exposure, and the measurement that finds it takes one query across two systems.
Frequently asked questions
Which dealership system is the source of truth?
It depends on the object, and it has to be decided and written down. Deal, financial, service and physical vehicle data are usually owned by the DMS; pricing and merchandising by the inventory tool; leads and activity by the CRM. Customer contact details and consent state are contested and need an explicit decision.
Why does this matter more once AI is deployed?
Because people silently mediated the conflict and automation does not. A rep seeing two different phone numbers picked the right one; a sequence uses whichever system it happens to be connected to, acts on it hundreds of times, and the disagreement becomes a customer experience.
What are the precedence rules?
Four: one named owner per object with no exceptions, non-owners may read but not write, conflicts resolve automatically toward the owner and are logged, and consent is a union rather than an intersection — an opt-out anywhere applies everywhere.
Why is consent handled differently from other objects?
Because the costs are asymmetric. For most objects the owner's value should win. For consent, the most restrictive state should win regardless of which system holds it, because contacting someone who opted out is a different kind of error from failing to contact someone who did not.
How does ownership usually get decided in practice?
By integration order. Whichever system was connected first becomes the de facto authority, which means the most consequential data architecture decision in the store was made as a side effect of a project sequence nobody was thinking about.
What happens when the owning system cannot be written to?
The rule becomes unimplementable, because corrections have nowhere to go. Ownership has to be assigned to a system that can actually hold the authoritative value, which sometimes means the obvious owner is the wrong choice for a specific field.
How do you find out how bad the divergence is?
Run two queries across systems: contact details that differ, and consent state that differs. The first sizes the everyday problem and the second finds the obligation exposure, and both can be run before any decision about ownership is made.
What should be done first?
Measure consent-state divergence. It should be zero, it frequently is not, and a customer who opted out in one system while still receiving messages from another is both a complaint waiting to happen and an exposure that is entirely avoidable.
Conclusion
- Every shared object lives in at least two systems, and none was built assuming it was secondary.
- People mediated the conflict silently. Automation acts on it, at volume.
- One owner per object, in writing. "Both" is not a rule.
- Consent is the exception: most restrictive wins, wherever it is recorded.
- Measure consent-state divergence first. It should be zero and frequently is not.
Last updated: