Home · Solutions · Operations & quality
Solution · Operations & qualityOffer the customer a slot that exists: skill, bay, courtesy car and parts already checked
Service slots booked against real workshop capacity
Every booking from the phone, the website, the importer's app or the desk is checked against technician skills, bays, courtesy cars and parts before it is promised.
Executive summary
Stop booking three timing belts on a Tuesday with one qualified technician, and ordering the parts once the car is on the ramp.
The design starts from a catalogue, not a robot.
The adviser offers a slot that exists: skill hours, a bay, a car and parts are checked before the customer hears a date.
the workshop diary and parts orders in each brand's DMS; the car register in Microsoft Lists; the importer's parts ordering
Business problem
Workshop planning
New-car margins are thin; a dealer group's result is made in aftersales, where the unit of sale is a technician-hour, and it is perishable. The diary is where the hours are sold, and in most groups it is filled from the customer's side only: the day asked for, the job as described.
Bookings arrive by phone, through the website form, from the manufacturer's app and at the desk; website and app bookings come in as emails and are retyped. The diary then knows the day and the hours, not which technician holds the high-voltage qualification, whether the alignment bay is taken, whether a courtesy car exists that morning, or whether the parts kit is on the shelf.
The adviser promises with the customer waiting. The workshop manager reads next week on Friday afternoon and moves jobs by phone. The customer returns for a second visit, then answers the manufacturer's satisfaction survey, which the group is paid on. Utilisation reads eighty percent on hours sold, while ramps stand empty on Thursday.
How it works today
- PersonA customer calls; the adviser finds a free line in the DMS diary on the day asked for and writes in the job as described
- PersonWebsite and importer-app bookings arrive as emails and are retyped into the diary in the afternoon, sometimes the next day
- Risk of errorThe diary counts hours, not skills or bays: three timing belts land on the Tuesday the one qualified technician is on leave
- PersonCourtesy cars are promised from memory and a whiteboard; about once a week one car is promised twice for the same day
- WaitingThe parts desk hears what next week needs when the adviser has a quiet moment; otherwise parts are ordered when the car arrives
- SystemThe car is on the ramp, the part is not there; the customer is called, the courtesy car stays out a second day, the ramp waits
- PersonThe workshop manager reads next week's diary on Friday afternoon and moves jobs and customers by phone
- Risk of errorUtilisation is reported on sold hours: eighty percent on paper, idle ramps on Thursday
Why the current process costs more than it appears
The bill that never reaches the budget.
- Retyping is the small cost. Each booking carries three checks nobody records: is the skill there that day, is a car free, can the parts arrive. Skipped, they return later as a second visit.
- An hour not sold on Thursday is gone. Overbooked Tuesdays and empty Thursdays are one planning error seen from two sides, and a utilisation figure built on sold hours hides both.
- Promises made without a check become customer experience: a missing courtesy car and a second visit are what the manufacturer's after-service survey asks about, and the survey feeds the bonus.
- Parts ordered with the car on the ramp are express orders for a customer already waiting; ordered against a booking date, the same part comes with the regular delivery.
Cost of inaction
Idle ramps appear in no report as a cost, so the second row deserves the argument: six unsold hours a week per workshop is under one technician-day per site, and at a retail labour rate it matches the whole coordination pool. Neither row prices the second visit, the car out an extra day, or the survey the customer answers after both.
Without a change the week keeps its shape: Tuesday overbooked because it was asked for, Thursday idle because nobody offered it, express parts orders as a habit. A tenth workshop adds a tenth diary.
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: three brands, nine authorised workshops in six cities, 74 technicians, 22 service advisers, 38 courtesy cars, one DMS per brand, Microsoft 365 with Teams.
4,100 service bookings a month; roughly 45% by phone, 25% through the website form, 15% through the importers' apps, 15% at the desk; one booking in three asks for a courtesy car.
The adviser writes what the customer asks for into the DMS diary; website and app bookings are retyped from email; the parts desk hears the day before, when there is time.
About eight minutes per booking of checking, retyping and coordination; a diary that counts hours, not skills or bays; a car promised twice about once a week; parts ordered on the ramp.
One queue for every booking; robots attach standard time, skill, bay type and parts kit, check the day's capacity, reserve a courtesy car and order the parts; the adviser offers slots that exist.
In the modelled case the eight minutes per booking fall to the exception share, a promised car exists, parts for known jobs are on the shelf the day before, and Thursday's idle hours are visible a week early; a model, not a client.
Proposed solution
The design starts from a catalogue, not a robot. Each job the workshop sells gets a row per brand in Microsoft Lists: standard time, required skill, bay type, whether it needs a courtesy car, and the parts kit by model and mileage. Beside it sits the site's capacity: technicians with skills and roster, bays by type, the courtesy-car fleet with its reservations. A site factor per job family adjusts the standard time to the site.
Robots collect and check. Every booking becomes one queue item in Orchestrator; the robot reads the vehicle in the DMS, attaches the job row and checks the day for skill hours, a bay, a car and parts. If everything fits, it books, reserves, orders and confirms; if not, the adviser receives the nearest three dates that fit.
Teams is where the people work: next week's load by skill and bay in a Power BI tab, collisions as UiPath Action Center tasks listing the jobs that could move, a daily list for the parts desk. Nothing is diagnosed by a robot; what the technician finds on the ramp stays with the technician. No AI is involved.
UiPath Orchestrator queues, triggers and credential stores; UiPath Integration Service connectors for Microsoft OneDrive & SharePoint, Microsoft Outlook 365 and Microsoft Teams; UiPath Action Center tasks in Microsoft Teams; Microsoft Lists forms and versioning; Power BI as a Teams tab
The booking queue and channel adapters, the job catalogue and capacity model, the reservation logic, the collision rules and tasks, the parts desk's daily list, the Power BI load model, confirmation texts and the advisers' runbook
Each brand's DMS (vehicle file, diary, parts) through its API where the vendor offers one, otherwise through UI automation with the robot's own account; the importer's parts ordering by the same route; the website form by email or webhook
How the automated process works
- AutomationA booking from any channel becomes one queue item: the adviser's form in Microsoft Lists, the website form by email or webhook, the importer's app through the mailbox it writes to
- SystemThe robot reads the vehicle in the DMS (model, engine, mileage) and attaches the job row: standard time, site factor, skill, bay type, parts kit
- AutomationIt checks the requested day: skill hours left after bookings and absences, a bay of the right type, a free car if needed, parts on the shelf or deliverable by the day before
- AutomationWhen the day fits, the booking goes into the DMS diary, the car is reserved, the parts are ordered against the visit, and the confirmation goes out on the channel the customer used, limited to the appointment; anything beyond it needs the channel consent record
- PersonWhen it does not fit, the adviser receives the nearest three dates that do as an Action Center task in Teams; the adviser may still book the requested day, and the collision is flagged the same hour
- PersonThe workshop manager reviews next week's load in the Power BI tab; collisions arrive as Action Center tasks with the jobs that could move, the manager decides, the robot checks and reserves again
- AutomationThe parts desk receives a daily list in its channel; a part that will not arrive in time raises a task to the adviser two working days before the visit
- SystemAfter each visit, planned and actual hours are written back per job family, and the aftersales director corrects the site factors
Human-in-the-loop model
Automation handles
- Collecting every booking from every channel into one queue, with vehicle and job row attached
- Checking capacity by skill and bay, reserving the car, ordering the parts, writing the booking into the DMS diary
- Confirmations, alternative dates for the adviser, collision tasks for the workshop manager, the parts desk's daily list
People decide
- What the customer is offered and promised: the adviser talks to the customer and may overrule the proposal
- Which jobs move when a day collides: the workshop manager, from the task
- What is wrong with the car and what work it needs: the technician, never the robot; additional work is a separate decision with the customer
- The catalogue itself: standard times, site factors, skills, car rules and parts kits stay with the aftersales director
Before and after
Systems and integrations
We do not add technology to make an architecture look serious. Every element below has a specific job in this process.
Inputs
- the adviser's booking form
- the website form
- importer-app bookings via the site mailbox
- the technician roster and absences
- the bay register
- the courtesy-car register
- the job catalogue
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- the workshop diary and parts orders in each brand's DMS
- the car register in Microsoft Lists
- the importer's parts ordering
- Power BI semantic model
Human touchpoints: the adviser's form and alternative-date tasks in Teams; Action Center tasks for collisions and parts shortages; the parts desk's daily list; the Power BI load tab
Technologies used
one booking queue across nine workshops; triggers; credential store; retries and run log
Alist-item trigger on the booking form, email trigger for website and app bookings, channel messages
Acollision tasks for the workshop manager, alternative-date and parts tasks for the adviser
Abooking form, job catalogue, skills and roster, bay register, courtesy-car register
Anext week's load by skill and bay, car occupancy and parts readiness per site, as a Teams tab
Asystem of record; API where offered, otherwise the user interface
CIllustrative economic model
What it is worth, with the arithmetic shown.
Behind each booking sit three checks no timesheet records: skill hours that day, a free car, and the parts and their lead time. Eight minutes is what those checks, the retyping and the calls around them add up to across the adviser and the parts desk; €22 is a fully loaded hourly cost blended across advisers and parts staff in Poland. Nothing was measured at a client; the rows price released capacity, 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
- The adviser offers a slot that exists: skill hours, a bay, a car and parts are checked before the customer hears a date
- Jobs known in advance have their parts on the shelf the day before; one visit stays one visit
- Next week's load is visible by skill on Friday, not by phone on Monday, and collisions are moved a week early
- After-service satisfaction, which the manufacturer measures and pays on, is defended where the promise is made
The management view
- Nine diaries read on one scale: hours sold, hours planned by skill, bays free by day, car occupancy and parts readiness
- Utilisation turns from a reporting number into a planning number: next week's idle hours are seen before they happen
- Every promise has a trail: who booked what, what was checked and reserved, what changed and why
- Standard times and site factors are corrected from actual hours, so the plan improves each month
Board-level KPIs
Security and governance
Where the data sits and who can see it.
- Each robot signs in to the brand's DMS with its own account, limited to the diary, vehicle file and parts orders of its sites; the password sits in a vault Orchestrator reads at run time, never in a workflow
- The queue carries the registration number, the job and the requested day; name, phone and address stay in the DMS; robots run from the EU region of UiPath Automation Cloud and the registers stay in the group's Microsoft 365 tenant
- Confirmations are limited to the appointment; a reminder or an offer beyond it goes only where the channel consent record allows and never to a contact on the suppression list
- Standard times, site factors, skills and car rules are versioned in Microsoft Lists and changed by the aftersales director's role only; technicians' qualifications are listed with expiry only, the certificate stays in HR
Why now
Skills, not hours, are becoming the constraint: more than half of the new cars registered in Poland in 2025 had an electrified or gas drivetrain (350,500 of 597,400, PZPM and KPMG, February 2026), and only some technicians hold the high-voltage qualification; a diary that plans by hours alone overbooks the wrong people
Capacity found in the existing diary costs nothing to recruit: the modelled €12,030 a month is adviser and parts-desk time, and the unsold hours behind it belong to technicians the group already pays
The pieces are ordinary now: Integration Service triggers on a Microsoft Lists item and on a mailbox, Action Center tasks inside Microsoft Teams, Power BI as a Teams tab; the custom part is the DMS connection, one per brand
Relevant executive roles
The diary becomes a plan by skill and bay across nine workshops, and utilisation turns from a report into a lever
Promises made at the desk are promises the site can keep, and the customer's survey after the visit reflects that
Unsold technician-hours are counted and moved, the courtesy-car fleet is sized from occupancy, and express parts orders fall to genuine surprises
Common questions and objections
It does, and the robot writes into it; the diary stays the system of record. What the planner does not read is the roster, the skills list, the car register, the parts lead time and the other three channels at once; the robot does.
They can, and should: the adviser decides. The booking is still checked the same hour, and a collision reaches the workshop manager as a task with alternatives, not on the morning.
Correct, which is why the catalogue carries a site factor per job family, and planned hours are compared with actual after every visit. Today's diary is corrected by nobody.
When this is not the right solution
- A single workshop with one diary and an adviser who knows every technician and every car; a printed roster and a whiteboard cost less than a robot
- The DMS holds no standard times or skills per job; the catalogue is then a data project that comes first, and we will say so
- Most of the site's work is drive-in and breakdown traffic that never passes through a booking; the diary is not where that capacity is decided
A question for the next management meeting
Next Tuesday, at our largest workshop: which technician is qualified for each job already in the diary, which customer gets which courtesy car, and will the parts be on the shelf before the cars are in the yard?
Implementation approach
What we deliver, and what we need from you to start.
We deliver
- Discovery at two workshops of different brands: channels, diary use, roster, fleet, parts routine, a month of bookings
- The job catalogue per brand in Microsoft Lists, with a site factor per job family
- The booking queue with adapters for the adviser's form, the website form and the importer-app mailbox
- The capacity and reservation robots, the DMS integration per brand, the tasks and daily list in Teams, the Power BI load model
- A pilot at one workshop, then rollout site by site with hypercare and a runbook for advisers
We need from you
- Three months of bookings and workshop orders from two sites, with planned and actual hours
- An aftersales director as owner of the catalogue, a workshop manager and a senior adviser for the pilot
- Robot accounts for each brand's DMS, the site mailboxes and Teams
Stages
Discovery
Channels, diary use, roster, fleet, parts routine at two workshops
Design
Job catalogue, capacity model, reservation and collision rules, permissions, confirmation texts
Build
Queue, robots, DMS integration per brand, Teams tasks, Power BI model
Pilot
One workshop through a full booking cycle alongside the current diary
Rollout
The remaining workshops in brand order, with hypercare
Departmental. Effort depends on how many DMSs the group runs and whether each offers an API, and on how complete the standard-time and skills data are.
Eighty percent on paper, two empty ramps on Thursday, three timing belts on Tuesday.
Send us one week of one site's workshop diary, that week's roster and the courtesy-car list. We come back with the collisions a robot would have flagged, the parts it would have ordered earlier, and a first estimate of the hours released.
Check one week of bookings against capacityThe neighbouring process usually has the same problem
Stop parking cars on the ramp while an adviser dials voicemail for a yes the customer would have tapped in a minute.
View solution Supply chainThe part is next door, not on a six-week backorderStop ordering from the importer what your other sites already hold, and stop missing the return window for the rest.
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 solutionIndustries we deliver this in most oftenAutomotive retail