Live AI case · Transportation · fleet of ~400 cars · 6 cities

AI implementation at a taxi fleet of 400 cars: same revenue, lower costs

An AI implementation case at a taxi fleet: the company rents about 400 cars to taxi drivers in six cities. Revenue did not grow by a single ruble in five months — the owner deliberately stopped buying cars. So the work went into costs: payroll fell by ₽500K a month, and the share of the fleet in repair dropped from 14% to 5.7%.

Published October 1, 2026 · Breakdown by Anton Ro Baten

Case at a glance

Company: Car rental for taxi drivers
Scale: Fleet of about 400 cars · 6 cities · a management company and city offices
Request: “We want to bring in neural networks to grow”
Timeline: 5 months · figures taken a month after the project closed
Status: Project closed; cumulative repair savings are being reconciled against documents

−20%
payroll: ₽2.5M → ₽2.0M a month
5.7%
of the fleet in repair instead of 14%
−25–30%
technical repair budget
≈70%
of driver questions closed without a person

Point A: where they started

Rental revenue is capped by the number of cars, and the owner had stopped buying them: repairs were getting more expensive faster than new cars added profit.
Repairs were the second-largest cost after leasing. The technical director approved service quotes by hand, from memory, across several hundred cars.
Repair requests did not exist as a record: a repair started with a conversation, not an entry.
The company did not know how much exactly it was overpaying.

What we did

Repair history for every car
When approving a quote, you see what was already replaced on this car, when and for how much. Repeat items are highlighted at the moment of decision, not six months later in a review.
A warranty register for parts
Every installed part got a warranty period. If it fails within that period, the system flags it: replace under warranty. Before, the service simply replaced the part again — at the company’s expense.
The technical unit digitized
Request intake, repair budget per car by make and repair bay, repair time, inventory accounting.
An app for drivers
The team wrote its own mobile app in five months. Part of the support and part of the sales functions moved there — not “into a neural network”.
Built by the managers themselves
The technical director digitized the technical unit with his own hands, and the company’s team wrote the app. We ran the sessions, provided prompts and worked through blockers.

What AI found in the data

Repeat repairs nobody had cross-checked: when approving a quote, you could not see that this part had already been replaced on this car.
Warranty parts the company paid for twice: the service replaced a part again within its warranty period.
Work the service billed for: about ₽1.15M was cut in July alone.
A paid service in the sales unit whose function AI took over: ₽55K a month saved.

Point B: results

Technical unit (according to the technical director)

Metric	Result
Technical repair budget	−25–30%
Share of the fleet in repair	14% → 5.7%
Average repair time	−65%
Time to close a quote	−38%
Request cycle	3× faster in 4 months
Billed work cut — in July alone	≈₽1.15M

People and costs (finance director’s data)

Metric	Result
Payroll	₽2.5M a month on May 1 → ₽2.0M a month · −₽500K a month, 7 people
Annual payroll effect	≈₽6M
Driver questions closed without a person	≈70%
Paid service in the sales unit	−₽55K a month

The implementation cost less than one month of payroll savings — and that is before the repair savings, which are still being reconciled against documents.

How we measured

All figures come from the company’s managers at a recorded reporting meeting. The company is anonymized at its request.
Payroll data comes from the finance director, with a baseline and dates.
We don’t use reported profit as the measure of impact: the company defers costs to future periods, and savings are recognized with a lag — services are paid a month to a month and a half later.
The team itself considers the cumulative four-month savings figure overstated until it is checked against documents — so it is not here.

What didn’t work

Body repairs did not get cheaper: pricing works differently there, and repeat highlighting does not apply.
People were let go before the automation was ready. Those who stayed carried a double load, and the pace dropped for several weeks. The right order is the reverse.
With large amounts of context the model started making mistakes. The cure is discipline: every error is traced to its source, and the conclusion goes into the permanent instructions.

In their own words

“Problems are now solved at the level of the cause, not the consequences.”
— the owner

“I have three times more time. I don’t wait for anyone to do something for me.”
— technical director

“It’s like a hammer for a builder — if someone is working with a stick, they’ve already lost.”
— technical director, on AI

What’s next

Reconcile the cumulative repair savings against documents and publish them separately.

Takeaways for your business

The most expensive thing corporate AI finds in the first months is not automation but leaks in your own data: repeat repairs and parts paid for twice.
First the function runs without a person, then the staffing decision — otherwise you pay twice.
Don’t judge the impact by the profit report in the first month: savings are recognized with a lag.
If the revenue lever is blocked, count the costs — that is where the money the company never saw is.

Full breakdown with figures — on Teletype (in Russian)

All cases