Multi-Rooftop Dealer Group Standardisation Without Erasing Local Reality

1. Why multi-rooftop groups drift

Dealer groups grow through new sites, brands, countries and acquisitions. Each site brings history, local expertise, legacy systems and workarounds. Over time, the same words mean different things. One branch marks a vehicle retail-ready after photography, another after mechanical preparation. One CRM stage means a contacted lead, another means any automated response. Management receives a common dashboard built from uncommon processes.

Some variation is legitimate. Accounting, VAT, invoicing, registration, consumer rights, language, OEM warranty and parts interfaces differ. Fleet composition also varies substantially across Europe. Eurostat reports material country differences in vehicle age and powertrain, while ACEA reports 256 million cars on EU roads in 2024.^[1] Standardisation must preserve necessary local operating reality.

2. Build a layered standard

The group core defines customer, vehicle, lead, stock, repair and financial semantics, mandatory controls and KPI formulas. The country layer contains legal and fiscal requirements. The OEM layer contains brand interfaces and mandated process. The rooftop layer covers approved capacity or organisational differences. The role layer controls tasks, views and access.

This model prevents local necessity from contaminating the group core while avoiding a central template that cannot operate in practice. Every field and rule should have an owner and layer.

3. Standardise the business objects

Start with identifiers and lifecycle states. Define how customers are matched, what a household or company means, how consent is represented and how duplicates are resolved. Define vehicle identity, specification source, location, ownership, availability, retail-readiness and ageing start. Define lead source, assigned, contacted, qualified, appointment, won and lost. Define repair-order status, technician time, parts reservation, approval and invoice completion.

A common semantic model also improves integration. STAR's automotive retail domain model aims to provide shared semantics across DMS, OEM and third-party applications.^[2] It is not a complete European implementation blueprint, but it illustrates why consistent business objects matter more than moving flat files.

4. Choose core workflows and control points

Standardise high-value journeys, not every click. For sales, define capture, assignment, response, qualification, test drive, quote, trade-in, approval, order and delivery. For used cars, define acquisition, inspection, refurbishment, media, publication, pricing, stock action and handover. For workshop, define booking, reception, diagnosis, parts, additional work, approval, completion and invoice.

Specify mandatory control points: identity and consent, vehicle evidence, purchase approval, price exception, discount authority, parts issue, additional-work approval, segregation of duties and invoice correction. Local teams may arrange work around them, but cannot silently remove them.

Privacy by design requires purpose-based access and default limitation.^[3] A shared group customer record does not mean every user can see every interaction. Use role, legal entity, brand, location and purpose to control access, with auditable exceptional access.

5. Govern variants and exceptions

Create an exception register with requestor, owner, reason, evidence, affected layer, users, control impact, data impact, cost, start date and review date. Classify each as required by law, required by OEM, temporary transition or approved commercial differentiation. A preference is not a permanent exception.

Use a design authority with operations, product, data, finance and security representation. It should publish decisions and reusable patterns. When one country solves a problem, assess whether the group core should evolve. When an OEM requirement expires, retire the variant.

6. Make performance comparable

Define KPI numerator, denominator, event time, exclusions, owner and refresh. A lead-response dashboard must distinguish automated acknowledgement from useful response. Stock age needs one start event. Workshop utilisation needs agreed available hours. Margin needs consistent treatment of preparation, bonuses, finance, warranty and overhead.

Compare process conformance before business outcomes. If one rooftop does not record loss reasons or technician time, its apparent performance may be a data-quality effect. Track completion, exception and override rates alongside commercial KPIs. Eurostat's motor-trade turnover metadata demonstrates why even a common term such as turnover needs a precise definition and VAT treatment.^[4]

7. Roll out through a repeatable operating product

Treat the group template as a product with version, release notes, owner, backlog and adoption measures. Pilot at a representative rooftop, correct the core, then deploy in waves. Separate configuration that can be reused from one-off migration and local change work.

Prepare role-based training, local champions, support escalation and data-quality dashboards. Measure adoption of required workflows and the rate of unofficial workarounds. A rollout is not complete when users can log in. It is complete when critical processes and controls are stable and management data is trustworthy.

90-day starting plan

1. Map the five highest-value cross-rooftop journeys and current variants.
2. Publish definitions for ten critical objects and KPIs.
3. Create the configuration-layer model and exception register.
4. Measure data quality and process conformance by rooftop.
5. Select one representative pilot and define acceptance evidence.
6. Establish the design authority and template release process.

This produces value before a full platform rollout because it makes decisions, comparisons and migration requirements clearer.