Home · Solutions · Customer service
Solution · Customer serviceNo ticket gets lost in the back room, and the date promised to the customer watches itself
Service tickets from drop-off to pickup
A robot runs every ticket: a number and a receipt at drop-off, a queue ordered by promised dates, an alert when a repair waits for parts longer than it should, a text when it is ready, and a reminder when nobody collects. The back room stops being a black box.
Executive summary
Tickets live on slips pinned to the equipment and in a notebook; dates promised at the counter are watched by nobody, parts are ordered from memory, and the customer learns anything only when he calls.
Every ticket gets a number, a date and a queue position; the robot watches promised dates and parts, texts at status changes and reminds about pickup; the technician sees his queue, the owner the whole one.
Equipment stops going missing, promised dates are kept or renegotiated in advance, “what about my repair” calls all but vanish, and the shelf of finished items clears.
the ticket register in SharePoint; texts to customers; the repair queue in Microsoft Teams; the parts order list
Business problem
A slip pinned to a bicycle
A small repair shop, bikes, appliances, power tools, takes equipment in at counter pace: the customer describes the fault, someone writes it on a slip, the slip travels with the item to the back room. The date is given at the counter, out of courtesy and experience: “should be ready Wednesday”. From that moment everything depends on the slip surviving and Wednesday reminding itself.
The back room runs on its own logic: what gets fixed is whatever is nearest, whatever is simple, and whatever the customer is currently shouting about on the phone. A ticket waiting for a part drops out of circulation entirely: the part “will get ordered”, and then the item stands a week because nobody knows the courier already came. Finished equipment can stand for days more, because the call to the customer is a task that can always be done tomorrow.
Throughout all this the customer knows exactly nothing. So he calls, and every call is a technician torn from a repair to hunt for a slip and establish which stage the item is at. The more traffic, the more calls, the less time for repairs, the longer the queue: a spiral every shop knows from peak season.
What remains at the end is a shelf of uncollected items and a notebook where some entries end in a question mark. How many repairs were invoiced, how many customers will return after calling three times, nobody knows. All that is known is that the season was rough.
How it works today
Below is what the work looks like before anything is automated.
- PersonIntake on a slip pinned to the item; the date promised verbally at the counter
- Risk of errorThe queue follows whatever is nearest and whoever calls loudest, not the dates
- WaitingA ticket waiting for a part drops out of circulation; nobody knows the courier came
- Risk of errorFinished equipment sits on the shelf, because the call can always be made tomorrow
- PersonThe customer calls; the technician hunts for the slip instead of repairing
- Risk of errorThe uncollected shelf grows; notebook entries end in question marks
Why the current process costs more than it appears
The bill that never shows up in a budget.
- Every “what about my repair” call takes minutes out of a technician’s repairing; in season that is hours a day.
- A promised date missed costs more than a long date kept: the customer plans around the promise.
- A finished item on the shelf is frozen payment and occupied space; an uncollected one can be a total loss.
- A part not ordered in time stretches a repair by a week, and the queue grows by everyone waiting behind it.
Cost of inaction
Any shop can verify the first row with tally marks by the phone in one week. The second shows in season: a repair that could take three days takes ten, because the part was ordered only at the customer’s second call.
The model does not price the customers who simply do not return after a season of calls and slippage; that line is the largest and uncountable.
A model organisation with realistic proportions – the numbers exist so you can run the same maths on your own data; they are not a client result.
A bike service shop with a seasonal peak: three technicians, an intake counter, around 210 tickets a month in season, Microsoft 365.
Intake on slips, an intuitive queue, parts ordered from memory every few days, dates promised at the counter.
In season a dozen or more status calls a day; finished equipment waits two days on average for the customer call.
After the season a dozen uncollected items remain on the shelf, and the notebook is full of question marks.
Intake creates a ticket with a number and a customer receipt; the queue orders itself by promised dates; the “waiting for part” status adds a line to the order list and watches its age; “ready” sends a text, and a reminder follows after two days; the owner sees the queue and bottlenecks in Teams.
In the modelled case status calls fall by three quarters, promised dates are nearly always kept or renegotiated early, and the finished shelf clears within a day. Model numbers, not the shop’s records.
Proposed solution
We start with your workflow: which statuses a repair has, what a promised date means and when one may be promised, how and from whom you order parts. Those rules exist today in counter practice; we write them down, and from then on the system watches them, not memory.
Intake takes a minute: the item, the fault in the customer’s words, contact, a promised date suggested from the queue’s load, the ticket number on a receipt and a label. The back-room queue orders itself by dates, not by what is nearest; the technician sees his list on a tablet and flips statuses with one tap. The “waiting for part” status immediately adds a line to the order list, and the robot makes sure no line sits there longer than you agreed.
The customer gets a text at intake, at readiness, and a reminder after two days; between those points he has no reason to call, because nothing changes for him. The owner sees the queue, the bottlenecks and the repairs at risk of their date in Teams, before the customer finds out. After the season a register remains: what, when, for how much and whether collected, instead of a notebook of question marks.
UiPath Orchestrator: the ticket queue, date and part-age watching, reminders, retries and an audit trail; UiPath Integration Service connectors for Microsoft Teams, Outlook 365 and SharePoint; the SMS gateway you already use
A ticket register with numbers and receipts, a queue by promised dates, a parts list with age watching, status texts and pickup reminders, and a bottleneck view for the owner
The register in SharePoint; a back-room tablet with one-tap statuses; ticket number labels; the SMS gateway via API
How the automated process works
- PersonIntake in a minute: a numbered ticket, a receipt for the customer, a label on the item
- AutomationThe queue orders itself by promised dates; the technician sees his list on a tablet
- AutomationThe “waiting for part” status adds a line to the order list and watches its age
- Automation“Ready” texts the customer; no pickup within two days triggers a reminder
- PersonThe owner sees bottlenecks and at-risk repairs in Teams before the customer calls
- SystemAfter the season a register remains: what, when, for how much, collected or not; no question marks
Human-in-the-loop model
Automation handles
- The queue by dates, parts watching and at-risk repair alerts
- Status texts, pickup reminders and the register of every ticket
- The bottleneck view and weekly numbers for the owner
People decide
- The repairs, diagnoses and estimates themselves; the automation runs the flow, it does not true wheels
- Customer conversations in atypical cases and priority decisions
- The dates promised at the counter; the system suggests from the load, a human decides
Before and after
Systems and integrations
The stack is short on purpose: one engine, one execution layer, one place where a person decides.
Inputs
- tickets from the counter with promised dates
- statuses from technicians’ tablets
- the parts and supplier list
- date and reminder rules
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- the ticket register with history and receipts
- status texts and reminders with a record
- the queue, bottlenecks and numbers in Microsoft Teams
Human touchpoints: the queue and bottlenecks in Microsoft Teams; at-risk cases with the owner; weekly numbers
Technologies used
the ticket queue, date and part alerts, retries, a record of every change
Aqueue views, cases, register writes
Athe ticket, parts and history register with permissions
Astatuses and reminders; we work with the gateway you already use
Bthe ticket number on the item and in the customer’s hand; any printable model
BIllustrative economic model
Numbers you can check against your own data.
The model prices the call time and the shortened repairs; it does not price the customers who come back because this time it felt human. Volumes and rates belong to the scenario; your own numbers go into the calculator alongside.
Run the maths on your data
An illustrative estimate based on your inputs. It models freed capacity, not promised savings.
Business benefits
- No ticket goes missing; each has a number, a date and a queue position
- Promised dates are kept, or renegotiated before the customer gets angry
- Technicians repair instead of hunting slips and answering calls
- Parts order themselves from the queue, not from memory; repairs stop standing for weeks
- The finished shelf clears itself: a text, a reminder, a pickup
The management view
- The shop’s flow stops depending on counter memory and slip survival
- The season stops being a call spiral; more tickets do not mean more chaos
- The post-season register is knowledge: repair times, bottlenecks, the most common faults
Board-level KPIs
promised dates kept · status calls per day · age of lines on the parts list · time from ready to pickup · tickets with incomplete data
Security and governance
The automation has exactly the permissions it needs. Not one more.
- The robot works on ticket data: item, fault, contact, dates, amounts; nothing beyond that
- The register has permissions and history; every status change has an author and a time
- Texts have a record: what, when, to whom; you approve the wording
- Customer data is kept as long as you decide, and nowhere else
- Data stays in your Microsoft 365 tenant and your SMS gateway; the robots run in the EU region of UiPath Automation Cloud
Why now
Customers track parcels by the hour; a shop silent for three days reads worse than it deserves.
Seasonal peaks grow while hands do not; surviving the season without chaos is now a competitive edge.
A technician’s hour keeps getting dearer; spending it hunting slips has stopped making sense.
Relevant executive roles
Sees the queue and bottlenecks before they become calls; after the season has a register instead of question marks
Repairs off a tablet list; flips statuses with one tap
Gets a number, a ready text and a reminder; no need to call or remember
Common questions and objections
The machine does not order the repairs, it watches the promises: it sorts the queue by the dates you yourselves gave customers, and alerts when one is at risk. What to pick up first within the day remains the technician’s call; the difference is he sees all the dates, not just the nearest slips.
And you still can: priority is a field on the ticket, not an exception to the system. The difference is that fast-tracking one ticket immediately shows which other dates will shift, so the promises made to other customers stay real.
And nothing more is needed: a phone number for the texts suffices, and the receipt with the ticket number replaces an account. The whole process works for a walk-in exactly as for a regular.
When this is not the right solution
- A one-man shop with a few repairs a week: a notebook and keeping one’s word suffice
- No team commitment to tablet statuses: without them the register dies like the slips
- Expecting the automation to diagnose the fault or price the repair: that remains a craft
A question for the next management meeting
How many items sit in our back room longer than we promised, and which of them calls tomorrow?
Implementation approach
Scope without ambiguity, before anything is signed.
We deliver
- A ticket register with numbers, receipts and labels
- A queue by promised dates with risk alerts
- A parts list fed from statuses, with line-age watching
- Status texts and pickup reminders in your tone
- Owner views in Teams and two weeks of parallel running
We need from you
- Your repair workflow and date-promising rules; we write them down together
- An SMS gateway and a back-room tablet
- The parts supplier list and the way you order today
Stages
Discovery
The flow today: intakes, the queue, parts, calls, the uncollected shelf
Rules
Statuses, date rules, alert thresholds, text wording
Build
The register, the queue, the parts list, texts, Teams views
Parallel run
Two weeks: the system and the slips side by side, calls and slippage counted
Go-live
Full traffic before the season; a numbers review after the first month
A quick win. Everything runs on Microsoft 365 and your SMS gateway; best closed before the season, because it pays back fastest at the peak.
Thursday, 4:40 p.m.: a customer at the counter for the bike promised for Wednesday. The bike stands untouched, because the part “is being ordered”. Since Monday.
Describe your shop: how many tickets in season, what intake looks like, how much equipment sits in the back room right now. We return a workflow design and the arithmetic of the hours leaking into calls and hunting.
Check what sits in your back room todayThe neighbouring process usually has the same problem
The customer calls a third time asking about his car, and the mechanic crawls out from under the lift again.
See the solution Customer serviceOne inbox instead of four channelsEmail, Messenger, phone and a form. Four places where the customer could ask the same question.
See the solution Customer serviceMissed calls called backHe called three times during opening hours. He booked where someone picked up.
See the solutionIndustries where we deploy this most oftenSmall business & services