Home · Solutions · Operations & quality
Solution · Operations & qualityEvery piece of gear has a status, and a booking never promises a bike that will not be there
Rentals: bookings, deposits, inspections
A robot keeps the fleet register: free, reserved, with a customer, in service. Bookings check availability for real, deposits and handover reports record themselves, servicing speaks up via the rental counter, and overdue returns get an automatic reminder.
Executive summary
Gear availability lives in staff heads, bookings in the phone and messages, deposits in a notebook, and service dates in memory; the season turns all of it into chaos that costs equipment and customers.
The register gives every piece a status and a history; a booking checks availability for real, issue and return are a phone-based report, the deposit has a record, and the rental counter calls gear in for service by itself.
Double bookings disappear, overdue returns get reminders, gear stops vanishing from the records, and the owner sees each category’s utilisation and knows what to buy and what to sell.
the fleet register in SharePoint; the booking calendar; issue and return reports; SMS reminders; reports in Microsoft Teams
Business problem
Three notebooks and two heads
A rental shop manages a fleet; it just never calls it that. Dozens or hundreds of pieces, each with its own condition, repair history and location, circulate between customers, the workshop and the shop’s locations. In season that carousel spins from morning till night, and the only system is often a bookings notebook, a deposits notebook and the owner’s memory.
A phone booking promises gear whose availability nobody truly checked: the calendar does not know two of the five bikes are in the workshop and a third left yesterday for a week. The customer arrives, the gear is not there, and that is precisely the kind of disappointment that ends up in the reviews. The reverse is worse: gear stands idle because nobody knows it came back.
Deposits and handover reports are a chapter of their own: cash noted in a notebook, the gear’s condition at issue described with the word “fine”, the return accepted on the run without a look. When a customer hands back a cracked frame, the dispute runs without evidence. And service dates, from brakes to bindings, exist mostly as a guilty conscience: what gets serviced is what broke, not what was due after thirty rentals.
Meanwhile the owner cannot answer the simplest business questions: which categories earn, what stands dead, how much gear is overdue and since when. Fleet purchases are decided by feel, mid-season, which is the most expensive way.
How it works today
Below is what the work looks like before anything is automated.
- PersonBookings taken by phone into a notebook, with no real knowledge of availability
- Risk of errorDouble bookings and empty promises surface only at pickup
- PersonCash deposits noted in a notebook; the issue report is the word “fine”
- WaitingReturns accepted on the run; gear goes back on the rack with no inspection and no status change
- Risk of errorServicing happens when something breaks; a rental counter does not exist
- Risk of errorOverdue returns get noticed when someone asks about that particular item
Why the current process costs more than it appears
The bill that never shows up in a budget.
- Gear “somewhere” is frozen capital: it earns nothing, and often it simply never comes back.
- A double booking costs twice: the lost customer, and the review that scares off the next ones.
- A return without a report means every damage is a dispute without evidence, usually a lost one.
- Reactive servicing is dearer than planned servicing, and gear breaks in season, exactly when it earns most.
Cost of inaction
The figures come from a mid-sized model rental shop; in real life the first line is easiest to check: compare what was bought with what is left after the season. The second line is sales lost to availability chaos: harder to measure, but every owner knows its taste.
The model does not count staff time lost to notebook shuffling and explanatory phone calls; at several hundred rentals a month that is another few dozen hours.
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 and watersports rental in a tourist town: 140 pieces in four categories, two locations, a seasonal team, Microsoft 365.
Around 520 rentals a month in season; bookings by phone and social media; a bookings notebook and a deposits notebook; servicing by conscience.
The post-season stocktake shows losses every year; some gear stands idle while customers are turned away.
Damage disputes run without evidence; deposits get returned for lack of arguments.
The register gives every piece a number and a status; a booking from any channel checks the fleet calendar’s real availability; issue and return are a phone report with photos and a signature; the deposit has a record and a status; the rental counter calls gear in for service; an overdue return triggers a text.
In the modelled case post-season losses fall by most, double bookings disappear, and fleet utilisation rises because gear stops standing “somewhere”. Model numbers, not the shop’s records.
Proposed solution
We start with a stocktake and the register: every piece gets a number, a category, a status and a history. That foundation is laid once, and from then on a status changes only through an operation: booking, issue, return, service. Gear loses the ability to vanish without trace, because every change has an author and a time.
Bookings, whether from the phone, the website or messages, land in one fleet calendar that knows true availability: it knows what is in the workshop, what is with a customer and what returns on Thursday. Issue is a report on the staff phone: photos, condition, deposit, signature; return is the same report in reverse. A dispute about a cracked frame ends with the issue photo, not a shouting match.
The rental counter and calendar watch the servicing: a bike due after its thirtieth rental reports to the workshop before it breaks in a customer’s hands. Overdue returns get an automatic text, and the owner sees weekly utilisation per category: what earns, what stands, and what to buy before the season’s peak rather than in the middle of it.
UiPath Orchestrator: an operations queue, reminder and service schedules, retries and an audit trail; UiPath Integration Service connectors for Microsoft Teams, Outlook 365 and SharePoint
A fleet register with statuses and history, a booking calendar that knows real availability, issue and return reports, a deposit ledger, service counters and overdue alerts
The register and reports in SharePoint; the report form on the staff phone; reminders via an SMS gateway; online bookings via Bookings where you choose to open them
How the automated process works
- SystemEvery piece has a number, a status and a history; a status changes only through an operation
- AutomationA booking from any channel checks real availability in the fleet calendar
- PersonIssue and return are a phone report: photos, condition, deposit, signature
- AutomationThe rental counter calls gear in for service before it breaks with a customer
- AutomationAn overdue return triggers a text reminder past the return date
- PersonThe owner sees weekly category utilisation and the exception list
Human-in-the-loop model
Automation handles
- Every piece’s status and history, the availability calendar and overdue alerts
- The deposit ledger and the completeness of issue and return reports
- Service counters and the weekly fleet utilisation report
People decide
- Inspecting gear at issue and return; the report only records it
- Decisions on disputed deposits, repairs and retiring gear
- Pricing policy, fleet purchases and booking rules
Before and after
Systems and integrations
The stack is short on purpose: one engine, one execution layer, one place where a person decides.
Inputs
- the fleet register with numbers and statuses
- bookings from all channels
- issue and return reports from the phone
- service and deposit rules
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- real availability in the fleet calendar
- the deposit ledger and photo reports
- overdue alerts and the utilisation report in Microsoft Teams
Human touchpoints: exception cases in Microsoft Teams; a weekly utilisation report; a rules review before every season
Technologies used
the operations queue, service and reminder schedules, a record of every status change
Aalerts, reports, register and report writes
Athe fleet, deposit and report registers with versions and permissions
Aonline bookings tied to real availability, if you choose to open them
Areturn reminders and booking confirmations; we work with your gateway
BIllustrative economic model
Numbers you can check against your own data.
The model counts equipment losses and sales lost to availability chaos; it does not count staff time or the value of calm at peak season. Volumes and amounts 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
- A booking promises only gear that will really be there; double bookings vanish
- Deposits and gear condition have a record; disputes end with a photo, not a row
- Servicing happens on plan, so gear breaks less, and not in customers’ hands
- Overdue gear comes back after a text, not after someone notices the gap
- The owner sees which categories earn, and buys fleet on data, not feel
The management view
- The fleet becomes a managed asset with a history, not a herd of gear with unknown fates
- A second location or a new category is register entries, not new chaos
- A seasonal hire gets a process on a phone instead of three notebooks and folklore
Board-level KPIs
gear with unknown status · double bookings · returns past the due date · services done on plan · fleet utilisation per category
Security and governance
The automation has exactly the permissions it needs. Not one more.
- The robot works on operational data: gear, statuses, dates, deposits; customer data within the rental agreement’s scope
- Photo reports have restricted access and a retention period you set
- Every status change has an author, a time and a source operation
- The deposit ledger separates roles: staff record, the owner settles
- Data stays in your Microsoft 365 tenant; the robots run in the EU region of UiPath Automation Cloud
Why now
Gear prices have jumped; every lost piece hurts more than it used to, and the fleet is real capital now.
Customers book online with your competitors and expect certainty the gear will be there; a notebook cannot give it.
Seasonal staff change every year; a process on a phone is learned in an hour, notebook folklore in a week.
Relevant executive roles
Knows where every piece is and what it earns; buys and sells fleet on data
Issue and accept gear with a phone report, without notebooks and guesswork
Gets gear for service on plan, not broken at peak season
Common questions and objections
The phone report takes less time than a notebook entry: four photos, a tap, a finger signature. And the time truly missing in season is eaten today by explanatory calls, gear hunts and deposit rows; those are what disappear.
Which is exactly why there is one register, and the status knows the location: a transfer between locations is an operation like any other, with an author and a time. The availability calendar sees both locations, so a booking can promise gear where it will really be.
A report protects both sides and is read that way: the customer gets proof he returned the gear whole, and certainty nobody will pin someone else’s damage on him. For regulars the process can be trimmed to a minimum; the level of formality stays your decision.
When this is not the right solution
- A dozen pieces and one location: a decent notebook and discipline suffice
- No agreement to a one-off numbered stocktake: without the foundation the register cannot start
- Expecting the system to recover gear lost in past seasons: history before the register stays history
A question for the next management meeting
How many pieces of our gear are “somewhere” right now, and how many of them will we ever see again?
Implementation approach
Scope without ambiguity, before anything is signed.
We deliver
- The opening stocktake and a fleet register with statuses and history
- A booking calendar that knows real availability, with optional online bookings
- Phone-based issue and return reports with photos and a deposit ledger
- Service counters and overdue alerts with SMS reminders
- A weekly utilisation report and two weeks of parallel running
We need from you
- One day for a joint stocktake and gear numbering
- Your rules: deposits, return dates, service intervals per category, report formality level
- An SMS gateway and access to the channels you take bookings through
Stages
Discovery
The fleet, locations, booking channels, the scale of losses and disputes
Stocktake
Gear numbering, opening statuses, categories and service rules
Build
The register, the availability calendar, reports, deposits, alerts and reporting
Parallel run
Two weeks: the system and the notebooks side by side, agreement compared
Go-live
The register takes over the fleet; a rules review before the season
A departmental project: it covers the whole gear cycle, so it needs a one-off stocktake and a week of team discipline; the technology itself runs on the Microsoft 365 you already have.
Saturday, 10 a.m.: a customer with a booking for two bikes that are not there. Yesterday’s page is missing from the deposits notebook. The season is on.
Describe your rental shop: how many pieces, how many rentals in season, what the last stocktake showed. We return a register design and the arithmetic of the losses you can stop before the next peak.
Check where your gear is todayThe neighbouring process usually has the same problem
The autoclave, the extinguishers, the liability policy and staff check-ups expire in different calendars.
See the solution Finance & accountingInvoices chased before they turn difficultThe client pays after 40 days because nobody reminded after 14. The cash sits with others.
See the solution Management & planningUtilisation of lanes, rooms and studios, weeklyEvenings burst at the seams, mornings stand empty, and the price list has been one for years.
See the solutionIndustries where we deploy this most oftenSmall business & services