Custom CRM for car rental: the full case study

A CRM tailored for car rental is a management system built around the real process of a charterer, instead of adapted by a generic product. It is not a question of the most beautiful interface: it is that it knows how to answer questions that a standard management software can not even formulate.

This article tells a real project delivered to Rial Rent, luxury and sports car rental based in Milan, which also operates a fleet of yachts. The system covers 27 cars, beyond 70 customers and beyond 90 contracts imported from the previous management software.

I tell how it is done, what it really does, where it breaks down and — above all — the two questions that justified the tailored. If you are looking for the general reasoning on building or buying, it is in Custom CRM or off-the-shelf business management software; here's what happens when you build it.

The starting point: a management software that did not respond

Before the project there was a generic third-party management software, from which we imported the historical data. It was not a bad product: it was a wrong product for that job.

The two questions he could not answer are the ones that decide the management of a rental:

1. How much did this single car make this year? Not the total turnover: the margin of that medium, with insurance, stamp, maintenance, tires and overtime inside.
2. Who was driving on May 17 at 17:14? A question that comes up every time a fine enters the office, and to which answering by hand means scrolling through contracts until it returns.

Everything else —customer registry, vehicle list, contracts.the ready product did. Tailor-made was justified on those two, not on aesthetics. It is the criterion that is worth taking home from this case study.

How the system is made

1. Installable web application. A PWA in React: Opens from any device, installs on the home screen, does not pass through stores and updates itself.
2. Three roles, three views. The administrator sees everything; the operating staff works on contracts, deliveries and documents; the driver only sees their own day delivery and pick-up assignments and the documents they need.
3. Serverless backend. Cloud and blob storage functions: no servers to update, no machines to guard.

Separation of roles is not a detail of convenience. A driver who opens the application to know where it is to deliver has no reason to see the profitability of the fleet or the full customer record — and must not be able to see it. It is the same principle behind the safety work described below.

The fines: from PDF to driver

It is the function that has saved the most repetitive work, and it is the one that best explains how the system reasons.

First: read the minutes

You load the PDF and the system tries two ways in waterfall.

Then regular expressions look for the format of the Italian plate, tolerating the errors typical of the OCR la the letter O read in place of the zero is the classic — and distinguish the date of infringement from the notification one.

The OCR turns in the browser, on the device of who uploads the file. It has an advantage and a price: documents do not leave the company, but the first reading is slow because the language model needs to be downloaded. It should be told to the user as it happens, with a progress bar, otherwise it looks broken. The detail is in read the fines in PDF.

Then: find who was driving

With license plate and instant of the infraction, the system searches between the contracts of that vehicle the one that covered that moment and dates back to the customer.

There are five cases explicitly handled, and this is the part that distinguishes a serious automation from one that guesses:

• Match certain: a contract covers the instant, it generates the communication of the driver's data.
• Approximate Match: the infraction falls into the tolerance on the edges, it is asked to confirm to a person.
• No active contract: led the company. It's an outcome, not a mistake.
• Vehicle not found: the plate extracted does not correspond to any means in the fleet.
• Unreadable date: the system stops and asks for manual insertion.

The tolerance on edges It deserves a note. A rental that ends at 10:00 on the contract but returns at 11:40 creates a time hole in which a fine does not formally have a driver. How many hours of tolerance are acceptable is a customer decision, not a parameter to guess. The complete reasoning is in Matching the fine to the driver.

The Deadline: What to Do Today, Not an Archive

Each vehicle has four types of expiration — insurance, stamp, review, cutting — plus the mileage threshold for servicing. The system calculates the days remaining and assigns a level: overdue, critical within 7 days, approaching within 30, or up to date.

The choice of project that changes daily use is another: in the fleet list emerges the nearest deadline of any means. The dashboard responds to "what I have to do today" instead of being an archive to question. The detail is in Fleet Schedule.

There is also the management of Tyres: set mounted and set in stock, season, make, date of assembly. It serves to know when to change and not to buy back a tire train that is already in stock.

Quotes: from messy message to PDF

Requests come as free text messages, often in English, written in haste. A parser extracts:

1. The Dates, recognizing about ten different formats — it is the most boring and the one that breaks most often.
2. Place of delivery and return, which almost never coincide.
3. Vehicle required, miles planned, and if you need a driver.

Then calculate the quote by putting together rental rate, transport of the vehicle, driver and tolls, using a table of distances from the base of Milan to the recurring destinations: airports, Italian cities, Switzerland, Austria, C Costate d'Azur.

The quote comes out in PDF with real photos of the vehicle. The flow is described in automatic quotations from free text; the general theme in AI quote automation.

Contracts, signing and delegation to the guide

The rental contract is generated from the data already present in the system, is signed on the screen at the time of delivery and is archived in PDF. No printing, no scanning, no rolling sheets.

When the delivery is assigned to a driver, the system also produces the delegation to the guide with driver and vehicle data — document that the driver can reload from their view when needed. The detail is in contracts and digital signature in app.

Vehicle documents, where they are needed

Vehicle registration documents, service records and certificates live in the middle tab, not in a shared folder. Vehicle datana registration plate, first registration, holder — are on the card next to the documents from which they come.

It seems like an organizational banality. In practice it's the difference between finding a booklet in three seconds and looking for it in a folder with file names decided by different people in different years. The theme is taken up in Digital Vehicle Documents and, generally, in document automation with AI.

Profitability: The Transition That Changes Decisions

For every means the system puts on one side the revenues of the rentals and on the other the real costs: insurance related to the months of possession, stamp, maintenance, tires, extraordinary costs. The result is the margin of that vehicle.

This is the step that turns business management software into a decision tool: which car to keep, which to replace, and which to raise the rate on. Without it, decisions are based on intuition — and intuition rewards the cars you like, not the ones that earn money. The dedicated article is profitability by vehicle.

Yachts: Modeling Work Data, Not Software

The fleet also includes boats, owned and partnered. They are in a separate section, with its own documents and the distinction between ownership and partnership.

The temptation, when building, is to unify: they are all "means", why make two sections? Because cars and yachts have different cycles, costs and documents, and mixing them produces empty fields in half the records and rules full of exceptions. Modeling real work data, even when it is less elegant, is almost always the right choice.

Security: from demo to production

The first version was a demo with trial accounts and credentials visible in the login screen. It was great to show the product; it was an accident waiting to happen the moment real customer data came in.

The serious version has passwords saved only as hash with an algorithm designed for passwords, sessions with signed tokens, second mandatory factor, limit of attempts per address and per email, and constant time response on login to not reveal what emails exist.

Then there was the part that matters the most: a safety test on the result, conducted separately by those who had written the code. He found and shut down four problem categories, including a way around the second factor and a sensitive document downloadable from a role he shouldn't have.

The full story is in Mandatory 2FA for business software.

The Three Roles, and Why They Matter

The separation of accesses is the choice that is seen least and that holds the system more over time.

The driver is the most instructive case. When they open the application, they have just one question: where do I need to go, with which vehicle, and which documents do I need? Giving them the full management software is not generous; it is counterproductive: it makes finding the only information they need harder, and exposes data they have no reason to see.

This setting also has a useful side effect when verifying security: if a role must not be able to download a document, that is a written and verifiable rule, not a convention.

What we didn't automate

As in any project, the list of what remains manual says more than what is automatic.

• Confirmation of an uncertain match. When the infringement falls into the tolerance between two contracts, a person decides. Attributing a fine to the wrong customer is a relationship damage, not an annoyance.
• Sending the quote. The system prepares the draft, sends it to a person. A price is a commercial decision.
• Distances not in the table. The system declares that it does not know them instead of estimating them.
• The decision on which car to replace. The account per vehicle gives the number; the choice remains who knows the market and the customers.

The criterion is the same that we apply to all projects: it automates what is repetitive and verifiable, it leaves to a person what is irreversible or ambiguous. We also talk about it in AI workflow and in AI agents.

Practical examples

A fine coming to the office. It loads the PDF. The system reads plate and instant, finds the contract that covered that moment, indicates the customer and prepares the communication of the driver's data. What used to be scrolling contracts becomes a thirty-second check.

A request for a quote at 23:00 on Saturday. A message arrives in English with dates written in an ambiguous format. The parser extracts what it succeeds, calculates the distance to the base and produces the draft. On Monday morning someone rereads it and sends it, instead of starting from scratch.

A car that seemed fine. At the end of the year the bill per vehicle shows that a very rented vehicle has a thin margin, because maintenance and tires eat it. It is the type of information that does not emerge from turnover and that changes the decision on what to keep in the fleet.

Mistakes to Avoid

Automating before you understand the right field. Extracting data from a document is easy; knowing what data is really needed is work. It must be done by talking to those who do the work, not by looking at the document.

Trusting the OCR. On a crooked scan he misses similar characters. The system must validate the format of what it extracts and declare itself uncertain when it is. An automation that declares itself uncertain is worth more than one that guesses.

Ignoring cases at the edges. Out-of-hour deliveries and re-entry, overlapping contracts, vehicles used by the company: they are most real cases after the first few months, not the exception.

Bringing a demo to production. Home page credentials and test accounts are sales tools. It takes an explicit moment when you declare the transition from demo to system with real data, and at that moment the rules change.

Unifying what work keeps separate. Cars and yachts in a single "means" table look stylish and produce a data model full of exceptions.

How to apply it in the company

If you are evaluating a tailored management software, the useful sequence is this:

1. Write the questions that your current software doesn't answer. If it's less than two, you probably don't need the custom.
2. Verify that the data to answer exists. If no one records maintenance costs, no software will calculate profitability.
3. Decide on limit cases with those who do the work, not at the table: tolerances, exceptions, what to do when the data is missing.
4. Put security in the plan, with a verification made by someone who did not write the code.
5. Define who keeps it and what happens in two years. It is the question that decides whether the project is sustainable.

On the processing of personal data of customers and drivers — documents, contracts, contacts — the framework is in AI and GDPR.

Conclusion

A CRM tailored for car rental is not justified because the ready-made business management software looks bad. It is justified when that product cannot answer central operational questions, and in this project there were two: the profitability of each vehicle and identifying its driver at a precise moment.

The two things we would do exactly the same: have the system declare when it's not safe instead of letting it guess, and treat security as a separate verification step. What we would do first: decide the limit cases with who does the work, because they are the real specification of the project.

Do you want to understand what processes in your company can be automated with AI? Giallo Studio can help you turn the problem into a real workflow. The service is described in custom software, the form installable in PWA and web app, and other real projects in the Case Studies — including the WhatsApp agent for short rentals.