Ask a GM what their CRM is for and you get an answer about lead routing, follow-up cadence, maybe a DMS handoff for the F&I office. Ask what their sold-log is for and the honest answer is: nothing, after the deal funds. It gets exported once, emailed once, opened by the controller for the monthly close, and then it sits. The system of record remembers everything and nothing gets asked of it.
That's not a data problem. It's an attention problem — and it shows up in a search behavior nobody in the dealership would admit to out loud.
Why Are Dealers Googling "Dealership CRM Meaning"?
Autocomplete volume on queries like "dealership crm" and "dealership crm meaning" has held steady rather than declined, which is an unusual signal for a category that's been sold to dealers for two decades. People don't search for the definition of tools they understand. They search for the definition of tools they were sold, told to use, and never had explained.
That search behavior is a tell. It means the systems of record at most stores are functioning as compliance infrastructure — the place a deal has to pass through — rather than as intelligence infrastructure. Nobody is confused about how to log a sale. They're confused about what the store is supposed to get back out of having logged a few thousand of them.
The honest answer is: usually nothing. The sold-log is the highest-signal document in the building and it's also the most under-read.
What Actually Lives in a Dealership's Sold-Log?
Strip away the deal-specific fields — buyer name, trade VIN, F&I products — and every sold-log reduces to the same five facts: sale date, model year, make, model, and a new-or-used read. That's not a rich schema. It's a bare one. But run twelve or twenty-four months of it against live stock and it answers questions the DMS was never built to answer:
Which models are actually moving, independent of how long they sit. Which models the store keeps ordering that keep piling up. And — where the timing lines up — what price a given model actually sold at, not what it listed at.
None of that requires a new integration. It requires someone to open the export and cross-reference it against today's lot, which is exactly the kind of manual correlation work that gets deprioritized the moment the deal desk gets busy. The data was never the bottleneck. The cross-referencing was.
Why Doesn't Sold Velocity Show Up Anywhere Dealers Already Look?
Sell-through, the metric most dealers actually track, is inferred — it's a proxy built from how long a VIN sits on the lot before it disappears from the website. That's a reasonable proxy when it's the only signal available. It is still a proxy. A car can vanish from a site because it sold, because it got wholesaled, or because a scrape missed a cycle.
Sold velocity computed from an actual delivered-units log is a different claim entirely — it's not how long a model sits, it's how many of a given model actually left the store as paid deals in a given window. The two numbers correlate, but they diverge exactly where it matters: on the models a store over-orders because they don't sit long (floorplan-friendly) but don't convert to signed deals at the rate the lot-turn number implies.
That gap — sold-vs-stocked — is the actual merchandising signal buried in a spreadsheet nobody reopens. It tells a buyer what to order more of, what to slow down, and what to stop taking on trade. None of that is visible from a website scrape alone. It requires the sold-log.
This is the same argument this publication has made before about where inventory truth actually lives — see the case for treating the dealer's public site as the live inventory record — except here the missing half isn't current stock. It's what already left.
Can You Recover a Price Band From a Sold-Log That Has No Price Column?
Most sold-log exports don't carry a price field at all — or if they do, it's post-discount, post-rebate, post-doc-fee, and functionally useless for reconstructing what the vehicle was actually listed at when it sold. This is usually where the analysis stops. No price column, no pricing insight, back to the spreadsheet.
But a sold VIN isn't just a row in an export. It's also, somewhere, a row in every inventory snapshot taken while that car sat on the lot. Joining a sold VIN against the store's own historical inventory captures recovers the listed price that unit carried just before it sold — without the sold-log needing a price field at all.
Do that across a full model line and a pattern falls out that no single deal sheet shows: the P25–P75 range — the actual band of listed prices a given model sold within, not the band it was priced at. A model listed consistently above that band isn't necessarily overpriced in the abstract. It's overpriced relative to what that specific store's buyers have actually paid for it.
That's a materially different statement than "check KBB" or "match the market average." It's the store's own selling history, read back to itself.
What Does This Mean If Your Sold-Log Export Is Messy?
The practical objection to any of this is always the same: our export doesn't have a clean new/used column, our make field has three spellings of the same brand, our DMS report doesn't look like anyone else's DMS report. That objection is correct, and it's also not a reason to skip the analysis — it's a data-normalization problem, not a data-absence problem.
A sold-log's columns can be mapped onto a canonical sales schema regardless of which DMS produced the export, working across whatever layout the file actually uses rather than requiring a fixed template. Where a genuinely necessary field is missing — no new/used flag at a franchise store, for instance — it can be derived from what the row does contain: model year, sale date, and the store's own franchise, each delivery classified rather than left blank. Inferred values get flagged as inferred. The analysis states its own coverage instead of presenting a guess as a fact.
There's a floor, though, and it matters: sale date, year, make, model, and a new/used read are the minimum a file has to support. A sold-log that can't support those fields fails the upload with the exact fields it's missing, rather than proceeding on a fabricated value. That's a deliberate constraint, not a limitation to route around — a merchandising call built on an invented new/used split is worse than no call at all.
What About Trend and Seasonality — Or Is That Overreach?
The temptation with any historical dataset is to find a trend line the first month there's data to plot one. That temptation is exactly how a dealership ends up over-ordering a model because of a six-week blip that got read as a season.
Year-over-year trend reads require at least two years of sold history, and a repeating seasonal peak isn't confirmed until at least three years are on file — the analysis states its own confidence rather than asserting a season from an insufficient window. A store eighteen months into keeping usable records gets sold velocity and price-band guidance today. It doesn't get a seasonality claim it hasn't earned yet, and it isn't told otherwise.
The same discipline applies to gross. A sold-log shows what a car sold for, not what the store made on it — those are different numbers, and conflating them is how merchandising advice turns into fiction. Selling price is not gross, and no economics get invented for the deal beyond what the sold-log and inventory history can actually show.
This same restraint — stating a limitation instead of papering over it with a plausible-sounding number — is the same posture this publication has argued a real audit trail requires; see the piece on what an actual compliance record has to look like when the FTC comes asking.
The AUTONOMi Approach to Historical Sales Intelligence
AEGIS reads an uploaded sold-log through the same Inventory Intel channel a dealer uses to hand over any document, and recognizes it as data to analyze rather than an instruction to obey. Buyer names and any other personal information in the file are dropped at parse and never stored — the analysis runs on units and dates, not on customers.
From there the merchandising layer does the cross-referencing no one on the floor has time for: sold velocity per model, sold-vs-currently-stocked gaps that flag what to order more of and what to stop taking on trade, and — where the uploaded history overlaps with the store's own inventory captures — the P25–P75 price band each model actually sold within, with live stock priced above that band flagged directly. Off-brand trades and auction buys, which often make up a third of a store's used volume, get analyzed at the make and make-plus-model level too — which makes to take on trade, pay up for, or pass on — derived from the store's own new-vehicle mix rather than configured by hand.
Every one of those findings is hash-chained the same way every other AEGIS decision is — AXIOM records every dealer-impacting decision through a hash-chained audit entry the dealer can read back. A price-band recommendation isn't a black-box number handed down; it's a documented read of the store's own sold history, and the store can see exactly how it was reached.
What Happens to the Store That Actually Reads Its Sold-Log?
None of this requires new hardware, a DMS migration, or a new vendor relationship. It requires uploading a file most stores already export monthly and pointing a system at it that's willing to say "I don't have three years of data, so I won't claim a season" instead of guessing.
The stores that skip this aren't behind because they lack the data. They're behind because the data has been sitting in a spreadsheet, unopened, since the deal funded — while the lot gets restocked on instinct and the same models get reordered because that's what got ordered last time. The gap between "we have a sold-log" and "we know what our sold-log says" is closing for the stores willing to upload the file. For a dealer group ready to see what a season or two of their own sold history actually shows about price and demand, the fastest way to find out is to connect a sold-log and see what AEGIS finds.
