Home · Solutions · Customer service
Solution · Customer serviceEvery due date already sits in your DMS. The customer should hear it from you first.
Reminders that bring the car back to your workshop
Robots compute every vehicle's next service, inspection, tyre and guarantee-end date, check consent per channel, send a reminder with a booking link, and show which customers are going quiet.
Executive summary
Stop learning that a customer has left only when the fourth service fails to appear in the diary.
The design starts with a table, not a message.
Every vehicle is written to before its date, on the customer's channel, with a link that turns the reminder into a booking without a phone call.
the SMS gateway or Azure Communication Services; site mailboxes in Microsoft Outlook 365; the contact log in the DMS or CRM
Business problem
Customer retention
A dealer group earns little on the new car and most of its result afterwards: workshop hours, parts, tyres, storage, the next car. All of it depends on the customer coming back, and that is left to chance. In the first years the guarantee and the manufacturer's programmes bring the car in; around the third year they thin out, the owner starts to compare, and retention falls with nobody holding a number for it.
The dates that would keep the car are already in the DMS: last service and mileage, an odometer reading from every visit, delivery date and guarantee term, the last inspection, the set on the storage rack. What is missing is the list: each site pulls its own report when the diary looks thin, and a customer who did not answer is called next month by somebody else, or never.
The independent workshop is a lawful competitor with the same right to the manufacturer's repair information (Regulation (EU) 2018/858, Article 61) and often a better reminder habit. What it lacks is the group's service history, diary, storage rack and consents, worth nothing unused.
How it works today
- PersonThe adviser pulls a "vehicles due" report from the DMS when the diary looks thin and calls or texts between customers; the bookings that follow are never traced back
- PersonA marketing coordinator builds the tyre-season list in Excel from a DMS export and the storage file, de-duplicates by eye and sends a batch through the SMS portal
- Risk of errorConsent is checked from memory or not at all: the export carries a number, so it is used; an objection noted at one site never reaches the other ten
- WaitingInspection dates are known only for cars the group's own station inspected, guarantee ends are on nobody's list, and a car outside this month's report waits for the next quiet hour
- SystemRetention is computed once a year in Excel for the budget and argued about, because every site counts its base differently
Why the current process costs more than it appears
Nobody planned this work; it accumulated.
- Four minutes per reminder is the visible cost. The invisible one is the reminder never sent, because the day the adviser is busy is the day the base is not written to.
- A customer lost after year three shows up nowhere as a loss: one workshop order fewer in a full diary, a storage contract quietly not renewed, a retention figure argued about once a year.
- Consent handled from memory is a liability carried per message: a text to a number with no channel consent, or to a customer who objected at another site, is what a regulator asks about.
Cost of inaction
Nobody budgets for a customer who does not come back: the fourth service simply fails to appear in a diary that is full anyway. The third row is the one to argue about. 1,500 vehicles a year is under five in a hundred of a 31,000-vehicle base, and €280 is a modest year of workshop labour, parts and tyres. Put your own numbers in; the effect compounds, because a car that went quiet in year three is absent in year four as well.
Without a change the sites write to the customers they have time for, the peaks arrive unprepared, the consents stay in people's memories, and retention is learned once a year from a workbook.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A dealer group in Poland: four brands, eleven showrooms, nine authorised workshops, one DMS per brand, a group CRM with the consent record, Microsoft 365 with Teams; 31,000 vehicles sold or serviced in the last four years.
9,800 reminder messages a month at full coverage, averaged over the year: about 3,900 service-due, 2,100 inspection, 1,400 guarantee-end and 2,400 second or third touches.
Each site pulls its own due report when somebody has time; the tyre list is built in Excel; consent is checked from memory; bookings are not tied back.
About four minutes per reminder across the list, the call or text and the note afterwards; coverage that depends on an empty diary; no retention number until the budget round.
Robots compute each vehicle's next due date from the rule table and the mileage trend, check consent per message and channel, send with a booking link, stop after the agreed sequence, and report due lists, response rates and retention in Teams and Power BI.
In the modelled case the whole base is written to on time, 653 hours a month return to the desk, every message carries a recorded consent and an outcome, and the board sees retention by year of ownership monthly. Modelled potential, not a client result.
Proposed solution
The design starts with a table, not a message. A row in Microsoft Lists per brand carries the service interval in months and kilometres, the guarantee term, the reminder types, the sequence per type and the versioned template. A second table, signed by counsel, records which type is a plain service notice and which is commercial communication, and the consent each needs on each channel. The aftersales director owns both; robots only read them.
Robots do the arithmetic and nothing else. A robot reads every vehicle from each brand's DMS, derives a kilometres-per-day trend from the odometer readings, and takes the earlier of the projected mileage interval and the time interval as the service due date; inspection and guarantee-end dates come from their own fields, and the tyre window is set per region, since Poland has no calendar rule for winter tyres. Nothing leaves without the consent check for that customer, entity and channel. No AI is involved: every date is arithmetic on fields the group already holds.
UiPath Orchestrator time triggers, queues and credential store; UiPath Integration Service connectors for Microsoft Outlook 365, Microsoft Teams and Microsoft OneDrive & SharePoint; UiPath Action Center notifications in Microsoft Teams; Microsoft Lists versioning; Power BI as a Teams tab
The due-date engine per brand, the consent and suppression check, sequence and cap rules, versioned templates, booking and response matching, site channels, adviser tasks and the Power BI retention model
Each brand's DMS and the group CRM by API where the vendor offers one, otherwise UI automation with the robot's own account; the SMS gateway through UiPath Connector Builder, or Azure Communication Services
How the automated process works
- AutomationOn the first working day of the month, and nightly for vehicles with new workshop orders, a robot reads every vehicle from each DMS, computes the due dates from the rule table in Microsoft Lists and queues them in Orchestrator
- AutomationBefore every message the robot checks the consent record for that customer, entity and channel, and the suppression list that any reply saying stop updates the same day for every brand; a vehicle with no usable channel becomes a line on the site's list, never a message
- AutomationThe reminder goes out by SMS through the gateway or by e‑mail from the site mailbox, with a proposed window and a booking link; each send is logged with template version and consent reference
- SystemA booking made through the link lands in the workshop diary like any other; the robot matches bookings and workshop orders back by registration number, so every message ends as booked, visited or silent
- PersonVehicles worth a call, such as a guarantee ending or a set on the rack, reach the adviser as an Action Center task in Teams with the history attached; the adviser decides and records the outcome
- AutomationEach month the site channel receives next month's due list by type, the last cycle's response rate by channel and the vehicles that went quiet; the Power BI tab shows retention by year of ownership
Human-in-the-loop model
Automation handles
- Reading every vehicle in every DMS and computing the next service, inspection, tyre and guarantee-end dates
- The consent and suppression check per message and channel, the send, the log, the sequence and the cap
- Matching bookings back to reminders, due lists and response rates in Teams, the retention model in Power BI
People decide
- What the car needs: the technician on the ramp and the adviser with the customer; a reminder names a date, never a diagnosis
- Which customers get a call rather than a third text, and what is said: the adviser, from the task
- Intervals, tyre windows, sequences and templates: the aftersales director, with counsel on the basis for each type
Before and after
Systems and integrations
Every entry can be checked in vendor documentation. The evidence class is stated next to each one.
Inputs
- vehicle files, service history and odometer readings in each brand's DMS
- the consent record and suppression list in the group CRM
- storage records
- the rule tables in Microsoft Lists
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- the SMS gateway or Azure Communication Services
- site mailboxes in Microsoft Outlook 365
- the contact log in the DMS or CRM
- the Power BI semantic model
Human touchpoints: due lists and response rates in site channels in Microsoft Teams; Action Center call tasks; the Power BI retention tab; the rule tables in Microsoft Lists
Technologies used
monthly and nightly runs over four DMSs, one queue item per due date, time triggers, credential store, run log
Ae‑mail reminders, channel posts, rule tables read from SharePoint lists
Acall tasks for advisers with the vehicle history
Ainterval and sequence tables per brand, the basis table signed by counsel, versioned templates
Adue list by month and site, response rate by channel and type, retention by year of ownership
Atext messages with the booking link
Avehicle file, service history, consent record
CIllustrative economic model
The arithmetic is open, so it can be argued with.
A reminder never sent costs nothing to send, which is the trap this table avoids: it prices full coverage by hand, the consistency the group does not pay for today. Four minutes blends the coordinator's list work, the adviser's call or text and the note afterwards; €21 an hour is a fully loaded cost in Poland. Nothing was measured at a client, and the rows show capacity returned, not posts removed.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Every vehicle is written to before its date, on the customer's channel, with a link that turns the reminder into a booking without a phone call
- The modelled 653 hours a month go back to the customers at the desk; what remains is the calls worth making, handed over as tasks with the history attached
- Each message carries a recorded consent and a template version; an objection at one site silences every brand the same day
- Every reminder has an outcome in the data, so the SMS budget and the sequence are tuned on response rates rather than defended on habit
- Peaks are planned a month ahead from the due list, and customers going quiet are named in time
The management view
- Eleven sites, one due list: what is due next month by type and site, how much of it may be sent, and what the last cycle produced
- Retention by year of ownership, the number the board has never had: the share of vehicles sold in each year with a paid visit in the last twelve months
- A trail per message: date, type, channel, template version, consent reference, outcome; a regulator's letter is answered by a query, not a search
Board-level KPIs
Security and governance
Control is not an add-on.
- Each robot signs in to a brand's DMS with its own account, allowed to read the vehicle file and write the contact log, nothing else; mailbox and gateway credentials sit in the Orchestrator credential store, never in a workflow
- Queue items carry registration number, type, channel and date; contact details are read at send time and not stored in Orchestrator, robots run from the EU region of UiPath Automation Cloud, and the lists, the log and the Power BI model stay in the group's tenant
- Every send is logged with template version and consent reference, the evidence a complaint or a regulator's query calls for; objections take effect within the day across every brand, and only a named role clears an entry from the suppression list
- Rule tables and templates are versioned in Microsoft Lists and changed only under the aftersales director's role
Why now
The record years are ageing into the drift years: 597,400 new passenger cars were registered in Poland in 2025, 8.3% more than in 2024 (PZPM and KPMG, February 2026), and each becomes somebody's third- and fourth-year owner; who writes first decides whose workshop that owner uses
Consistency has a price the group never pays and a cost it pays anyway: the modelled €13,720 a month is what full coverage by hand would take, so the sites send a third of it
Nothing in the stack is exotic: Orchestrator time triggers, Integration Service connectors, Action Center tasks in Teams and Power BI as a Teams tab; the group-specific work is the rule tables and the DMS connection
Relevant executive roles
The base is written to completely and on time, outbound work shrinks to the calls worth making, and retention becomes a monthly number with an owner
The revenue row in the cost of inaction is the aftersales result three years out, and the SMS and adviser budget is tuned on response rates
The site knows a month ahead what is due, what it may send, and which customers are going quiet while a call can still bring them back
Common questions and objections
For some brands it does, and the design reads that calendar so the sequences do not collide. The importer's message does not carry your diary, your storage rack or your booking link.
The sequence has an end and the cap is group-wide: at most one message per customer per fortnight, an agreed number of touches, then silence until the next cycle. An objection on any channel, at any site, silences every brand the same day.
That is the problem stated exactly: the call happens when the diary is thin, not when the car is due. The design keeps the call for the vehicles worth it and hands it over as a task with the history attached.
When this is not the right solution
- A single-site dealer with a few thousand vehicles and one adviser who knows the base; a good DMS report and a fixed hour a week cost less than a robot
- The DMS holds no reliable odometer readings or service history because most of the base is serviced elsewhere; the engine would have nothing to compute from
- No channel-level consent record exists; the robot could send almost nothing, and consent capture at the desk comes first
A question for the next management meeting
By the fourth year of ownership, how many of the cars this group sold are still serviced by this group, and does anybody in the room own that number?
Implementation approach
Delivery runs in stages, so it can be stopped at any point.
We deliver
- Discovery at two sites of different brands: due reports, who sends what, the consent record as it is, a month of contacts and their outcomes
- Rule tables per brand in Microsoft Lists and the basis table for counsel's sign-off
- The due-date engine with DMS reading per brand, the consent and suppression check, sending, the send log and response matching
- Site channels, adviser tasks in Action Center and the Power BI retention model
- A pilot with one brand and one reminder type, then the rest, with hypercare and a runbook
We need from you
- A read-only extract of one brand's vehicle base with service history, odometer readings and the consent record
- An aftersales director to own the rule tables, a site director and a senior adviser for the pilot, counsel for the basis table
- Robot accounts for each DMS and the CRM, the site mailboxes, the SMS gateway and Teams
Stages
Discovery
Due reports, consent record, contact volumes and outcomes at two sites
Design
Rule tables, basis table, sequences and caps, templates, permissions, matching rules
Build
DMS reading, due-date engine, consent check, sending, tasks, Power BI model
Pilot and rollout
One brand and one reminder type for a full cycle, then the remaining types and brands, with hypercare
Quick win. Effort depends on how many DMSs hold the base and whether each offers an API, on the state of the consent record, and on the number of condition-based intervals.
The date was in your DMS for a year. The text came from the workshop down the road.
Send us one brand's vehicle base as an extract: sold and serviced dates, odometer readings, last inspection, the consent record as it stands. We come back with the due dates a robot would have computed and how many cars went quiet last year.
Count how many cars came back in year fourThe neighbouring process usually has the same problem
Stop rebuilding each brand's campaign completion report from a printed call sheet, the DMS and the importer portal.
View solution Supply chainTyre season without a lost set or an unbilled shelfStop searching the racks for a set that has moved, and stop storing tyres nobody will collect.
View solution Sales & marketingThe next car offered while the current one is on the rampYour owner base drives through your workshops every month while sales buys leads from portals.
View solutionIndustries we deliver this in most oftenAutomotive retail