Dealer Flywheel
Why do dealerships with working technology, documented processes and capable people still lose performance between them?
Operational intelligence and technology implementation for automotive dealerships: find where performance breaks between systems, people, information, timing and ownership, then help implement and measure the fix.
The observation.
The short version: why this exists.
A dealership can have functioning technology, documented processes, capable employees and established vendors, and still lose performance between them.
The problem isn't always a missing process or a broken piece of software. Failures can sit between systems, people, timing, ownership and information, where no single application can see them.
A store also doesn't necessarily need another piece of software. It may already own the technology that would solve the problem, with the feature turned off or the information arriving at the wrong moment. Dealer Flywheel is being built to find those failures with evidence first, before anyone recommends a fix.
Demo · Equity Mining Alert
Run the prototype.
A Dealer Flywheel prototype, shown outside the dealership systems it was built for. The same rules run here on a synthetic store, in your browser. No real customers, vehicles or results.
Equity Mining Alert · demo
Your next sale is already in your service lane.
A sample Nissan store's service morning. When a customer with equity, a lease ending soon or an expiring warranty checks in, the advisor sees why on the lane board and a named salesperson gets a text and a CRM task. If nobody takes it within minutes, it goes to the sales manager.
- Run the morning. Customers check in as the clock moves. Press +15 min to jump ahead.
- Service lane. Flagged customers are highlighted with the reason and a talking point for the advisor.
- Salesperson. You're Ashley Chen. Your texts arrive here; claim them and log what happened. Other salespeople act on their own.
- Manager. Anything unclaimed escalates here, with today's counts: flagged, contacted on site, appointments and sold.
Prototype build note · Equity Mining Alert
- The problem
- Customers with equity, a lease ending soon or a warranty running out sit in the service lane every morning, and Sales doesn't know they're there.
- Riskiest assumption
- That a salesperson will claim an alert within minutes if it reaches them by text the moment the customer checks in.
- What it does
- Rules flag customers as they check in. The advisor sees why on the lane board, a named salesperson gets a text and a CRM task, and anything unclaimed goes to the sales manager after 10 minutes.
- Left to rules and people
- Every flag is a rule you can read, with no model involved. The salesperson decides whether and how to approach the customer.
- What's next
- Run it on a real store's service schedule and compare contacts and appointments with a morning without it.
Service lane · advisor board
This morning's appointments
Highlighted cards are customers the engine flagged. The advisor sees why and what to say; Sales is alerted the moment they check in.
Sales manager
Service to Sales, this morning
These numbers come from the morning you just ran, including what you logged as Ashley and what the other salespeople did on their own.
Escalated to you
Build note.
The problem, the assumption, the system, and what comes next. Results appear here only once a real store has run it.
- The problem
- Dealerships lose performance in the handoffs between working tools and capable people: work nobody owns, waits nobody sees, information that arrives too late, and exceptions that fall between systems.
- Riskiest assumption
- That a store's own CRM export holds enough evidence to show where those handoffs fail, before any new software goes in.
- What it does
- A diagnostic pipeline anonymizes a CRM activity export, turns it into an event log, maps the paths leads actually take, and classifies every lead as untouched, orphaned or a duplicate under rules the dealer sets.
- Left to rules and people
- Every threshold belongs to the dealer, and the report prints any rule still on its suggested value. Customer fields are replaced with a salted hash before analysis. A finding without enough evidence is reported as not enough evidence, and an analyst, not the pipeline, confirms the cause.
- What's next
- The first run on a real store's data. Until then the scoring cutoffs are marked provisional.
Built so far.
Real code with tests. It has run on synthetic data only. No store has run it yet, so there are no results to show.
Diagnostic pipeline
Intake, anonymize, normalize, mine and report. A CRM export goes in and a manager-readable diagnostic comes out.
Lead ownership classifier
One classifier with two views: a baseline of every lead in the export window, and a morning list of open exceptions by lead ID only, so the list itself carries no customer names or numbers.
Findings contract
A schema every finding must pass. Validation fails closed, so a run with an invalid finding writes nothing.
Equity Mining Alert
A service-lane alert: flag customers with equity as they check in, text a salesperson and escalate if nobody claims it.
Planned.
Not built yet. The demos would come from the same code and run in the browser on synthetic data.
First run on a real store
Run the diagnostic on one store's own CRM export, with the dealer setting the rules. Findings appear on this page only after that, and only with the evidence behind them.
Lead ownership morning list
Change the dealer's rules, like store hours or the untouched threshold, and watch the list of untouched, orphaned and duplicate leads re-sort.
Can this be a finding?
Add evidence or test calls and watch the verdict and confidence change. A clean result without enough coverage becomes not enough evidence.
CRM activity normalizer
Messy CRM activity labels become a clean event timeline. A label it doesn't know is refused, not guessed.