Dealerships
Dealership software that survives a DMS outage
CDK Global's June 2024 ransomware attack knocked booking, parts and finance systems offline at roughly 15,000 dealerships for weeks. Most had no way to take a service appointment without it.
What makes a dealership build different
4 things that decide this
- 01Two DMS vendors, CDK Global and Reynolds and Reynolds, run most of the software layer for North American dealerships, and both have suffered outages that stopped stores from booking or invoicing.
- 02A DMS integration is a negotiation, not a download. Vendors gate API access and charge for every connection, which is why so many dealer tools end up bolted on rather than built in.
- 03Service booking and parts procurement are the two workflows a dealership cannot run on paper for more than a day without losing revenue.
- 04Multi-store groups need one view across locations. A DMS built for a single rooftop does not give a general manager that by default.
You do not own the system your dealership runs on
CDK Global and Reynolds and Reynolds between them run the dealer management system for most North American dealerships. Your inventory, your repair orders, your finance and insurance paperwork, and your customer records all live inside one vendor's database.
In June 2024, CDK was hit by ransomware and took its systems offline for close to two weeks. Dealers went back to paper repair orders and manual credit checks. Some could not book a service appointment at all, because the booking calendar lived inside the DMS.
The lesson was not "pick a different DMS." Daily work, answering the phone, booking a bay, chasing a part, should not be rented from one vendor. Build it as a system you own, one that calls the DMS through its API instead of living inside it.
- 01A DMS outage does not just stop reporting. It stops the phone getting answered and the bay getting booked.
- 02API access to CDK and Reynolds is negotiated and metered.
- 03Owning the booking and procurement layer means a DMS outage degrades your business instead of stopping it entirely.
- CallA voice agent answers, independent of the DMS.
- BookWrites to your calendar, then syncs to the DMS.
- PartOutbound agents check supplier pricing directly.
- SyncRepair orders and quotes flow into the DMS by API.
- DegradeIf the DMS is down, booking and calls keep working.
The DMS stays the record of the sale. It stops being the single point of failure for taking one.
What dealer groups actually need built
AI reception that does not depend on the DMS
Inbound voice agents answer service and parts calls and book against your own calendar, so a DMS outage does not mean an unanswered phone.
DMS and API integration
Repair orders, parts requests and customer records synced to CDK, Reynolds or another DMS through its API, so your booking and procurement tools stay yours even where the record of sale stays in the DMS.
Outbound parts procurement
Agents call or query suppliers for availability and pricing and return a comparison, instead of a service advisor holding four calls at once.
Multi-store visibility
One dashboard across rooftops, with role-based access for service managers, front desk and parts, so a general manager sees every branch without logging into each DMS separately.
We have built this shape, in a multi-branch automotive business
ZhoopZhoop is a multi-branch collision and repair business in Toronto, not a franchised dealership. The workflow matches a dealership service department: a phone that has to be answered while every tech is busy. Parts that have to be sourced from more than one supplier.
Inbound AI voice agents answer the customer call and book the appointment against the live diary. Outbound agents call suppliers on request, collect availability and pricing, and hand back a comparison instead of a note on a pad. Every branch reports into one dashboard with role-based access.
A dealership service department adds one layer on top. Booking and parts data has to match a DMS the dealer does not control. That matching, not the voice agent, is the harder engineering problem. It is where a DMS integration project earns its scope.
- The booking and calling layer can be built and owned independently of the DMS.
- DMS integration is a separate, scoped piece of work.
- Escalation to a person has to fire before any booking logic, on every call, with no exceptions.
A multi-branch automotive build with the same shape
Renting the workflow against owning it
| Criterion | Booking and parts live inside the DMS | How we build it |
|---|---|---|
| DMS outage | Booking and calls stop. Staff move to paper. | Booking and calls keep working. Only the DMS sync waits. |
| Parts sourcing | A service advisor calls suppliers one at a time by hand. | Agents call or query suppliers and return a comparison. |
| Multi-store reporting | Log into each rooftop's DMS separately. | One dashboard across branches, role-based access. |
| Switching or adding a DMS | Rebuild every workflow that was baked into the old one. | The booking and parts layer stays yours. Only the sync target changes. |
The stack behind a dealership build
Reception and booking
Integration
Running it
Questions dealer groups ask first
01What happens to our booking system if CDK or Reynolds goes down again?
Nothing, if the calendar and call handling are your own system with an API connection to the DMS. An outage then degrades reporting, not your ability to take a call or book a bay. The 2024 CDK outage stopped booking at dealers precisely because the calendar itself was the DMS.
02Can you integrate with CDK Global or Reynolds and Reynolds?
Yes, to whatever API access the DMS vendor grants your dealership. Access is negotiated per dealer and usually metered per connection, so scope the integration first: which records sync, in which direction, how often. That scoping is a paid two-week diagnostic once it means working inside a system we do not control. The first conversation about it is free.
03How does an AI receptionist handle an emergency or upset caller?
It hands over to a person immediately, and that rule sits before any booking logic. Distress, confusion or anything sounding unsafe triggers an escalation rather than another question. See how we test for that before launch.
04Can one system cover multiple rooftops that each run differently?
Yes, and the hard part is permissions, not features. A dashboard across branches needs role-based access for service managers, front desk and parts. Decide early which choices stay central and which stay local to a store, because changing that later rewrites the data model.
05Do you build software for dealerships specifically, or for repair shops?
Both. We build the operational layer around the vehicle: booking, parts procurement, customer calls and DMS integration. A franchised dealership service department and an independent repair group need the same layer. That is why our production build for a Toronto repair operation transfers directly.
06How do we start without disrupting service during a DMS transition?
Pick one workflow, usually the phone or parts sourcing, and build it as a system independent of the DMS first. Scoping that call is free. Where the work has to reach into your existing DMS integration, a paid two-week diagnostic gives you a fixed price instead of a guess.
Go deeper
- Automotive software development →The full picture: repair, collision and service businesses.
- ZhoopZhoop case study →AI reception and parts procurement for a multi-branch automotive business.
- Should an AI receptionist handle emergency calls? →No. Route it to a person, and design that route first.
- API integration →How we connect owned systems to vendor platforms like a DMS.
