How to Select a DMS: A European Dealer RFP and Scorecard

1. Form the decision team and scope

DMS selection affects sales, used vehicles, workshop, parts, finance, IT, privacy and group reporting. Create a decision team with accountable operational owners, not only representatives. Name one executive sponsor, product owner, data lead, integration lead, security/privacy lead, finance controller and change lead. Define who recommends, who approves and who can reject on a mandatory requirement.

Document legal entities, rooftops, brands, countries, languages, users, transaction volumes and critical periods. Separate current scope from a plausible three-year roadmap. A requirement for every hypothetical future market can distort the decision, while ignoring likely expansion can create another replacement.

2. Convert needs into testable requirements

A requirement should name actor, trigger, data, action, output and acceptance. Replace “strong CRM” with “a web, OEM or phone enquiry is matched or created, consent is recorded, the lead is routed by brand and geography, an owner and SLA are visible, communication is captured, and a completed deal returns status without a duplicate customer.”

Build a country and OEM matrix. For every cell, record accounting, tax, invoice, payment, registration, warranty, parts, campaign, reporting, identity and language requirements. The European context is materially varied. Eurostat's passenger-car data show large differences in fleet age and powertrain by country, while EU rules on privacy, data access and e-invoicing still require local implementation.^[1]

3. Use gates, weighted criteria and evidence levels

Eligibility gates prevent a high total score from hiding a fatal gap. Examples include production support for a required country, named OEM interface, statutory accounting output, data-residency boundary or migration deadline. A failed gate can be resolved only by approved remediation with a date, owner, cost and contractual commitment.

4. Script demonstrations instead of accepting product tours

Provide representative but safe data and fixed scripts. Ask the vendor to show a lead through quote, trade-in and order; a used car through appraisal, inspection, preparation, media, publication, pricing and sale; a repair order through booking, technician work, parts, additional approval and invoice; and a period-close or management-report path.

Add exceptions: duplicate customer, wrong VIN, cancelled deal, unavailable part, failed interface, offline inspection, reversed invoice and user leaving mid-process. Count systems, clicks, rekeyed values, manual exports and invisible background dependencies. Record the version and market demonstrated.

Standards can improve interoperability, but do not substitute for a demonstration. STAR publishes automotive lead, deal and retail-delivery APIs and a retail domain model.^[2] Ask whether and how a vendor implements relevant standards, then test the actual proposed interface.

5. Validate cloud, API, security and data claims

For cloud, identify SaaS, dedicated hosting or hosted legacy architecture. Request availability definitions, incident history, RPO, RTO, backup and recovery test evidence, maintenance rules and capacity model. For APIs, request objects, fields, events, write operations, authentication, sandbox, rate limits, overages, versioning, monitoring and data-export rights.

For privacy and security, assess roles, least privilege, MFA, logging, encryption, vulnerability management, subprocessors, transfer mechanism, retention, deletion, incident notification and independent assurance. GDPR requires risk-appropriate controls and privacy by design, but a certification or cloud provider does not make the dealer automatically compliant.^[3] ENISA guidance can structure evidence requests, although NIS2 scope must be assessed separately.^[4]

6. Apply fair public evidence statuses

Public status is an orientation tool. Procurement evidence may change it. A vendor should be invited to correct factual errors and provide current confidential proof under an appropriate process.

7. Finish with implementation, references and contract

Reference calls should match country, dealer size, OEM complexity and scope. Ask what changed after contract, what required workarounds, what data failed, how long adoption took, how incidents were handled and what the reference would do differently. Do not ask only whether users like the product.

Make acceptance criteria contractual. Cover data completeness and reconciliation, critical workflows, integrations, performance, security, training, cutover and support. Price migration iterations, environments, API usage, messages, storage, report work, travel, indexation and change requests. Define service levels, escalation, exit export, transition support, deletion and retained access to statutory records.