Dealership DMS RFP Template

A request for proposal that vendors cannot answer with a brochure. Structure, wording and the scoring sheet that goes with it.

An RFP is a lot of work, so be honest about whether you need one. A single rooftop replacing an aging system with two realistic candidates usually does better with a structured demo script and a written question list than with a formal procurement process. The paperwork does not improve the decision, it just delays it.

An RFP earns its keep when the decision is genuinely contested. Multiple rooftops, several vendors with different strengths, a group where more than one person has to sign off, or a store that has been burned before and wants commitments in writing rather than in a sales conversation. It also earns its keep when the incumbent is a candidate, because it forces them to compete on paper instead of on the relationship.

The real value of an RFP is not the vendor answers. It is the internal argument you have while writing it. Deciding what you actually require, as opposed to what you currently have, is the hardest part of any system change, and it is much cheaper to argue about it in a conference room than during a conversion.

Send it to no more than four vendors. Give them three to four weeks. Any less and you get boilerplate, any more and the project loses momentum.

Vendors write better proposals when they know the shape of the store, and vague RFPs get vague answers priced defensively high.

State the number of rooftops and their locations, franchise points and any independent operations, approximate new and used volume per month, service repair order count per month, parts operation size, headcount by department, and the number of people who would need a login. Say what you run today and roughly how long you have run it. Say which third party systems currently connect to it, by name.

Then state your timeline honestly, including any date you must avoid. If you have a manufacturer program deadline, a fiscal year end, or an acquisition closing in the spring, put it in the document. Vendors plan implementation capacity months out, and a date discovered late is a date missed.

Finally, say what is driving the change in one paragraph. Cost, capability, service quality, an acquisition, or a contract ending. Vendors will position around it either way, and the ones who position honestly against a stated problem are the ones worth reading. Our page on dealer management system requirements covers how to work out what you actually need before you write this section.

This is the body of the document and the part most stores write too loosely. Write requirements as things a person does, not as feature names, because feature names are easy to answer yes to.

Accounting. General ledger structure and factory statement production, accounts payable and receivable, bank reconciliation, schedules, payroll or the interface to your payroll provider, deal posting, floorplan and vehicle inventory accounting, month end close, and multi entity consolidation if you have more than one store.

Sales and F&I. Desking, deal structure, forms library and form maintenance, printing to your existing hardware, deal jacket imaging, funding tracking, product sales and cancellation handling, and the compliance records you must retain.

Service. Repair order lifecycle across customer pay, warranty and internal, appointment scheduling against capacity, technician time and dispatch, shop loading, labor operations, multi point inspection, warranty claim submission and tracking.

Parts. Inventory, ordering and returns, stocking levels, special order tracking, counter workflow, and the interface to service.

Cross cutting. User roles and permissions, audit trails, reporting and report writing, mobile access, uptime commitments, and what happens during a vendor outage.

Ask each requirement as a question ending in how, not whether. Vendors answer yes to whether. How produces something you can evaluate.

Feature lists converge. These do not, and they are where a proposal stops being marketing.

Which of these capabilities are native, which are a partner product, and which are on a roadmap? Require a date and an owner for anything on a roadmap, and treat undated roadmap items as absent.

What does integration with a named third party cost, who builds it, who maintains it when either side updates, and what is the process when it breaks? Every store underestimates this and every store pays for it later.

What is the release cadence, and can a store defer an update? Who tests releases against dealership workflows before they ship?

How is support structured, what are the hours in our time zone, what is the response commitment by severity, and is that commitment contractual or aspirational? Ask what happens at six on a Saturday, since that is when a store actually breaks.

Ask for three reference stores of similar size and franchise mix, at least one that went live in the past twelve months and one that has been on the system more than five years. Call them yourself and ask what surprised them in month three. Our demo question list carries the same discipline into the meetings that follow.

Put this in the RFP rather than saving it for contract negotiation, because a vendor who answers it badly in writing has told you something important early.

Who owns the data in the system? What is the complete list of what we can export, in what formats, and is any of it charged for? Does the export include document images and the index mapping each image to its deal or repair order? Can we export on demand during the term, or only at the end?

What happens on termination? How long is data retained and accessible, what does read only access cost after the term, and how long does the exit process take from written notice to final delivery?

Who can access our data on the vendor side, how is that logged, and what is the notification process in the event of a security incident? What certifications or audit reports can you supply, and how recent are they?

These questions are covered further in DMS data ownership, and they belong in the RFP for a simple reason. The answers you get before signature are commitments. The answers you get after signature are quotes.

Never accept a proposal priced in the vendor's preferred structure, because no two structures are alike and comparison becomes impossible. Dictate the format and require every respondent to use it.

Then require the five year total as a single number. That one line ends more arguments than the rest of the document combined, because the cheapest monthly figure is very rarely the cheapest five years. Our total cost of ownership page breaks down the costs that never appear on a proposal at all.

Ask directly what the price will be at renewal and what the increase mechanism is. A vendor unwilling to cap escalation in writing has answered the question.

Require a proposed project plan, not a paragraph about partnership. It should name a phase structure with durations, the vendor resources assigned and whether they are dedicated or shared, what the store is expected to supply in hours per week and from which roles, and the data migration approach including exactly what is migrated and what is not.

Ask specifically what is not migrated. Every conversion leaves something behind, and the vendor who tells you what in the proposal is more trustworthy than the one who implies nothing is lost.

On training, ask for hours by role, whether training is on site or remote, whether it happens before or after go live, and what refresher support exists at thirty and ninety days. Adoption is where system changes actually fail, and training scheduled three weeks before go live is training people have forgotten by the time they need it.

Require a named implementation lead and an escalation path with names and titles. Then ask what happens if the go live date slips, and who bears the cost. The answer tells you how much of the plan the vendor believes.

Build the scorecard before the proposals arrive. Scoring after you have read them is how a preferred vendor wins a process that was supposed to be objective.

Weight the categories to match your store. A high volume service operation should not score parts and service the same as a small independent. Typical weighting looks like function by department at around forty percent, five year cost at twenty, implementation and support at twenty, data and exit terms at ten, and vendor stability and references at ten. Score each category one to five against written criteria, with a short written justification per score, and have two or three people score independently before comparing.

Then use the demos to test the scores rather than to be sold. Bring your own scenarios: an ugly repair order, a deal with a trade and negative equity, a month end close, a parts special order that goes wrong. Insist the vendor drive your scenario in their system rather than presenting their script. Our vendor evaluation scorecard covers the mechanics in detail.

Score again after the demos. Movement between the paper score and the demo score is information: it usually means the proposal was written by a team that does not use the product.

One structural note, and it is where we should declare our own position.

Do not bundle your CRM and lead generation requirements into the DMS RFP. They are evaluated on different criteria, on a different timeline, and by different people, and bundling them means the CRM decision gets made as a footnote to an accounting decision. Stores that bundle usually end up with a CRM their sales floor does not use, which costs more than any line on the DMS proposal. Run a separate process with the CRM RFP template instead.

LeadLocate does not sell a dealer management system. There is no general ledger, no accounts payable, no deal posting to accounting, no parts, no repair orders and no title work. We are the lead generation and CRM layer that sits alongside whatever DMS you choose, and neither a DMS integration nor an inventory feed is required for us to operate. That independence is worth something during a conversion, because your sales and follow up side keeps running while accounting is being replaced, which is covered in the F&I switching checklist.

If you want to see what that layer includes while your DMS project runs, pricing is on the pricing page and you can contact us at any point.

How many vendors should get the RFP?

Three or four. Fewer and you have no comparison, more and the evaluation collapses under its own weight. Include the incumbent if they are a genuine candidate, because it forces them to compete on paper instead of on the relationship.

How long should vendors have to respond?

Three to four weeks. Shorter windows produce boilerplate. Longer ones let the project lose momentum and let internal consensus drift before the answers arrive.

What is the single most important question in the document?

What can we export, in what format, and what does it cost. It is answered honestly before signature and expensively afterward, and it determines whether the next change of system is a project or a hostage situation.

Should the CRM be part of the DMS RFP?

No. Run it separately. Bundled, the CRM gets chosen as a footnote to an accounting decision and the sales floor ends up with software it will not use. Different criteria, different timeline, different evaluators.

Does LeadLocate respond to DMS RFPs?

No, because we do not sell a dealer management system. We provide the lead generation and CRM layer that runs alongside one, with no DMS integration or inventory feed required. We are happy to be evaluated on that basis.

How do we compare pricing when every proposal looks different?

Dictate the format. Require one time, recurring, per module, per integration and transactional lines separately, plus a capped escalation figure and a five year total. That last number ends most arguments, because the cheapest month is rarely the cheapest five years.

The CRM and lead layer runs independently of whatever system you pick. No DMS integration required, month to month, no long term contract.