Ask
Can the product do what the dealership requires?
DEALERSHIP CRM EVALUATION RESOURCE
A dealership CRM demo checklist you can actually use
A polished CRM demo can make almost anything look easy. Your dealership needs to know what will work with your people, your data, your other systems, and your actual store workflows.
Use this checklist with every finalist. Ask the same questions, run the same scenarios, and record what each vendor proves.
Direct XLSX download. No form or email required.
THE METHOD
Five prompts for every requirement.
Show Me
Can the vendor demonstrate it using a realistic dealership workflow?
Prove It
What evidence shows it will work with your data, systems, and rules?
Who Owns It?
Who configures, delivers, supports, and pays for each part?
What Happens When It Breaks?
How is a failure detected, corrected, and explained to the dealership?
A verbal 'yes' is an answer to Ask. It is not automatically evidence for the other four prompts.
The checklist tells you what to evaluate. The scenarios tell you how to test it.
Use the checklist as your question bank. Use the five scenarios as live tests with every finalist.
BEFORE THE DEMO
Prepare the team and the requirements.
Bring store leadership, daily CRM users, implementation owners, and IT. Include someone who can speak for each rooftop if the stores operate differently.
Write down your Must Have requirements first. List the systems the CRM must exchange information with, the workflows you expect to preserve or improve, and known data or process problems. Give every vendor the same scenarios.
Agree on who will record answers and evidence. When a vendor cannot show something, mark it Not Yet Verified and assign a follow-up. Do not quietly change the requirement to fit what the vendor showed.
STEVE’S TAKE
Corporate IT knows the architecture, standards, security requirements, and group strategy. Local IT knows the connectivity, network limitations, equipment, configuration, and vendor hardware in the actual building. A design that looks right at the group level can stumble at the rooftop if nobody asks how that store operates.
THE QUESTION BANK
What to evaluate.
Mark the priority that fits your dealership. Ask for a live demonstration wherever the item matters to your decision.
Customer and lead workflow
Lead arrival and assignment
Show how a lead enters the CRM, how ownership is assigned, and what happens when the expected assignment fails. Can the store see where the lead came from and when it arrived?
Customer timeline
Open one customer record and follow calls, texts, emails, appointments, notes, tasks, and sales activity in order. What is missing, delayed, or stored somewhere else?
Follow-up and task rules
Show who receives the next task, when it is due, and what happens when the assigned person is unavailable or a task is overdue. Can a manager see and correct exceptions?
Appointments and handoffs
Move a customer from inquiry to appointment to showroom handoff. Show how the receiving person knows what has already happened and what is expected next.
Communications and consent
Show how communication preferences, opt-outs, and channel restrictions affect both manual outreach and scheduled automation. What happens to messages already queued?
Customer identity and duplicates
Create customers with similar names. Show matching, duplicate warnings, merge permissions, and how a mistaken merge is corrected. What prevents one customer’s activity from appearing on another customer’s record?
Vehicle and household relationships
Show how vehicles, trade-ins, service history, household members, and separate buyers relate to a customer record without collapsing distinct people into one identity.
Manager visibility and escalation
Show how a manager finds missed leads, aging tasks, appointment problems, and unusual activity. Can the manager act on the problem from the same view?
STEVE’S TAKE
Follow the message. A communications feature is useful only if the store can see who was contacted, through which channel, under which rule, and what happens when that rule changes.
Connected systems and data
DMS data exchange
Identify which DMS data moves in each direction, how often it moves, and which system is authoritative for each field. Demonstrate a real record, not just a connection diagram.
Website, inventory, and lead sources
Show how leads and context arrive from the dealership website, inventory tools, and third-party sources. What happens to campaign, vehicle, and customer details along the way?
Other vendor integrations
For each required integration, name the vendor, the data exchanged, the delivery method, the cost, and the support owner. Is the capability available today in the proposed package?
Data mapping and exceptions
Show where field mappings live and how missing, mismatched, duplicate, or rejected values are surfaced. Who can fix an exception, and how does the dealer know it was fixed?
Integration monitoring and recovery
Show the difference between a successful technical transmission and a correct business result. How are failures detected, retried, reconciled, and escalated?
APIs and access to data
Identify the APIs, exports, permissions, rate or access limits, and partner approvals needed for current and likely future use. Who controls access, and what changes if a vendor relationship ends?
STEVE’S TAKE
A system can report a successful connection while the wrong data lands in the wrong place, arrives too late, or triggers the wrong action. Test working as required, not merely connected.
Store operations and oversight
Multi-rooftop operations
Show shared and store-specific customer views, permissions, routing, reporting, and handoffs. Where can one rooftop see or change another rooftop’s data?
Roles and permissions
Demonstrate access for a salesperson, manager, administrator, group user, and outside partner. Can permissions match real responsibilities without giving people unnecessary access?
Reporting and definitions
Build or open the reports the dealership actually uses. Agree on definitions for leads, response time, appointments, sold customers, and other critical measures. Can users trace a number back to its source?
Audit trail and corrections
Show who changed a record, when, and what changed. If data or an automated action is wrong, can the dealership correct it and retain a usable history of the correction?
Security and data handling
Confirm how access is managed, how sensitive data is handled, what the dealer can export, and how security responsibilities are divided. Send policy or contractual questions to the dealership’s appropriate reviewers.
AI and automation behavior
Show where AI or automation acts, what information it uses, what a person can review or override, and how errors are found. Test ambiguous records and changing customer preferences, not only the vendor’s ideal example.
Delivery and long-term ownership
Migration and history
Identify what comes over, what stays behind, what changes format, and what must be validated. Test sample records, attachments, activities, ownership, and duplicate handling before committing to a cutover plan.
Implementation and training
Get a plan with milestones, dealership responsibilities, training by role, acceptance criteria, and the work required before go-live. Which parts depend on another vendor or the dealership?
Support and failure ownership
Walk through a problem that crosses two vendors. Who receives the first call, who diagnoses it, who communicates with the store, and who stays responsible until the business problem is resolved?
Commercial and roadmap commitments
Tie required capabilities to the proposed package, statement of work, partner agreements, and pricing. Record exceptions and get important commitments in writing. A roadmap slide is not a current capability.
STEVE’S TAKE
“We migrate the data” does not tell you whether your people will find the right history on the right customer after go-live. Ask to inspect representative records before calling migration complete.
STEVE’S TAKE
“Implementation will handle it” is not enough. An implementation team can configure and deploy what the product supports. It cannot turn a product limitation into a feature. Separate configuration, custom development, partner work, and unsupported requests—and name who owns each one.
THE LIVE TESTS
Run the same five scenarios with every finalist.
Give each vendor the starting conditions and expected steps. Ask them to use the proposed product and integrations. Record what they show live, what they explain verbally, and what still needs dealer testing or written confirmation.
A
The 15-minute customer journey
- Start
- An existing service customer submits a new website lead about a specific vehicle using changed contact information, such as a different phone number or email address.
- Run it
- Follow lead arrival, the customer identity and matching decision, assignment, the lead-response clock, salesperson contact, the customer’s text response, appointment, showroom handoff, digital-retail information where applicable, and desking / first pencil. Change something meaningful in the deal—vehicle, trade, terms, or salesperson—complete the sale, and have a manager reconstruct the customer history and reported outcome.
- Look for
- Correct matching, duplicate prevention, preserved history, visible timing, clear ownership, communications history, a clean digital-to-showroom handoff, what carries into desking, what must be re-entered, and whether reporting reflects what happened.
- Customer journey
- SERVICE HISTORY → NEW SALES LEAD → COMMUNICATIONS → APPOINTMENT → SHOWROOM → DESKING / FIRST PENCIL → SALE → MANAGEMENT REVIEW
B
Integration says success, but the result is wrong
- Start
- A connected system reports a successful transmission, but a field is mapped incorrectly, a record arrives late, or the business result is wrong.
- Run it
- Trace the source record through the integration to the CRM. Show the error, monitoring, notification, correction, retry or reconciliation, and final customer record.
- Look for
- Evidence that the dealership can detect and fix an incorrect result even when the connection itself says “success.” Test working as required, not merely connected.
C
Same name, different customer
- Start
- Create two separate customers named Juan Rodriguez. Give them different contact information, vehicles, and histories.
- Run it
- Search, match, import or update, communicate, and apply any relevant automation or AI behavior. Ask what could cause the records to merge or a message to go to the wrong person. Then show the correction and audit path.
- Look for
- Two distinct identities throughout the workflow, sensible duplicate controls, and a recoverable path if someone makes a mistake.
D
Opt-out with queued follow-up
- Start
- A customer has an automated message queued, then opts out before the message is sent.
- Run it
- Change the preference. Show what happens to the queued message, any related tasks, the customer timeline, and the user or manager view.
- Look for
- The rule applying at the right time across the channels and tools involved, plus a clear record of what was stopped or sent.
E
Multi-rooftop customer and handoff
- Start
- A customer interacts with one rooftop, then contacts another store in the group.
- Run it
- Show identity matching, store ownership, permissions, communications history, routing, reporting, and the handoff between people or rooftops.
- Look for
- The right shared context without unintended access, duplicate outreach, lost ownership, or misleading store-level reporting.
THE EVIDENCE
Record what was proved.
Use the same workbook for all finalists. No email address is required.
Record each requirement’s priority, result, evidence, delivery method, owner, failure path, and open questions. Keep a verbal claim separate from a live demonstration, dealer test, document, or written commitment.
Pass means the requirement was supported with evidence appropriate to its importance. Concern means there is a material condition, dependency, or unanswered question. Fail means it does not meet the agreed requirement. Use Not Yet Verified when the answer is incomplete.
A roadmap slide is not a current capability. Do not quietly change the requirement to fit what the vendor showed.
THE DECISION RECORD
Resolve the unanswered questions.
After each demo, list what the vendor demonstrated, what it only claimed, what remains unknown, who owns each dependency, and what must be resolved before signing. Assign an owner and due date to every important follow-up.
The useful output is a decision record, not a score that picks a winner for you. Review the Must Have items, unresolved integration and implementation risks, commercial exceptions, and commitments with the people who will live with the decision.
For the wider technology context, see Automotive Technology Consulting. Learn more About Steve. If AI or product capabilities are central, see Product, AI & Technology Consulting.
INDEPENDENT CRM ADVICE
Need another set of eyes on your CRM decision?
I can help your team separate what is proven from what still needs testing before you commit.