The seller wrote an email with sale value, payment terms and pickup date. The manager approved on the thread. Legal drafted the contract and got it signed. Finance confirmed on the thread, keyed the sale into the system and issued the transfer authorisation. Seven or eight emails, each waiting on the previous one, and nobody could see where the sale was.
Seven emails became one click
A vehicle rental and fleet-outsourcing company replaced approval chains that ran on email through five or six departments, maintenance tracked in spreadsheets and chat notes, and counter requests that generated a hundred messages a day with a system where a sale, a repair or a transfer is a record that moves, and the people who need to act are told on their phones.
The recorded interview is undated. The public video was published in February 2025. At the time of the interview the fleet was about 3,500 vehicles; the company site now reports more than 4,000. Everything below describes the operation as it was at the time of the interview.
A vehicle rental and fleet-outsourcing company whose assets only earn while they move.
Citycar rents vehicles and runs outsourced fleets for companies. Every vehicle is bought, insured, maintained, repaired, moved and eventually sold. Each of those events involves several departments and usually a third party.
Vehicle rental and fleet outsourcing
3,500Vehicles in the fleet at the time of the interview
7People on the maintenance team, first for about 2,000 vehicles and still for about 3,500
WhatsAppChannel to approvers, customers and carriers; the system now writes the message
2025Year the public recording was published
About 3,500Vehicles in the fleet at the time of the interview; the company site now reports more than 4,000Operations lead, in the recorded interview; the company site now reports more than 4,000.
7People on the maintenance team, first for about 2,000 vehicles and, by the operations lead, still for about 3,500Recorded interview; self-reported, no measurement method.
100 to 120Emails a day the counter no longer generates, by the team arithmetic: about 30 requests a day, three to five messages eachRecorded interview; the team's own estimate.
7 to 8Emails a vehicle sale used to take before finance could act; now one clickRecorded interview; the operations lead's own count.
“That process was slow, took a lot of hands and had very little control. Today it's all automated and all traceable, from the sale being registered to the transfer document being closed: automatic authorisations, automatic contract, automatic signature, automatic to finance.”
Christian LimbergerOperations lead, in the recorded interview
BeforeAfter
- Sale written up in an email and approved on the threadSale registered as a record; the approver gets a WhatsApp notification and confirms with one click
- Legal drafts the contract and chases the signatureContract generated automatically and sent for signature automatically
- Finance confirms by email, then keys the sale into the systemFinance notified automatically on confirmation; the transfer authorisation is generated when payment is confirmed
- Reserve-vehicle request by email between maintenance and logisticsOne click from the maintenance screen; the request is tracked to completion
- Counter requests by email and memoryA kanban the counter team marks as each request completes
- Maintenance in spreadsheets and chat notesMaintenance as records with required fields, SLA tracking, approvals and supplier quotes inside the record
- Customer messaged by hand at each repair stageStatus messages sent automatically through the messaging integration
- Supplier quotes by emailQuote requests sent from the record; quotes submitted through a public link; team notified on arrival
- Transfers requested by messageA transfer pipeline from request to delivery, filtered by delivery date and category
- Vehicle handovers with no standard recordA mandatory checklist with plate, odometer, fuel, photos and signature on every movement
What was not replaced. WhatsApp stayed as the channel; the system writes the message. The rental and finance system of record stayed. Workshops and carriers stayed as external parties and now interact through links and forms. The approval itself stayed a human decision; what changed is where it arrives and how many steps it takes.
The bottleneck was operational, not commercial
Citycar rents vehicles and runs outsourced fleets for companies. The group started in vehicle retail, added rental under an international franchise in 2006, and launched its own rental brand in 2017 with about a thousand cars. Its main business today is monthly rental and fleet management for corporate customers, with a rent-a-car counter at head office and branches across its region; the company site reports a fleet of more than four thousand vehicles and more than three thousand registered suppliers. At the time of the interview the fleet was about 3,500.
A rental fleet is a set of assets that only earn while they move. Every vehicle is bought, insured, maintained, repaired after damage, moved between branches and customers, and eventually sold. Each of those events involves several departments and usually a third party: a workshop, a carrier, a buyer. The number of vehicles multiplies each event, and a vehicle waiting for an approval or a quote is a vehicle not earning.
That is why the bottleneck was operational and not commercial. The company was growing its fleet. What it lacked was a way for one department's action to reach the next without an email, and a way to see where each vehicle and each request stood without asking. The operations lead's own summary: the process was slow, needed a lot of hands, and had very little control.
Every process depended on a person remembering to send the next message
“That process was slow, took a lot of hands and had very little control. Today it's all automated and all traceable, from the sale being registered to the transfer document being closed: automatic authorisations, automatic contract, automatic signature, automatic to finance.”
A reserve-vehicle request went from maintenance to logistics by email and came back the same way. The counter handled about thirty requests a day, each generating a short exchange: the car is ready, received, picked up. People forgot to mark the shared file; requests were missed.
Spreadsheets held some of it. A sales-pipeline tool held the rest, but with no custom fields, so the controls lived in chat notes on each card. The team messaged each customer by hand at every stage. Supplier quotes came by email and waited for a click.
Moving a vehicle to or from a customer meant a message to whoever handled freight, a quote by email, and no view of what was pending, quoted or on the road.
The pattern: every process worked, and every process depended on a person remembering to send the next message. As the fleet grew, the number of messages grew with it, and so did the chance that one of them was not sent. The company's own diagnosis was that growth had made the manual version untenable, and that the fix had to start with mapping the processes, because there was no point automating a process nobody had written down.
Item by item, what did each job before and what does it today
| What did this before | What does it today |
|---|---|
| Sale written up in an email and approved on the thread | Sale registered as a record; the approver gets a WhatsApp notification and confirms with one click |
| Legal drafts the contract and chases the signature | Contract generated automatically and sent for signature automatically |
| Finance confirms by email, then keys the sale into the system | Finance notified automatically on confirmation; the transfer authorisation is generated when payment is confirmed |
| Reserve-vehicle request by email between maintenance and logistics | One click from the maintenance screen; the request is tracked to completion |
| Counter requests by email and memory | A kanban the counter team marks as each request completes |
| Maintenance in spreadsheets and chat notes | Maintenance as records with required fields, SLA tracking, approvals and supplier quotes inside the record |
| Customer messaged by hand at each repair stage | Status messages sent automatically through the messaging integration |
| Supplier quotes by email | Quote requests sent from the record; quotes submitted through a public link; team notified on arrival |
| Transfers requested by message | A transfer pipeline from request to delivery, filtered by delivery date and category |
| Vehicle handovers with no standard record | A mandatory checklist with plate, odometer, fuel, photos and signature on every movement |
What was not replaced. WhatsApp stayed as the channel; the system writes the message. The rental and finance system of record stayed. Workshops and carriers stayed as external parties and now interact through links and forms. The approval itself stayed a human decision; what changed is where it arrives and how many steps it takes.
The chain, end to end, for one used-vehicle sale
- 1The seller registers the sale with value, payment terms, pickup date and buyerPerson
The system cannot know a sale was agreed until a person says so.
- 2The approver receives a WhatsApp message that a sale is pending, opens it, checks the details and confirmsPerson, one click
One click on a phone instead of finding a thread.
- 3The record moves to confirmed; finance is notified; the contract is generated and sent for signatureAutomatic
Routing, contract and signature request run without another email.
- 4The buyer signsExternal
An external party, on the document the system already sent.
- 5Finance confirms payment on the recordPerson
The system cannot know a payment arrived until a person says so.
- 6The transfer authorisation is generated and the vehicle is written out of the fleetAutomatic
Write-off follows confirmation, not a further thread.
- 7At pickup, the buyer or driver completes the checklist: plate, odometer, fuel, photos, signaturePerson
The system cannot know a car left the yard until a person at the gate says so.
- 8The checklist is stored on the vehicle's record for any later dispute over fines or damageAutomatic
The company asked for a custom signature field to make the checklist fast enough; Jestor built it in two weeks.
The hard links are 1, 5 and 7. The system cannot know a sale was agreed, a payment arrived or a car left the yard until a person says so. The design does not remove those people; it removes everything between them. The seller fills one record instead of writing one email; the approver clicks on a phone instead of finding a thread; the person at the gate fills a checklist that took the company a custom signature field to make fast enough, which Jestor built in two weeks when the company asked.
“We had seven people in maintenance looking after 2,000 cars. Today we have the same seven people for 3,500. When we reach 5,000 we might need one or two more at most. That's the point of these automations: less manual work, so we can scale with the same team.”
Every change, with the basis beside it
| Indicator | Result | Where it comes from |
|---|---|---|
| Sale approval | From seven or eight emails through five or six departments to one click from a phone notification | Recorded interview; the operations lead's own count |
| Counter communication | About 100 to 120 emails a day no longer written, by the team's arithmetic | Recorded interview; estimate from about 30 requests a day at three to five messages each |
| Maintenance headcount | Seven people for about 2,000 vehicles, still seven for about 3,500 | Recorded interview; self-reported, no dates or method |
| Maintenance visibility | From chat notes to records with required fields, SLA and downtime measured from the customer's workshop check-in | Recorded interview |
| Handover control | From no standard record to a mandatory checklist with photos and signature on every movement | Recorded interview |
No measured time or cost figure exists. The interview gives counts the team did in its head: emails per sale, requests per day, people per vehicle. None was measured against a baseline and none is given with a date. This write-up reports them as the team's own estimates and does not turn them into hours or money.
The headcount figure is the strongest claim and the least documented. Seven people for 2,000 cars and seven for 3,500 is a 75% increase in vehicles per person. It is plausible for the processes described and it is the operations lead's own statement; nothing in the interview shows when the count was taken or what the maintenance workload per vehicle was at either point.
"Automatic" starts after the click. The approval is a person, the payment confirmation is a person, the checklist is a person. What was automated is the routing, the contract, the signature request, the notifications and the write-off. The chain is fast because the human steps are one action each, not because they were removed.
The fleet figure is undated. The interview says about 3,500; the company's site says more than 4,000 today. The interview is treated as earlier and its figure is used only for the maintenance comparison it belongs to.
What this case does not measure
Worth naming, because it is usually what gets inflated.
All descriptions and both quotes come from the operations lead and the company's data analyst in a recorded interview. No process was independently observed or timed.
Downtime per vehicle before and after, cost per repair, approval cycle time in hours, transfer cost: none appear in the source. The SLA and downtime the team now measures are not reported.
Emails per sale, requests per day, headcount per vehicle: each is a count the interviewees did in conversation. Where the arithmetic is theirs, the write-up says so.
Several passages were reconstructed from context, including the second speaker's surname, which was not recoverable and is not used. The fleet size dates the interview to before the company's current figure. The public recording was published in February 2025.
The company's analyst built many of these processes on the platform himself, under the working model of the time. Jestor now builds and maintains the system on the customer's behalf; those passages are not used as evidence, and the mapping-first lesson they contain is reported because it holds under either model.
Revenue, utilisation, vehicles per employee company-wide: none is public and none is claimed.
A rental vehicle costs money every day, and earns only on the days it moves
| Indicator | Number | Source |
|---|---|---|
| Revenue per vehicle per month at a global rental company | USD 1,530 | Hertz Global Holdings, Q3 2025 earnings release |
| Depreciation per vehicle per month at the same company | USD 273 | Same release |
| Vehicle utilisation at the same company | 84%, up from 82% a year earlier | Same release |
| Average vehicles in that company fleet | About 545,000 | Same release |
Depreciation runs whether the car is rented, in a workshop or waiting for an approval. At the figures above, a day of downtime costs about nine dollars in depreciation and forgoes about fifty in revenue. Multiply by a fleet, and the two percentage points of utilisation a large operator gained in a year are the difference between a loss and a profit.
The gap between "rented" and "rentable" is made of repairs waiting for quotes, cars waiting for transfers, and sales waiting for approvals. Each of those is a process with a person and a message in it, which is exactly what this company set out to shorten.
One listed company's metrics are the cleanest public data on how a rental fleet earns and loses money, and they are used here for that reason. They describe a fleet a hundred times larger than this one, in a different market, with a different mix. A mid-sized fleet-outsourcing operator's own downtime per vehicle is the number to plan on.
The system is built to fit, and responsibility for it stays with us
Citycar's old process was not careless. It was email, spreadsheets and a pipeline tool doing a job they were not built for, and doing it well enough until the fleet doubled. The company's own observation was that a ready-made platform fits about seventy percent of the business and the rest never quite lines up. The question a bespoke system has to answer is what happens in year two: an operations system nobody can change becomes the new email thread in three years, with a login.
One builder owns each request from start to finish, and one is always in execution.
A new flow, a new automation or a new report comes in through the same channel, without becoming a new project.
If what was built is not right, it is rebuilt. Unlimited revisions within the subscription.
Seats are never the billing unit, which matters when sales, legal, finance, maintenance, logistics, the counter and every driver at the gate all touch the same records.
People learn to use their app the way they learn any app, by opening it. Building, configuring and maintaining stays on our side.
Full export at any time, by CSV and API. SOC 2 compliant, no exit fee. Pause in one click and the systems keep running.
Methodology and sources
The before-and-after descriptions and both quotes come from a recorded interview with the company's operations lead and data analyst, used through its machine-generated transcript. Quotes were cleaned of transcription noise without changing their content. The account is the company's own and was not audited. Passages describing the analyst building processes himself were not used as evidence, as they describe a working model Jestor no longer offers.
Company history, fleet size today and supplier count from the company's own site. Fleet size at the time of the interview from the interview itself.
Hertz Global Holdings, Inc., third-quarter 2025 earnings release, November 2025.
No hours saved, cost saved, downtime reduction or approval cycle time is claimed, because none was measured. The email counts and the headcount comparison are reported as the team's own estimates.