The Dealership Call Centre: Agents Juggling Six Screens to Answer One Question

Ask a dealership call-centre agent a simple question: "Has my car been collected from the body shop, and what do I owe?" Then watch what happens. The customer is on the line, and the agent is in the telephony softphone. Next comes the CRM to find the customer, the DMS to find the job card, and another screen for the invoice. Then WhatsApp Web, because the customer sent photos there yesterday, and a spreadsheet the service advisor updates when he remembers. Six screens, one question.

The customer hears typing and silence. The agent hears the clock. Across a few hundred calls a day, several branches and more than one language, handle times balloon. Agents are not slow. The answer simply lives in places that do not talk to each other.

This article is for the people who own that problem: owners, GMs, COOs, and aftersales, RevOps and customer-experience heads at dealer groups, especially those running several locations or several countries. We will look at the systems usually involved, what fragmentation costs in practice, and what fixing it looks like without ripping out software you have already paid for.

The stack most dealer groups actually run

Few dealer groups have a single system. They have layers added over years, each bought for a good reason:

• Cloud telephony or contact-centre platform. This might be Genesys, Avaya, or a hosted cloud telephony service. It handles routing, IVR menus, queues, recording and call statistics. It knows which number called and which queue it landed in. It rarely knows who the customer is or what car they drive.
• CRM. This holds leads, customer records, campaigns and case history. In many groups it was introduced for sales, so service interactions are logged inconsistently, if at all.
• DMS (dealer management system). This is the system of record for vehicles, job cards, parts, warranty, invoicing and stock. It is usually the most critical system and often the oldest, with limited or awkward interfaces.
• WhatsApp Business API. Via a messaging provider, this gives the business a verified number, a shared agent inbox, approved message templates for notifications, and opt-in handling.
• Finance or ERP. This is where tax invoices, credit notes and receivables are finalised, and where regional e-invoicing mandates, such as Peppol-based schemes, are met.
• Website forms and booking pages, which often drop requests into an inbox or spreadsheet rather than into any of the above.

Each of these works. The failures sit in the gaps between them, and the agent's screen is where those gaps become visible. Those same gaps stop leadership from seeing the operation as one picture.

A Tuesday morning, hypothetically

Consider a dealer group with branches in three countries and a central call centre. At 9:40 a customer calls in his first language about his SUV, which went into the workshop three days ago.

The agent, who speaks two languages, takes the call. The telephony platform shows a number, but it matches no customer. The vehicle is registered in the DMS under his wife's mobile number, and the CRM holds a second record for him with his name transliterated differently. She searches the CRM by name, gets two near-matches, and picks one. It has no service history.

She asks for the plate number and finds the job card in the DMS. The status reads "work completed", but no invoice has been raised. The advisor's notes say nothing about why. After a hold of nearly two minutes, she finds the reason in the shared WhatsApp inbox. Yesterday the customer approved an additional repair by voice note, sent to the advisor's own number rather than the business line. The advisor is at another branch and is not picking up.

Eight minutes in, the agent promises a callback. She logs the call in the CRM, but not in the DMS. The advisor, who never sees the CRM note, sends the customer a "your car is ready" template that afternoon, before the invoice is finalised. The customer arrives at the branch, waits for the bill, and then calls the call centre to complain. A different agent picks up and starts from zero.

Nothing here required a bad employee or bad software. It required six screens that did not share a customer.

Where the time, accuracy and money go

Scenarios like this are not isolated. Fragmentation leaks value in recognisable ways:

• Search and re-keying. Agents spend a large share of every call finding the customer and retyping details across systems. Every re-key is a chance for a wrong digit in a plate, phone number or chassis number.
• Duplicate and mismatched identities. Different name spellings across scripts and languages, family members sharing a number, and company fleets with several drivers all fragment the customer record. Nobody sees the full relationship.
• Hold time and callbacks. Each hold is an admission that the answer is elsewhere. Each promised callback is a second call the business pays for.
• Stale data. An appointment booked in the CRM but not written to the DMS means the workshop's capacity picture is wrong. Slots go empty, or two customers arrive for one bay.
• Broken follow-up. Service reminders driven by DMS history never reach the CRM campaign, or reach it a month late. Customers lapse quietly to independent garages.
• Unbilled and unapproved work. Approvals sitting in a WhatsApp thread, rather than attached to the job card, lead to disputes at collection. Sometimes work is done and never charged.
• Agent fatigue and turnover. Training someone on six tools takes weeks. Working in them all day, with a customer waiting, wears people down, and the next hire repeats the cycle.

None of these shows up as a line item. They show up as slow calls, repeat calls, unhappy customers and aftersales revenue that is smaller than the workshop's capacity should produce. For a RevOps lead, the effect is just as bad: lead-to-service-to-retention numbers come from different systems and rarely reconcile, so the funnel can't be trusted end to end.

WhatsApp is the front door, but it is bolted to the side

In many markets, customers prefer messaging to a phone call. They send voice notes, photos of a dashboard warning light, a screenshot of a quote. Multilingual customers switch languages mid-conversation, and they expect a reply in minutes.

The WhatsApp Business API makes this manageable at scale: multiple agents on one number, approved templates for reminders and ready-for-collection notices, and consent tracking. But it only helps if the conversation is connected to the rest of the business. When it is not:

• The agent opening a thread cannot see the customer's vehicle, open job card or last invoice, so the first reply is "Can you send your plate number?"
• A customer who calls and messages at the same time reaches two agents who each answer in isolation.
• Template notifications fire from one system with no knowledge of the invoice status in another.
• Approvals, photos and promises stay trapped in a chat rather than attaching to the job card.
• When advisors use personal WhatsApp numbers to keep things moving, customer history leaves with them when they do. That is also a problem under data protection laws such as GDPR, which expect consent and customer data to be managed in systems the business controls.

Messaging should be an input to the operating system of the business, not a parallel one.

Peak seasons and tax rules: when the cracks widen

Fragmentation is manageable on a quiet day. It stops being manageable under pressure, and the calendar brings plenty of it.

Peak seasons change the shape of demand. Holiday periods shift working hours and bunch call volumes around different times of day. Pre-holiday servicing, pre-summer air-conditioning checks, winter-readiness inspections and holiday-travel checks push workshops to capacity. School-return periods and public holidays bring their own spikes. The call centre often runs with the same headcount and a heavier queue. If every call takes two minutes longer than it should because of screen-hopping, the queue grows and abandonment follows. For a group with sites in several countries, these peaks rarely line up, so one location may be overwhelmed while another has spare capacity. Without a shared view, nobody can rebalance.

Tax and invoicing add a second layer. A customer who needs a corrected invoice with the right company name and tax registration number triggers a chain: the agent checks the CRM, the DMS holds a different value, finance needs to issue a credit note and a new invoice, and the customer expects it on WhatsApp within the hour. Where regional e-invoicing mandates apply, such as Peppol-based schemes, a mismatch between systems on something as basic as a buyer's details becomes a compliance issue, not just an irritation. Where VAT or GST documentation rules apply, they pull on finance time in the same way. Data that is wrong in one system and right in another is expensive in both places.

Why another tool, or a full replacement, is rarely the answer

The usual responses to this problem each have limits.

Buying a bigger platform. A unified contact-centre suite can improve routing and reporting. But the customer and vehicle data still lives in the DMS and CRM, and the platform is only as useful as what it can read from them.

Replacing the DMS or CRM. This is a large, risky programme. The DMS is entwined with the workshop, parts, warranty and finance. Few groups want to disrupt aftersales, the most revenue-critical and most manual part of the business, for a project that may take years.

Adding a screen-pop or agent desktop widget. This helps, but only if the data behind it is consistent. A pop-up showing the wrong customer faster is not progress.

One-off integration projects. Point-to-point connections built by a vendor and then left alone tend to break when a system updates, and nobody owns the fix.

What is actually missing is a maintained operating layer between the systems, with an owner.

How The Ninjaz Group approaches it

The Ninjaz Group is a managed-services partner. It designs the change, wires a client's existing systems into one operating backbone, and stays on to run it. The work is organised in three phases, and you can stop after any one.

Blueprint. We map the operation end to end, starting with the call-centre journey in question: who calls, what they ask, which systems each answer lives in, and what the agent does to get it. The aim is to find every gap where work is done twice, data goes stale or money leaks. Some gaps will be technical, and others will turn out to be process or ownership problems. You keep the map either way.

Build & Link. We build what is missing and wire the existing systems into one backbone. There is no rip-and-replace, and software you have already paid for stays. For a call centre, the goal is that the caller is identified once, against both the DMS and CRM. The agent sees the customer, the vehicle, the open job and the recent WhatsApp thread in one place. Bookings write through to the DMS. Status changes flow back out to messaging. Approvals attach to the job card instead of living in a chat. This is the work of the Managed Link layer: the operating layer between systems, built, owned and maintained by Ninjaz so DMS, CRM, finance, service, website and messaging behave like one connected operation rather than six separate ones.

Run. Once the backbone is live, we keep it healthy. We monitor the connections, fix them when a vendor updates a system, and adjust as the business changes, whether that is a new branch, a new country or a new messaging flow. On top of this, a central command-center view gives leadership one picture across locations: queues, handle times, open jobs, unbilled work and follow-up status. The group can then manage the operation from shared data rather than from several conflicting reports. The same data gives RevOps a consistent view from enquiry through service to retention, so the numbers reconcile.

None of this requires a big-bang programme. Many groups start with a single journey, such as "where is my car and what do I owe", prove that it works at one site, and then extend it to the other branches and countries.

Start with the question your agents hear most

If your agents are juggling six screens to answer one question, the problem is not the agents, and it is probably not any single piece of software either. It is the missing layer between them, and nobody owning it.

If you would like to see where the gaps are in your own operation, book a consultation. We will start with one call-centre journey and show you what a connected version could look like.