CASE DOSSIER · MULTI-BRAND AUTOMOTIVE
A dealership group that sells GAC, run as a single system.
Four brands, several locations, warranties checked by hand, and leads lost between WhatsApp and Excel. We understood it end to end and rebuilt it into four role-based portals, a warranty engine that evaluates itself, and a pipeline synced to Kommo.
01 · The process before
The multi-brand disorder was not a lack of people. It was the lack of a system that understood the process.
- ✕Each brand (GAC, DFSK, BERA, EMPIRE) was run on its own spreadsheet, its own criteria, and its own WhatsApp.
- ✕Warranties were checked by hand: someone cross-referenced mileage, months, and services to decide whether one was still valid.
- ✕Leads arrived over WhatsApp and were copied into Excel; many went cold before a salesperson saw them.
- ✕Service bookings were written down without knowing which bay was free or how long each type of service takes.
- ✕The customer had no way to see their vehicles, their history, or their warranty status without calling.
- →A single multi-brand platform: each dealership sees its own, the group sees everything.
- →The warranty engine evaluates itself in cascade (model → group-wide) and returns the status immediately.
- →The lead is captured once and moves through the pipeline, synced both ways with Kommo.
- →Bookings on real slots per bay and service type, with no Sundays and no lunch hour.
- →Four role-based portals: the customer enters their license plate and sees their vehicles and warranties without calling anyone.
02 · How we understood the process
Before writing code, we mapped how a multi-brand dealership group actually works.
Each brand brings its own context
GAC, DFSK, BERA, and EMPIRE share neither models nor warranties. The system had to be multi-brand at its root, not a table with a "brand" field.
The warranty is a rule, not a PDF
Validity = mileage + months + services. If it is a rule, the software can evaluate it on its own; nobody should cross-check it by hand.
Each role needs its own door
The manager, the salesperson, and the customer neither enter the same way nor see the same thing. Three login methods for three real contexts of use.
The lead already lived in Kommo
The point was not to replace Kommo but to keep it synced both ways so nobody copies and pastes.
03 · The optimized flow we built
Five chained steps, with no manual jumps between them.
- 01Single lead capture (WhatsApp / web / XLSX) with the phone number normalized to +58.
- 02Stage-based pipeline in the salesperson portal, synced with Kommo both ways.
- 03Service booking against real slots per bay and service type.
- 04Warranty engine that evaluates itself in cascade (model → group-wide) per VIN.
- 05Communication with WhatsApp templates assembled from the customer’s actual status.
04 · What we built · The dossier of the 4 portals
One single database. Four experiences depending on who signs in.
Select a portal to see its scope, its login method, and the modules it received.
Superadmin
Group / leadership
- Login method
- Email + password
- Data scope
- Sees and configures the whole group: the 4 brands and every location.
Multi-brand dealerships
Creating locations and assigning brands (GAC · DFSK · BERA · EMPIRE) per dealership.
Models and per-model warranty
Defines the warranty per model with a fallback to a group-wide policy.
Configurable dashboards
Assembles the widgets each dealership and each role will see.
WhatsApp template catalog
Templates with variables and conditional blocks, reusable across every location.
04 · The self-evaluating warranty engine
Nobody decides by hand whether a warranty is still alive. The system resolves it on its own.
Move the controls: mileage, months since delivery, and services completed. The status recalculates immediately, the same as in production (model policy with a group-wide fallback).
km limit
100,000
Month limit
36
Min. services
3
Within the km limit, within the month limit, and with services up to date. Coverage is active.
In production this evaluation runs in cascade per VIN: first the model policy, and if there is none, the group-wide policy. The customer sees it in their portal without anyone calculating it.
04 · Two-way Kommo sync + WhatsApp templates
The lead is recorded once. The system and Kommo keep themselves identical.
And the message to the customer is assembled from a template: the variables are filled from the record and the conditional blocks appear according to their warranty status.
The lead arrives
WhatsApp, web form, or bulk XLSX import. The phone number is normalized to the +58 format.
Internal pipeline
The salesperson works it by stages in their portal. Every change triggers the sync.
Two-way Kommo sync
What changes in the system goes up to Kommo; what changes in Kommo comes down to the system. One single truth.
WhatsApp from a template
Template with variables and conditional blocks driven by the actual warranty status.
Source template
Hi {{nombre}}, your {{modelo}} ({{placa}}) is booked for {{fecha}}.{{#garantia_activa}} Your warranty is still valid, so the service carries no labor cost.{{/garantia_activa}}{{#garantia_vencida}} Your warranty has expired; we are sending the estimate separately.{{/garantia_vencida}}Message the customer receives
Hi Andrea, your GAC GS3 (AB123CD) is booked for Tue 19, 9:00 a.m.. Your warranty is still valid, so the service carries no labor cost.
05 · Development scope
The architecture that holds up the four portals.
Multi-brand at the root
Dealerships with one or several brands (GAC · DFSK · BERA · EMPIRE), models per brand, and a per-model warranty with a fallback to the group-wide policy.
Role-based RBAC
Each role sees only what belongs to it: the group sees everything, the location sees its location, the salesperson their leads, and the customer their vehicles.
3 login methods
Email + password for management, a 4-digit PIN for the salesperson on the floor, and license plate → magic link for the customer with no credentials.
Configurable dashboards
The superadmin defines which widgets each dealership and each role sees; the dashboard is assembled from configuration, not hardcoded.
Cascading warranty engine
Automatic evaluation per VIN: km + months + services → active / expired / voided, resolving the model policy first and the group-wide one as backup.
Live integrations
Two-way sync with Kommo, bulk XLSX import/export, +58 phone normalization, and WhatsApp templates with variables and conditional blocks.
06 · What changed in the process
What changed was not the software. It was how the group works.
Results in terms of process and development scope, with no invented metrics.
One single operation, four brands
The group stopped running GAC, DFSK, BERA, and EMPIRE as separate businesses: today it is one system with context per brand and per location.
Warranties without human judgment
Validity no longer depends on who reviewed it. The rule is the same for everyone and evaluates itself, consistently.
No lead is lost in the copying
With a two-way Kommo sync, copying and pasting between WhatsApp, Excel, and the CRM disappeared.
The customer serves themselves
With their license plate they sign in, see their vehicles and warranty status, and book a service without calling or waiting for anyone.
Communication is consistent
Messages go out from a template and adapt to the customer’s actual status; they no longer depend on what each salesperson wrote.
A base ready to grow
Adding a brand or a location is configuration, not new development: the multi-brand architecture absorbs it.
YOUR DEALERSHIP GROUP IS NEXT
Do you run multiple brands as if they were separate businesses?
We'll show you how we'd rebuild your multi-brand operation into four role-based portals, with self-evaluating warranties and a synced pipeline. Schedule a 30-minute assessment.