Dealer Management System Requirements Checklist

Work out what your store actually requires before a vendor tells you. The list is shorter and more specific than most dealers expect.

Most dealership requirements lists are written by copying a vendor's feature page and adding a few things somebody remembers wanting. That produces a document every vendor can answer yes to, which is worse than no document at all, because it gives false confidence to a decision that has not actually been made.

Start somewhere less comfortable. Spend a week collecting what breaks. Ask the controller which month end tasks take longest and why. Ask a finance manager which deal types require a workaround. Ask a service advisor what they do twice because the system will not do it once. Ask a parts manager which report they rebuild in a spreadsheet every month. Write down the actual answers, not summaries of them.

You will end up with thirty or forty specific complaints. Some are system limitations, some are configuration nobody ever fixed, and some are process problems that will follow you to any new system. Sorting them into those three buckets is the single most valuable hour in the whole project, because the third bucket is the reason stores switch systems and remain unhappy.

Only then start writing requirements, and write them as tasks. Not payroll module, but process a payroll run for a hundred and forty employees across three entities with commission plans that change monthly. The second version is something a vendor has to demonstrate.

Requirements scale, and buying for a store you hope to be rather than the store you are is an expensive habit in both directions.

Write down the numbers. Rooftops and whether they are separate legal entities. Franchise points by manufacturer and any independent operations. New and used units per month. Repair orders per month and technician count. Parts inventory value and monthly parts sales. Total headcount and, separately, the number of people who need a login, since those are different numbers and vendors price against the second.

Then write down where you expect to be in three years. If an acquisition is realistic, multi entity consolidation moves from nice to have into must have, and discovering that after you sign is expensive. If you are shrinking, do not buy enterprise capability that will sit unused.

Size the technical side too. Number of workstations and where they are, printers by type and what they print, tablet or phone use in service and sales, and internet connectivity at each rooftop including what happens when it fails. A system that assumes reliable connectivity is a different risk in a store on a single circuit than in one with redundancy.

These numbers go straight into the RFP document and they change the pricing you are quoted, so getting them right early saves a round of revisions.

Accounting is where a dealer management system earns or loses its reputation, and it is the department least able to work around a shortfall.

Requirements to specify: general ledger structure with a chart of accounts that matches your manufacturer's statement requirements, factory financial statement production for every franchise you hold, accounts payable with your approval workflow rather than a generic one, accounts receivable including contracts in transit and schedules, bank reconciliation, and payroll either native or through a defined interface to your provider.

Then the automotive specific pieces. Deal posting from the sales system into the ledger, vehicle inventory and floorplan accounting with interest handling, warranty receivable tracking, and internal work between departments. Month end close as a defined process with a stated duration, not an implied one.

If you run multiple entities, be explicit about consolidation, intercompany transactions and whether the chart of accounts can differ by store. This is a common gap and it is the kind that only appears in month two.

Ask about report writing separately from reports. Every store eventually needs a number the standard report set does not produce. Whether that requires a vendor work order or a controller with an afternoon is a real requirement, and it will affect your life every month for as long as you own the system.

Be careful here, because this is where the boundary between the DMS and everything else is blurriest and where stores accidentally buy the same capability twice.

From the DMS specifically, require: deal structure and posting into accounting, the state forms library covering every state you deliver in, form maintenance when a state changes a disclosure, printing to the hardware you actually own, deal jacket imaging with a retrievable index, funding status tracking, product sales and cancellation handling, and the compliance records you must retain and produce.

Write the forms requirement precisely, because it is the most common cause of a delayed go live. Name the states. Name the unusual documents. Name the preprinted multipart stock you use and the printers it runs on. A vendor who says yes to a general forms question and no to a specific printer question has told you something you needed to know before signature.

What you should think twice about requiring from the DMS is desking, lead management, texting and follow up. Those are CRM functions, and DMS bundled versions of them are often the modules a sales floor quietly refuses to use. Evaluate them separately and on their own merits, which is covered in our CRM requirements checklist.

Fixed operations usually generates the longest section of a requirements list, and rightly so, because it is where the transaction volume is.

For service: repair order lifecycle across customer pay, warranty and internal on a single ticket, appointment scheduling against real shop capacity rather than an open calendar, technician time capture and dispatch, shop loading visibility, labor operation catalogs by manufacturer, multi point inspection, warranty claim submission and tracking, and rental or loaner handling if you run a fleet.

For parts: inventory with stocking level management, ordering and returns, special order tracking from order through arrival to installation, counter workflow including cash sales and wholesale accounts, obsolescence reporting, and the interface between parts and service so a technician is not walking to the counter to find out about a backorder.

Write these as scenarios and make vendors run them. A repair order that starts as customer pay, becomes partly warranty after diagnosis, has a part on backorder and gets reassigned to a second technician is the test. Every system handles a clean repair order. The ugly one is what your advisors deal with all day.

Ask what the department does during a system outage and how work is recovered afterward. Stores that never ask discover the answer at the worst possible moment.

List every system that currently exchanges data with your DMS, by name, before you write a single integration requirement. Most stores are surprised by the length of the list once they actually build it.

Typical entries: your CRM, your website provider and inventory feed, third party lead sources, payroll, service scheduling, an equity or marketing tool, phone and texting systems, credit reporting, payment processing, and a menu or aftermarket product provider. For each, write what data moves, in which direction, and how often.

Then, per integration, require an answer to four questions. Is it native, a certified partner connection, or something we build? What does it cost, one time and recurring? Who maintains it when either side pushes an update? What is the process and the response commitment when it breaks?

Integration fees are among the most reliably underestimated costs in a DMS change, and they are recurring rather than one time. Our total cost of ownership and hidden costs pages cover the ones that never appear on a proposal.

Data requirements belong here too. What can be exported, in what format, whether document images and their index are included, and whether export is available on demand during the term. Put it in the requirements list so it gets answered before contract talks, not during them. See DMS data ownership.

This section used to be an afterthought. It should not be, both because dealerships hold a great deal of sensitive personal and financial data and because the obligations around it have tightened.

Require role based permissions granular enough to match your actual structure, so a service advisor does not see sales gross and a porter does not see customer credit data. Require audit trails that record who viewed and who changed what, and require that those logs are retrievable by you rather than only by the vendor. Require multi factor authentication and a defined process for removing access the day an employee leaves, which is where most stores are genuinely exposed.

Ask what certifications or independent audit reports the vendor can supply and how recent they are. Ask who on the vendor side can access your data, how that access is logged, and what the incident notification process and timeline look like.

Require record retention behavior that matches your obligations, and require that retained records remain producible in a usable format. Ask your own counsel what those obligations are for your state and your operations, then hold the vendor to that answer rather than to a general reassurance.

A requirements list where everything is required is a list that cannot help you choose. Force the ranking before the demos, while nobody is emotionally attached to a vendor.

Use three tiers and be disciplined. Must have means we cannot operate without it and we will not sign with a vendor that lacks it. Should have means significant value, and its absence costs real money or hours we can quantify. Nice to have means we would enjoy it and it breaks a tie.

The test for the top tier is simple. If a requirement is genuinely a must have, you are prepared to eliminate an otherwise superior vendor over it. If you are not prepared to do that, it belongs in the second tier. Most stores start with forty must haves and finish with eight, and the eight are the ones that actually decide the outcome.

Get the ranking agreed by the people who will use each department's section, in writing, before the first demo. Requirements that get promoted mid process are almost always requirements someone invented to justify a preference formed in a conference room, and once that starts the evaluation is over. The vendor evaluation scorecard turns the finished ranking into weights you can score against.

Some things are better bought outside the DMS, and knowing which keeps the project smaller and the sales floor happier.

Lead management, messaging, calling, follow up automation, campaign management, landing pages and lead generation are all CRM and marketing functions. Bundling them into the DMS decision means they get chosen by the people who care most about accounting, which is how stores end up with a sales tool nobody opens. Evaluate them separately, on their own criteria, with the sales floor in the room.

That is where we sit, so we should say it plainly. LeadLocate is not a dealer management system. No general ledger, no accounts payable or receivable, no payroll, no deal posting to accounting, no parts, no repair orders, no service scheduling and no title work. We are the lead generation and CRM layer that runs alongside whatever DMS you choose, and neither a DMS integration nor an inventory feed is required for it to operate.

That independence is worth something during a DMS project, because the sales and follow up side keeps running while accounting is being rebuilt underneath it. If you do want the two connected once you are settled, DMS and CRM integration covers the options. Pricing is on the pricing page, month to month, and you can contact us if you would rather just ask what fits.

How do we write requirements a vendor cannot just agree to?

Write them as tasks a named person performs, with the numbers attached. Not payroll module, but run payroll for a hundred and forty employees across three entities with commission plans that change monthly. Then make them demonstrate it in their system.

How many must have requirements should we end up with?

Usually under ten. The test is whether you would eliminate an otherwise superior vendor over it. If not, it is a should have. Stores that keep forty must haves cannot use the list to decide anything.

Which requirement is most often missed?

Forms and printing specifics for F&I, and the export of scanned document images with the index that maps them to deals. Both are discovered late and both are painful, because they surface after the contract is signed.

Should CRM requirements go in the DMS list?

No. Keep them separate. Lead management, messaging, follow up automation and campaigns get evaluated on different criteria by different people, and bundling them means the sales floor inherits a tool it had no say in choosing.

Is LeadLocate a dealer management system?

No. There is no accounting, parts, service, title or registration functionality of any kind. We are the lead generation and CRM layer that runs alongside your DMS, and neither a DMS integration nor an inventory feed is required to operate.

How long should building a requirements list take?

Two to four weeks for a single rooftop, longer for a group. Most of that is collecting what breaks today from the people doing the work, which is the part stores skip and the part that makes the rest of the document useful.

Leads, messaging, calling, follow up and desking run independently of whatever system you choose. No DMS integration required, month to month.