Automotive CRM Requirements Checklist

Decide what you need before anybody shows you what they have. Requirements written as scenarios, sorted by what actually costs you money.

Here is the method, and it is the only part of this page that really matters. Do not write "must have texting." Write "a customer replies to a salesperson's text at 8pm on Sunday about a specific stock number, that salesperson is off, and a manager needs to see it and answer within ten minutes."

The difference is enormous. Every CRM in the market can answer yes to the first. The second forces a vendor to walk through routing, notifications, permissions, mobile access and threading in one breath, and you can watch which parts they hesitate on.

Build twelve to twenty of these, drawn from things that actually went wrong in your store in the last ninety days. Not hypotheticals. Real events, with the details intact, because the details are what expose a gap. The lead that arrived at 6:40pm on a Friday. The customer who called the main line and got transferred three times. The trade appraisal that lived in somebody's text messages and vanished when they left.

Once written, those scenarios become your demo script, your RFP source material, and later your acceptance test after go live. Most stores do this backward and end up with a requirements document that describes whichever product they saw last. The CRM RFP template is the document you send once this list exists.

Every requirements list starts out as thirty must haves, which means it has no must haves at all. Use one test to sort it: does the store lose money this month without it, or would it merely be pleasant.

A capability is a must have if you can name the specific loss. Leads sitting unassigned overnight costs deals, and you can point at the ones from last month. Round robin distribution that skips people who are at capacity is a must have if you have watched leads pile onto one person while others sat idle. A prettier dashboard is not a must have, however much you would enjoy it.

Three categories deserve a hard look, because they get promoted to must have status without justification. Deep integration with the dealer management system you run is often assumed rather than needed; write down exactly which fields have to move, in which direction, and how often, and the requirement usually shrinks. Mobile apps get demanded and then unused; specify what a salesperson must be able to do from a phone rather than asking for an app. And custom reporting frequently means five reports, which is a very different requirement from a report builder.

Aim to end with no more than eight must haves. If everything is required, nothing gets weighted, and the decision gets made on demo polish.

This section decides more of your outcome than any other, because a CRM that mishandles leads costs money every day regardless of what else it does well.

Requirements worth writing as scenarios: a lead arrives from a source you have not configured yet and must still land somewhere visible rather than bouncing. A duplicate arrives for a customer who already exists and must attach to the existing record rather than creating a second one. A lead arrives for a salesperson who is off today, or has left the store, and must reassign automatically. A lead sits untouched for fifteen minutes and somebody must be told without a manager watching a screen.

Then the rules themselves. Can routing consider source, vehicle, territory, time of day and user availability at the same time. Can a manager reassign in bulk after a schedule change. Does the system respect a per person cap or keep dealing regardless.

Write down where the response clock starts, because vendors will quote whichever definition flatters them. Time from lead arrival is the honest measure. Time from assignment hides the queue. Insist on the first.

Finally, specify what happens with no human involved at all in the first sixty seconds, since that is where most of your response time advantage is won or lost.

Write one requirement that does more work than a page of feature lines: every communication channel we use must be inside the system, on one bill, with history on one customer record.

Then enumerate what you need. Two way SMS and MMS with threaded history that survives a six month gap. RCS messaging for richer branded messages, with automatic SMS fallback so handsets that do not support it are not excluded. Click to call with a real softphone rather than a click that rings your desk phone first. Call recording, and specifically transcription to text, because nobody in your store will listen to recordings but a manager will read a transcript. Voicemail drop for outbound waves. Inbound call routing and IVR so calls reach the right department. Email with a genuine inbox and composer inside the CRM. Bulk email with recipient management and unsubscribe handling. Live chat on your website. Email domain authentication so your sending reputation survives.

Two requirements most stores never think to write. An email validator and a phone validator, so a campaign against an aging database does not damage your deliverability or waste an afternoon of dialing. And opt out propagation across every channel and campaign from a single customer record, which is a compliance requirement rather than a convenience.

Write the scenario for the handoff too: a customer who has been texting a salesperson calls the main line, and whoever answers must see the thread. That single scenario separates integrated platforms from assembled ones faster than any question you can ask.

The requirement to write here is about who can change things, not about whether automation exists.

Can a sales manager create or edit a follow up process without opening a vendor ticket, and how long does a change take to reach the floor. If the answer involves a support queue, every process improvement you plan for the next three years just got a lead time attached to it.

Then the behavior requirements. A cadence must stop automatically when a customer replies, because a sequence that keeps firing after a real conversation started makes your store look careless. Tasks must be assigned to a person with a due time, and an overdue task must escalate rather than aging quietly. Drip campaigns must be editable and must differ by lead type, since an inbound buyer inquiry and a seller offer request need nothing alike.

Include appointments and reminders explicitly. Write the scenario where an appointment is set for Saturday, confirmed by text on Friday, and the status is updated when the customer arrives, because show rate reporting is only as honest as that last step.

Then one uncomfortable requirement worth stating openly: the tools must be good enough that salespeople stop working customers from personal phones. No feature achieves that alone, but a system where texting and calling are slower than a personal handset guarantees the opposite. Task automation covers this layer in detail.

Be specific here, because desking is where feature grids hide the most.

Loan and lease both, not one. Tax handled correctly in every state you sell in, including how trade in credit caps apply where a state limits them, and more than one lease tax method where that matters. Payment frequencies beyond monthly, including semimonthly and biweekly, if your market uses them. A fifty state tax matrix that somebody maintains when a state changes its rules, which is a maintenance requirement rather than a feature.

Then the customer side, which is where a lot of stores are still emailing screenshots. Can the customer be sent a deal page they can open on a phone, see the numbers, and sign electronically. Is the signing recorded in a way you could produce later. Do print templates match what your store actually hands people, and can a deal jacket hold the paperwork against the record.

Write a scenario using a real deal from last month, including a trade with a payoff and a state you actually sell into, and require the vendor to build it live in front of you rather than showing their own clean example. Ugly deals expose engines. Clean ones prove nothing. Our desking tool page shows what those answers look like when the engine is built in house rather than licensed.

Write requirements as questions your general manager asks on a Monday, then check whether the system answers them without somebody rebuilding a spreadsheet.

Which source produced sold units last month, through to delivery rather than to lead count. What our response time distribution looks like, not the average, because averages hide the twelve hour outliers that lost the deal. Which salespeople are working their assigned leads and which are cherry picking. How many appointments were set, how many showed, how many sold. What is happening across rooftops if you have more than one.

Require reports as attachments during evaluation rather than screenshots in a deck. A vendor who cannot email you a populated example report has told you something.

On attribution, write the hardest scenario you have: a customer calls a tracked number from a campaign page, does not buy, walks in three weeks later, and gets written as a walk in. Require an answer about how those connect. If the answer depends on a salesperson remembering, your attribution is manual and you should price your own time into the decision. Reporting dashboards covers what good looks like here.

Short list, high consequence, and the section most often skipped when a store is excited about a demo.

Role based permissions specific enough that a service advisor does not see gross and a salesperson does not see the whole customer database. A login log and an audit trail of who viewed and exported what, because the most common data loss at a dealership is a departing employee taking a customer list. Encryption of customer personal information at rest. Consent records showing when and how a customer agreed to be contacted, retrievable if a complaint arrives. Blacklist and do not contact handling that can be imported in bulk and applies across every channel automatically.

Then the exit, which belongs in your requirements rather than in a panicked conversation three years from now. Exactly what you can export, in what format, whether communication history comes with it or only contact records, what it costs, how long it takes, and how long after cancellation you can still ask. Require the answers in the contract.

Add one requirement about the change itself: the vendor must support running in parallel with your current system for a defined overlap period. Cutting over with no overlap is the most reliable way to lose leads during a transition. The CRM migration checklist sequences that work.

Weight the sections by your own pain before you look at a single vendor. If speed to lead is what hurts, capture and routing carries the heaviest weight and a beautiful reporting suite does not rescue a weak answer there. Weighting after the demos is how a decision gets rationalized rather than made.

Score written answers first, in isolation, then demo only the top three. In the demo, verify the scenarios you wrote instead of watching a presentation. Hand them your list and ask them to perform it.

For reference, here is where we sit against the categories above. LeadLocate is a lead generation platform with a full CRM built in: lead inbox with distribution rules, SMS, MMS and RCS with SMS fallback, VoIP softphone with call recording and transcription, voicemail drop, IVR and call routing, email inbox and composer, bulk email, an email validator and a phone validator, automations and follow up processes, drip campaigns with an editor, appointments and reminders, lead pages, salesperson websites, live chat, desking across loan and lease with a fifty state tax matrix, customer deal pages with e-signature, role based permissions with a login log, and three reporting layers. We are not an OEM certified CRM and we do not sell a dealer management system.

Neither DMS access nor an inventory feed is required to operate, which is why individual salespeople and brokers run on the same platform a group does. Month to month, no long term contract, US only, with pricing published on the pricing page rather than hidden behind a quote request.

How many requirements should the list contain?

Twelve to twenty scenarios, of which no more than eight are true must haves. A list where everything is required cannot be weighted, and an unweighted list means the decision gets made on demo polish instead of fit.

Why write scenarios instead of features?

Because every vendor answers yes to a feature name. A scenario forces them to walk through routing, permissions, notifications and threading at once, and you can see which part they hesitate on. It also becomes your acceptance test after go live.

Is DMS integration a real requirement?

Sometimes, and less often than assumed. Write down exactly which fields must move, in which direction and how often, and the requirement usually shrinks. Our platform does not require DMS access or an inventory feed to operate at all.

What do stores most often leave off the list?

Opt out propagation across every channel, an audit trail of who exported what, consent records you could produce if questioned, and the export terms for leaving. All four are cheap to require up front and expensive to discover you lack.

Should the checklist include price?

Include total monthly cost at your real seat count with every module you need, plus the renewal price, because introductory pricing that steps up in year two is normal. Price is a comparison input, not a requirement, so keep it out of the scored fit sections.

How do we test a vendor against the list?

Hand them the scenarios and ask them to perform each one live using a real deal or lead from your own store. Bring an ugly example with a trade and a payoff. Clean demo data proves nothing about how the system behaves on a Friday evening.

Send the list, or read it to us on the phone, and we will show you each one working in the actual system rather than in a slide. Call 844-376-2274.