Home · Solutions · Customer service

Solution · Customer service

From the technician's photo to the customer's yes in minutes, written against the order

Repair status by message, additional work approved by a tap

Every repair-order status in the DMS becomes a message on the channel the customer chose; additional work goes out with the photo and the price, and the tap is recorded against the order.

Quick winMicrosoft TeamsHuman in the loopDeterministic automation
5,600repair orders a month close in this illustrative dealer group's nine workshops; for one in three, the car waited on the ramp while an adviser chased a yes by phone.

Executive summary

Challenge

Stop parking cars on the ramp while an adviser dials voicemail for a yes the customer would have tapped in a minute.

What changes

The DMS stays the system of record and the adviser stays the voice; what changes is who carries the news.

Business value

The car leaves the ramp on the customer's answer, not on the adviser's next free minute.

Systems involved

the repair order in the DMS (status, notes, attachments); SMS via the group's gateway or email via Microsoft Outlook 365; the event log read by Power BI

Business problem

Workshop communication

A repair order changes state five or six times between check-in and collection, and every change is news the customer wants. It travels by telephone from the adviser's desk, between customers at the counter, and the same adviser also prices the work, orders parts and hands cars over; a finding waits twice, for her free minute and then for the customer's.

The car can meanwhile be neither finished nor taken down, and reception answers "is my car ready?" on foot. The customer hears silence, then an invoice larger than the booking, carrying work agreed on a call nobody wrote down. The site director meets that in the importer's after-visit survey, which the group is partly paid on.

At group scale the habit becomes a blind spot: nine workshops, four brands, one DMS per brand, nine versions of "we'll call you", and no way to say how long cars wait for a decision. "tel. OK 12:35" on the job card is the entire approval trail.

How it works today

Nine workshops, one shape.

  1. PersonAt check-in the adviser notes the complaint in the DMS and promises to call; the mobile number is on the order, the preferred channel is not
  2. PersonThe technician finds worn front discs, writes the recommendation on the job card and photographs the disc with his phone, where the photo stays
  3. WaitingBack at the desk the adviser prices the lines, dials, reaches voicemail and tries again after the next customer; the car stays on the ramp
  4. PersonHearing nothing, the customer calls the switchboard twice; reception walks into the workshop and comes back with "still on the ramp"
  5. Risk of errorAfter two hours the technician takes the car down to free the ramp; when the yes arrives the car queues behind the afternoon's bookings
  6. SystemThe approval is a note on the job card, "tel. OK, discs and pads"; the price the customer heard is recorded nowhere, and the invoice surprises them
PersonWaitingRisk of errorSystem

Why the current process costs more than it appears

The cost grows where nobody is looking.

  • Fourteen minutes of telephone per order is the visible cost; the ramp is the larger one. A car waiting two hours for a yes holds a ramp sold by the hour, and the technician waits with it.
  • Unreached customers do not say no; they collect the car. A proposal unanswered by closing time leaves with the customer, and no report counts it.
  • Nothing about the approval survives in writing, so the counter conversation is one memory against another, settled with a discount.

Cost of inaction

Twelve months of dialling for a yes across nine workshops≈ €344,960
Three more years with the photo on the technician's phone≈ €1,035,000
Additional work released unsold, one proposal in twenty at €150 of parts and labour, per year≈ €191,500

The revenue row is deliberately small: one proposal in twenty is 106 cars a month out of the 2,128 with a finding, €150 is a modest ticket, and the margin rather than the ticket is what the group keeps. What no row prices is the ramp, where an hour spent waiting for voicemail is an hour sold to nobody.

Left alone the routine keeps its shape and gains a tenth version with the tenth workshop: advisers dial between customers, the disc photo stays on the technician's phone, the job card says "tel. OK", and the survey arrives the day after the customer learned the price.

Illustrative scenario

A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.

Organisation

A dealer group in Poland: four brands, nine authorised workshops in five cities, 84 technicians on 46 ramps, 26 service advisers; one DMS per brand; Microsoft 365 with Teams; an SMS gateway at three sites.

Volume

5,600 repair orders closed a month; 38% end with additional work proposed, about 2,128 proposals a month; roughly two "is it ready?" calls per order.

Current process

The adviser phones for every proposal and every collection; reception answers status questions on foot; the approval is a note on the job card; three sites text "car ready", six do not.

Bottleneck

About fourteen minutes of telephone per order; cars waiting one to three hours for a decision; a proposal in twenty released unanswered; no record of the price approved.

Solution

Order statuses in each DMS drive messages on the channel the customer chose at check-in; the proposal goes out with the technician's photo and the priced lines, is approved by a tap, and the answer lands on the order and in the ramp channel.

Potential outcome

In the modelled case the fourteen minutes fall to the exception share, cars wait minutes rather than hours, and every approval carries its time, channel and price. A model, not a client result.

Proposed solution

The DMS stays the system of record and the adviser stays the voice; what changes is who carries the news. Each repair order becomes a queue item in UiPath Orchestrator at check-in with the channel the customer confirmed, and robots watch its status in the brand's DMS, by API where offered and through the screen where not. Each announced status sends one of the group's approved texts, nothing generated and no AI involved.

The proposal is where the design earns its keep. The technician's photo reaches the order from the DMS technician app, or from the workshop tablet into the ramp channel in Microsoft Teams. The adviser prices the lines as today; the robot assembles photo, priced lines including VAT, her name and a link to a one-screen approval page on the group's domain. A tap calls an Orchestrator API trigger with a single-use token, writes the answer to the order and mentions the technician in the ramp thread.

Native capabilities used

UiPath Orchestrator queues, event and API triggers, credential stores; UiPath Integration Service connectors for Microsoft Teams and Microsoft Outlook 365; UiPath Action Center tasks completed inside Microsoft Teams; Power BI as a Teams tab

What we build

The order queue and status watcher per DMS, the message set with its channel and consent check, the proposal assembly, the approval page and token logic, the ramp-channel threads, the event log and Power BI model

Custom integration

Each brand's DMS (order status, quote lines, notes, attachments, invoice PDF) by API where offered, otherwise through the user interface with the robot's own account; the group's SMS gateway by API; ramp-channel photos through Microsoft Graph

How the automated process works

  1. AutomationCheck-in opens the order and the queue item; the adviser records the channel for this order, SMS to the number on the order or email, and the "checked in" message goes out
  2. PersonThe technician finds worn front discs, writes the recommendation on the job card and photographs the disc; the photo reaches the order through the DMS technician app or the ramp channel in Teams, tagged with the order number
  3. PersonThe adviser prices the lines in the DMS as a quote and sets the status to "additional work proposed"; anything above the group's threshold, or with a warranty or goodwill question, is held for her review
  4. AutomationBefore every message the robot checks the channel confirmed at check-in and that the text concerns this order only; offers and next-service reminders never come from this flow
  5. AutomationThe proposal goes out: photo, priced lines, the adviser's name, the approve-or-decline link; a thread opens in the ramp channel with order, ramp and time
  6. SystemThe customer taps; the API trigger starts the robot, which writes the answer with time, channel and address to the order and replies in the ramp thread, mentioning the technician
  7. PersonNo answer inside the window (45 minutes in the modelled case): a reminder on the same channel, then an Action Center task in Teams for the adviser, call, release without the work, or wait
  8. AutomationStatus "ready" sends the collection message with the invoice from the DMS attached; every event is logged with its time for the Power BI tab
AutomationPersonSystem

Human-in-the-loop model

Automation handles

  • Messages at each order status, on the channel the customer chose, about this order only
  • The proposal from the technician's photo and the adviser's priced lines, the approval link and the record of the answer
  • The ramp-channel thread, the go-ahead, the reminder, the escalation task when nobody answers
  • The event log and the per-workshop view in Power BI

People decide

  • What the car needs: the technician finds, photographs and recommends; nothing is diagnosed by a robot
  • What is proposed and at what price: the adviser, who can hold any proposal for a call
  • Yes or no: the customer, by tap or by phone; declines and questions stay with the adviser
  • The rules themselves: windows, thresholds and message texts stay with the aftersales director

Before and after

BeforeAfter
Finding to customer's answerone to three hours of calls and voicemailminutes, with most proposals answered inside the first window
Status calls per orderabout two, answered on foota message at each status; calls only from customers who prefer them
Record and price"tel. OK 12:35" on the job card, price first seen at the countertime, channel, photo and the price the customer saw before the work

Systems and integrations

Where a rule suffices we do not use a model. Where judgement is needed, a person decides.

Inputs

  • order status changes in each brand's DMS
  • the technician's photo from the DMS app or the ramp channel
  • the quote lines priced by the adviser
  • the channel confirmed at check-in

Automation layer

  • UiPath Orchestrator
  • UiPath Robots
  • UiPath Integration Service
  • UiPath Action Center

Target systems

  • the repair order in the DMS (status, notes, attachments)
  • SMS via the group's gateway or email via Microsoft Outlook 365
  • the event log read by Power BI

Human touchpoints: the customer's approval page; the ramp channel in Teams; Action Center tasks in Teams; the Power BI tab

order status changes in each brand's DMSUiPath OrchestratorUiPath Robotsthe repair order in the DMSthe customer's approval page

Technologies used

UiPath Robots + Orchestrator

one queue item per repair order; event triggers on status; API trigger for the customer's tap; credential store

A
UiPath Integration Service (Microsoft Teams, Microsoft Outlook 365 connectors)

ramp-channel threads and mentions; email and the invoice from the site's mailbox

A
UiPath Action Center in Microsoft Teams

the adviser's no-answer and hold-for-review tasks, completed inside Teams

A
Microsoft Teams

the ramp channel per workshop: waiting list, technician go-ahead, workshop manager's view

A
Power BI

minutes to answer, proposals answered before release, cars waiting, per workshop; as a Teams tab

A
The brand's DMS (repair order, quote lines, notes, invoice)

system of record; API where offered, otherwise the user interface

C
Approval page and SMS gateway

one-screen page on the group's domain with single-use tokens; the group's SMS provider by API

C
Averified product capability (vendor documentation)Cillustrative model — the figures on this page

Illustrative economic model

Start by questioning the assumptions.

Illustrative model
5,600 repair orders a month × 14 minutes of calls and status updates≈ 1,307 h / month
1,307 h × €22 fully loaded hourly cost≈ €28,750 / month
× 12 months≈ €344,960 / year
Adviser and reception time released per year (illustrative)≈ €344,960

Not every repair order costs a phone call, and the ones with additional work cost four; fourteen minutes is the blend across all 5,600 orders a month: dialling attempts and the call back on the 38% with a proposal, two "is it ready?" calls, and the collection call. €22 is a fully loaded hourly cost blended across advisers and reception in Poland. Nothing was measured at a client, and the rows price released time rather than posts removed.

Run the numbers on your data

hours released per month
of annual capacity released

An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.

Business benefits

  • The car leaves the ramp on the customer's answer, not on the adviser's next free minute; in the modelled case the yes arrives while the wheel is still off
  • The customer sees the photo and the price before the work; the invoice matches what was approved, and the approval is written against the order with time, channel and address
  • The adviser's day moves from dialling to the conversations that need a person: declines, questions, goodwill
  • The importer's after-visit survey, which feeds the bonus, finds a customer who was told everything

The management view

  • Nine workshops on one page: cars waiting for a decision, minutes waiting, proposals sent and answered today, by ramp and adviser
  • Approval discipline lives in the record, not in memory: what was proposed, at what price, who approved it and when
  • Additional work proposed per order, and the share approved before release, become numbers per workshop

Board-level KPIs

minutes from proposal to answershare of proposals answered before the car leaves the rampstatus calls per orderadditional-work lines approved before collectionthe importer's after-service survey result

Security and governance

The automation holds exactly the rights it needs, and not one more.

  • The robot's DMS account reads orders and writes notes, attachments and communication status for its own workshops; it cannot price, invoice or credit, and its password is fetched at run time from the vault
  • The approval link carries a single-use token bound to one order and one proposal; the page shows the last characters of the plate, the lines and the price, not the customer's name
  • Messages go only to the channel confirmed at check-in and speak only about this order, which is performance of the order rather than marketing; offers, reminders and surveys belong to the consent flow with its suppression list
  • The queue carries order number, lines, channel and token while name and address stay in the DMS; robots run from the EU region of UiPath Automation Cloud, Teams and Power BI stay in the group's tenant, and every proposal, answer and release keeps its history in Orchestrator and a note on the order

Why now

01

Customers get a photo and a status line from the courier and the bank, and the workshop is judged by that standard in the importer's survey the day after the visit; the base grows, with 597,400 new passenger cars registered in Poland in 2025, 8.3% more than in 2024 (PZPM and KPMG, February 2026)

02

The modelled €28,750 a month is adviser and reception time spent dialling; the ramp hours, the proposals released unanswered and the discount at the counter are not in that figure

03

The pieces are standard: Action Center tasks completed inside Microsoft Teams, the Integration Service Teams connector, an Orchestrator API trigger for the tap; the custom work is the DMS connection per brand and one approval page

Relevant executive roles

Aftersales Director

Additional work stops depending on whether a call connected; approvals, waits and declines become numbers per workshop

Site Director

The customer the importer surveys was told at every step and saw the price before the work; the argument at the counter has a record

Group CFO

Adviser time moves from dialling to selling, ramp hours stop waiting for voicemail, and the additional-work revenue that used to leave with the car is counted

Common questions and objections

Our DMS already sends a text when the car is ready.

Good, and the flow keeps it, so nothing is sent twice. That text does not carry the photo and the priced lines, record the tap against the order, or tell the technician in Teams that he can continue.

Customers approve more when an adviser explains it on the phone.

Some do, and the adviser still calls whoever the rules say: proposals above the threshold, customers who asked for one, anyone silent beyond the window. The simple yes stops waiting for a free minute.

Is a tap on a link a valid approval of paid work?

Whether your terms treat it as a binding order is for your counsel to confirm, and we ask for that during design. What the flow guarantees is the evidence: the customer saw the lines and the price, and the tap is recorded with time and token before the invoice exists.

When this is not the right solution

  • A single workshop where the adviser stands next to the ramp and most customers wait in the lounge; a walk to the sofa beats any message
  • The DMS exposes neither an API nor a stable screen for order status and quote lines, so the trigger would be the adviser retyping the proposal into a form, which moves work rather than removing it
  • Most orders are fleet or leasing vehicles authorised by the fleet operator through its portal; the driver does not decide, and the operator's channel comes first

A question for the next management meeting

Take yesterday's additional-work proposals across our nine workshops: how many were approved before the car left the ramp, how many were never answered, and which document shows what each customer agreed to?

Implementation approach

We start with one slice of the process and extend only once it is proven.

We deliver

  • Discovery at two workshops of different brands: the order life cycle in each DMS, the adviser's telephone day and a month of orders with their additional-work lines
  • The message set per status and channel in the group's wording, with the consent rules written down
  • The status watcher per DMS, the proposal assembly and the approval page with single-use tokens
  • The ramp channel in Teams with waiting list and go-ahead, and the adviser's exception tasks in Action Center
  • The event log and the Power BI tab per workshop, with settings for windows and thresholds

We need from you

  • Two months of repair orders from two sites, with additional-work lines, approval notes and the call log where one exists
  • An aftersales director owning texts and thresholds, a senior adviser for the pilot, and your counsel's confirmation of the approval wording
  • Robot accounts for each brand's DMS, the site mailboxes, the SMS gateway and Teams

Stages

Discovery

Order life cycle per DMS, the adviser's day, current texts and channels

Design

Message set, channel and consent rules, thresholds and windows, permissions

Build

Status watchers, proposal assembly, approval page, Teams channel and tasks, Power BI tab

Pilot

One workshop, one brand, a full month alongside the telephone

Rollout

The remaining workshops by brand, with hypercare and the settings handed over

Quick win. Effort depends on whether each DMS exposes order status and quote lines by API or only on screen, and on how many brands are in scope.