An AI consultant for a car dealership is someone you hire to decide what to build or buy, and often to run the deployment. The entire risk of the engagement sits in the scope of work, because a scope that names deliverables produces software and a scope that names hours produces a deck.
This guide covers what an AI consultant actually does for a dealership, the seven clauses a scope of work has to contain, how engagements are priced, where they fail, and how to tell a deliverable from a deck before you sign.
What does an AI consultant actually do for a dealership?
Three distinct jobs get sold under one title, and conflating them is the first way engagements go wrong.
Assessment. Working out which problem is worth solving, what it is costing you now, and whether the answer is a product, an integration or a build. Output is a decision with numbers behind it. Short — weeks.
Selection. Running an evaluation against real vendors with real criteria, including the integration work each one implies. Output is a recommendation you can defend to an owner, plus the cost model that supports it.
Delivery. Actually making it work: specification, integration, pilot, hardening, handover. Output is software running in your store, on a sequence that looks like the 30-day implementation plan. Months, for anything touching several systems.
A firm that only does the first two has no stake in whether the thing works. A firm that only does the third will build whatever you asked for, including the wrong thing. The engagements that work either cover all three or hand off between them with an explicit, written boundary.
The question that separates the two kinds of consultant
Ask what happens in month four.
If the answer is a presentation, you are buying analysis. That is legitimate and sometimes exactly right — but price it as analysis and do not expect software.
If the answer is a system in production with a named owner inside your building, you are buying delivery, and everything below applies.
What are the seven clauses a scope of work must contain?
1. The problem, as a number. Not "improve lead handling." A current-state measurement and a target: first-touch time outside business hours, today versus the commitment. Without this, nobody can say whether the engagement succeeded, which is convenient for exactly one party.
2. The systems, by name and version. Your DMS, your CRM, the specific lead sources. "Integrates with your existing systems" is not a clause, it is a hope. The integration inventory belongs in the document, because it is where the budget actually goes.
3. Escalation and failure behaviour. What the system does with a price question, an angry customer, an ambiguous message, an outage. This is the single most skipped clause and the most expensive to add later, because by then the behaviour is already in front of customers.
4. Data handling and compliance. Where customer data goes, how long it is kept, how consent is recorded, who can access logs. Under the Safeguards Rule you are the accountable party regardless of who wrote the code, so this cannot be deferred to the vendor's standard terms.
5. Acceptance criteria. The specific, testable conditions under which you agree the work is done. Written before work starts, not negotiated at the end when one party has all the leverage.
6. Handover. Source code in your repository, infrastructure in your accounts, credentials transferred, a runbook, and a named internal owner. Without this clause you have rented software with switching costs attached.
7. What happens when it goes wrong. Response times, who is on the hook, how long support runs after acceptance, and the terms for walking away mid-engagement.
The clause audit
Take any proposal on your desk and count which of the seven it contains, explicitly, in writing.
Clause Usually present Usually missing 1. Problem as a number ✗ 2. Systems by name and version ✓ 3. Escalation and failure behaviour ✗ 4. Data handling and compliance partial 5. Acceptance criteria ✗ 6. Handover ✗ 7. Failure and exit terms partial Four of seven missing is the normal state of a proposal, including from firms doing good work. The clauses are not missing because anyone is hiding something — they are missing because nobody asked, and writing them is harder than not writing them.
Ask. A firm that will not put acceptance criteria and handover in writing is telling you something useful at no cost.
How are AI consultants priced, and which model should you want?
| Model | How it works | Aligns when | Fails when |
|---|---|---|---|
| Hourly / time and materials | You pay for hours worked | Scope is genuinely unknown and you want to explore | Scope is known — the incentive runs against efficiency |
| Fixed price per phase | Each phase priced against named deliverables | Deliverables are specified well enough to price | The spec is vague, so the firm prices in risk you pay for |
| Retainer | Monthly fee for ongoing availability | After delivery, for maintenance and iteration | Used during delivery — it pays for presence, not outcomes |
| Outcome-based | Payment tied to a metric moving | The metric is clean, attributable and auditable | Almost always, in a dealership — too many confounders |
The honest default is fixed price per phase, with the assessment phase priced separately and cheaply. Pay a small fixed fee to find out whether there is a project. If there is, price the delivery against a specification that now exists because the assessment produced it.
Be sceptical of outcome-based pricing in a retail automotive context. Attribution is genuinely hard — lead source attribution alone defeats most stores — and a contract that depends on attributing a sales lift to one system will produce a dispute rather than an outcome.
Where do consulting engagements fail?
1. The assessment never becomes a specification. A strong diagnosis, correctly identifying the problem, and then nothing executable. The deliverable has to be a document someone can build from, or it is an expensive second opinion.
2. The consultant interviews the wrong people. Talking to ownership and not to the BDC manager who actually works the leads produces a system designed for the org chart rather than the operation. Insist the discovery includes the people who will use the thing daily.
3. Nobody inside the store owns it. The named owner in clause six is not a formality. An engagement where no internal person has time allocated to it will stall at every decision point and die at handover.
4. The pilot is never baselined. If nobody measured first-touch time before the system was switched on, the result is unarguable in both directions. Baseline before, or the engagement ends in opinion.
5. The engagement expands to fill the retainer. Monthly fees with no acceptance criteria run until someone gets tired. That is not a consultant problem; it is a missing clause five.
What should you measure during the engagement?
| Metric | How to compute | What it tells you |
|---|---|---|
| Days from kickoff to written specification | Calendar days | Whether the firm converts analysis into something buildable |
| Baseline captured before go-live | Yes or no, per target metric | Whether any claim about the result will be defensible |
| Internal hours consumed | Logged, by role, at fully loaded rates | The real cost, which is never on the invoice |
| Acceptance criteria met at handover | Count passed ÷ total | Whether the engagement finished or merely stopped |
The second row is binary and it is the one that gets skipped under schedule pressure. There is no way to recover a baseline after go-live.
Frequently asked questions
What does an AI consultant for a car dealership do?
Three different jobs are sold under that title: assessing which problem is worth solving and what it costs today, selecting between products and approaches with a defensible cost model, and delivering a working system through specification, integration, pilot and handover. Engagements that work either cover all three or define an explicit written boundary where one ends and the next begins.
How much does an AI consultant cost for a dealership?
Assessment phases are typically a low four-figure fixed fee and should be priced cheaply on purpose, since their job is to determine whether a project exists. Delivery is quoted against the specification the assessment produces and generally runs from the low five figures upward, plus an ongoing maintenance line of roughly 1 to 2 percent of build cost per month.
Should I pay a consultant hourly or fixed price?
Fixed price per phase, in most cases, with the assessment phase priced separately. Hourly makes sense only when the scope is genuinely unknown and you want to explore, because once the scope is known, hourly billing puts the firm's incentives directly against efficiency.
What should an AI consulting scope of work include?
Seven clauses: the problem expressed as a current number and a target, the systems named with versions, escalation and failure behaviour, data handling and compliance obligations, testable acceptance criteria written before work starts, full handover including source code and a named internal owner, and the terms covering failure and exit.
How do I know if a consultant will deliver software or just a deck?
Ask what exists in month four. If the answer is a presentation, you are buying analysis, which is sometimes right but should be priced as analysis. If the answer is a system in production with a named owner inside your building, ask to see the acceptance criteria and handover clauses in writing before signing.
Who inside the dealership should own the engagement?
Someone with operational authority and allocated time, usually the GM or the group operations lead, plus the manager of the department the system touches. Engagements where no internal person has hours assigned to the project stall at every decision point and collapse at handover, regardless of how good the consultant is.
Should payment be tied to results?
Rarely, in retail automotive. Outcome-based pricing requires a metric that is clean, attributable and auditable, and attribution is already the hardest measurement problem most dealerships have. Contracts that depend on attributing a sales lift to one system usually produce a dispute rather than an outcome.
What happens to the work if we end the engagement early?
That depends entirely on whether the exit terms were written at the start. A scope with handover and exit clauses means you keep the specification, the code written so far, the credentials and the runbook. Without those clauses, ending early typically means you keep the invoices and nothing else.
Conclusion
- The risk of the engagement lives in the scope of work, and it is readable before you sign anything.
- Seven clauses. Problem as a number, systems by name, escalation behaviour, data and compliance, acceptance criteria, handover, exit terms. Four are usually missing.
- Price the assessment cheaply and separately. Its job is to tell you whether a project exists, and sometimes the right answer is that it does not.
- Baseline before go-live or the result will be unarguable in both directions.
- A named internal owner is not a formality. It is the difference between a system and an orphan.
Last updated: