Rental management software: the machine has been out eleven days and the invoice says six

The owner of a construction equipment rental company, thirty one employees and four yards across two provinces in northern Italy, showed me how the company finds out where a machine is. You telephone. The lad in the yard opens a ring binder, runs through last week's delivery notes and says that the twelve metre boom lift, the one whose serial number ends in 417, should still be at the customer near Orzinuovi. Should. The customer took it for six days, eleven have gone by, nobody has heard from him since, and six is what will end up on the invoice.

If you recognise that scene, this article gives you the real cost of running rental on paper notes and phone calls, the single number that tells you whether rental management software will give you margin back or only a tidier archive, why the fleet with its serial numbers is the real project while the yard app is only the tip of it, how to build an availability calendar that does not promise machines you do not have, where a tiered rate card quietly eats your margin, the real price bands between the rental module of the ERP you already own, a vertical subscription product and a custom system, and the threshold in euros beyond which the arithmetic changes.

I have been writing software since 1999 and I have seen plenty of companies that put their own assets into somebody else's hands and then have to get them back: equipment rental firms with four yards and a single ring binder, audio and lighting hire companies whose warehouse empties on Thursday and fills up on Monday, scaffolding firms invoicing by square metre and by month, forklift rental companies with long term contracts and maintenance included, car hire outfits with twenty vehicles and a shared spreadsheet. I have also built and sold a software product used by many companies, and from the selling side I learned the thing that applies here too: in rental you do not sell an object, you sell time, and time is the one commodity that, if you do not count it, disappears without leaving a hole in the stock count.

The thing I have learned, and that nobody says during the product demo, is this: the number that decides is not how many contracts you write, nor how high your utilisation rate is, it is how many days your machines spend away from the yard with no contract line covering them. Every uncovered day is full rate you will never collect, because unlike a missing item in stock it leaves no gap that somebody eventually notices. If your uncovered day rate is high, good software takes it close to zero within a year and pays for itself. If it is already low, what you are buying is order, not margin, and it should be bought from a different budget.

What rental management software is, and what it is not

Rental management software is the system that holds together four things that today live in four different places in your company: the fleet with the history of every serial number, the calendar of who has booked what and until when, the contract with its rate card and terms, and the physical out and back movement with the condition the machine left in and came back in. If one of those four is missing, it is not a rental system: it is an ERP with the word rental written on top.

The difference from a normal ERP is not cosmetic, it is structural. In a trading ERP the unit of measure is the piece and the question is how many have I got. In rental the unit of measure is the day per serial number and the question is where is this one, until when and in what condition. Those are two different data models. The first adds up quantities, the second manages time intervals that can overlap, and anyone who has tried to bend the first into the second knows how it ends: serialised stock items used as machines, delivery notes used as contracts, and a notes column where somebody writes by hand when it is supposed to come back.

Dry hire, operated hire and long term rental: three different systems

This is where the confusion almost always starts, and it is expensive because you end up buying the tool for the other problem. In dry hire you deliver the machine and that is it: the customer operates it with their own staff, and you have to guarantee it is fit for use, compliant with its statutory inspections and delivered with its manual. Here the software revolves entirely around availability and return. In operated hire your own operator goes with the machine, and from that moment you are no longer renting, you are selling a service: responsibilities on site change, man hours, job sheets, shifts and standby come into play, and the software you need looks more like a field service system than a rental system. In long term rental, typical of forklifts and vehicles, the contract runs for years, the invoice is a fixed fee, and the heart of the system becomes the included planned maintenance and the counting of hours or kilometres above the allowance.

Three models, three systems. Most rental companies do at least two of the three and buy a system that does only one of them well. Before you watch any demo, take last year's revenue and split it across the three: the one that weighs most decides which software you are looking for, and the other two will have to accept a compromise you chose rather than a disaster you discover once the project is running.

The four families of companies that look for it, and want different things

The first family is plant and equipment rental, construction and industry: a large and very varied fleet, from breakers to boom lifts, short contracts, many customers, and the number one problem is knowing where the kit is. The second is technical hire, audio, lighting, video, exhibition stands: the fleet is thousands of small items that travel together as a package, and the number one problem is that three cables and an adapter are missing on return, which is to say the packing list. The third is operated hire and lifting companies: few but very expensive machines, and the number one problem is scheduling the operator and the machine together. The fourth is companies that rent out what they manufacture, from containers to cold rooms to scaffolding: the number one problem is that the fleet grows with production and nobody knows when to stop building and start recovering.

The four families search Google for the same thing and get the same ten results, but they only buy well if they have worked out which family they are in. A product designed for technical hire solves your packing list and leaves you exposed on statutory inspections. A product designed for construction handles serial numbers beautifully and has no idea what to do with a package of sixty items that goes out and comes back as one.

The real cost: what rental run on paper notes and phone calls costs you today

I will take the reference company of this article, the one with the ring binder, and keep it throughout so the numbers stay comparable. Thirty one employees, four yards, four point eight million euros of revenue of which three point six million is pure rental and the rest is consumables, transport and recharges. Seven hundred and forty machines in the fleet, twelve point six million euros at original cost. Two thousand nine hundred rental contracts a year. Average rate collected thirty four euros a day, which is low because the fleet is mixed and long rentals are discounted. Time utilisation fifty eight per cent, that is one hundred and seven thousand invoiced days out of one hundred and eighty five thousand available ones.

These five costs do not appear as lines in the accounts. They have no ledger account and no cost centre, and your accountant will never flag them, because from where they sit these do not exist: they are revenue that was never born.

The days out that nobody invoices

This is the big one, and on its own it is worth more than the other four put together. The mechanism is always the same: the machine goes out with a delivery note, the contract says six days, the customer keeps it eleven, you invoice six. Or the contract is open ended, the customer rings and says he will keep it a bit longer, the sales rep says fine, nobody writes anything down, and the count carries on from where it was. Or the machine comes back on Tuesday but the return note reaches the office on Friday with all the others and invoicing stalls. Or the machine is delivered on Friday afternoon and the contract is issued on Monday, and you will never see those three days.

In companies with no register of days, the uncovered day rate almost always sits between three and nine per cent of the days the machine is away from the yard. For the reference company, with one hundred and fifteen thousand days out, six per cent is six thousand nine hundred days, which at thirty four euros comes to two hundred and thirty four thousand euros a year. The first reaction is always the same, that cannot be right. It is, for a precise reason: in rental the revenue is measured in days and nobody keeps a register of days, they keep a register of contracts. A missing item is caught by the stock count, a missing day is caught by nobody.

The damage that comes back and does not get recharged

Out of two thousand nine hundred returns, damage is found on around fourteen per cent: four hundred and six machines coming back with something broken, bent, missing or simply caked in set concrete. The average repair, counting parts and in house labour, is around three hundred and forty euros. Fewer than half are recharged, because recharging requires two things you do not have: the documented condition of the machine at delivery and at return, with a signature underneath. Without those two you lose the argument with the customer every time, and often you do not even start it, so as not to damage the relationship.

That is up to eighty thousand euros a year between unrecovered repairs and the days the machine is down being put right, which are days that machine cannot be rented and therefore are not even in your utilisation figure. The technical fix is trivial and fifteen years old: six photographs at loading and six at unloading, geotagged and dated, attached to the document. The reason it does not happen is not the software, it is that nobody has decided it is mandatory and that without them the machine does not leave.

The machine you say you have not got

Nobody sees this one because it is lost revenue, not a cost. The customer rings and asks for a mini excavator for Monday. The yard does not know for certain which machines are coming back on Friday and which are committed, so it says no just in case, or says maybe and rings back on Tuesday. By then the customer has rung your competitor, and a customer who has hired once from the competitor goes back there.

Three requests a week turned away because of an inventory that does not know where things are makes one hundred and thirty eight lost rentals a year, which at eleven days average duration and thirty four euros a day comes to fifty one thousand euros, and counting the customers who never come back you reach up to seventy five thousand euros a year. The galling part is that the machine was often there: it was in another yard, or it had come back the day before and nobody had booked in the return note yet.

Breakdowns on site caused by calendar based maintenance

Almost every rental company services machines on calendar dates, because it is the only thing you can organise with a spreadsheet. The result is doubly wrong: machines sitting in the yard get serviced for nothing, and machines working twelve hours a day reach their service at double the hours and break down on site. Every breakdown on site costs a recovery transport, a replacement machine delivered free so as not to lose the customer, the uninvoiced days of the broken machine, and an urgent repair you pay more for because you want the part tomorrow.

Ninety breakdowns a year at an average of five hundred and fifty euros comes to up to sixty thousand euros a year, and the fix is not buying better machines: it is tying maintenance to hour meter readings instead of the calendar, which only requires reading the meter at every return and writing it down. The full logic of a maintenance plan built on data is in maintenance management software, which is about the plant inside your own factory but on hours versus calendar reads exactly the same.

The office chasing notes and signatures

The last cost is the most visible of all and, paradoxically, the one nobody counts, because these are salaries you would pay anyway. Somebody spends the day phoning the yards to find out where a machine is, redoing wrong delivery notes, chasing customer signatures, reconstructing at month end what went out and when so that it can be invoiced. In a thirty one person company that is almost always the equivalent of one and a half people, which at full employment cost is up to forty five thousand euros a year.

The five costs at their maximum come to almost half a million, but they never all peak in the same year: for the reference company, measured one by one, they came to about four hundred and forty thousand euros a year, that is twelve per cent of pure rental revenue. In smaller companies, with a single yard and rental already inside the ERP, the same measurement gives figures between seventy and one hundred and fifty thousand. But look at where the weight sits: more than half is in the first one. If you can only look at one thing, look at that.

The uncovered day rate: the number that decides

The exact definition, because that is what makes the number useful rather than merely suggestive: out of a hundred working days on which a machine was not in the yard, how many have no invoiced rental line covering them. Why it was out does not matter: it could be a rental extended verbally, a machine left on site for convenience, a transfer between yards that took eight days, or a machine at an outside workshop that nobody recorded. All of these are days on which that capital was committed and produced nothing, which is exactly what you want to know.

How to measure it, in a day

You need two pieces of information and there is almost always one and a half of them. The first is the out and back movements, that is the delivery notes: they exist because they are fiscal documents, but often they are not in a database, they are in a folder. The second is the invoiced rental lines with the period they cover: those always exist, because they are invoices. If the notes are already digitised, the measurement is a query. This is the shape I use on SQL Server, and it needs a table with one row per day, which almost every ERP already has:

-- Uncovered days: working days on which the machine was away from the yard
-- and no invoiced rental line covered them
WITH giorni_fuori AS (
    SELECT u.IdMezzo, c.Giorno
    FROM UscitaMezzo u
    JOIN Calendario c
      ON c.Giorno >= CAST(u.DataUscita AS date)
     AND c.Giorno <  CAST(COALESCE(u.DataRientro, GETDATE()) AS date)
    WHERE c.Lavorativo = 1
      AND u.DataUscita >= DATEADD(MONTH, -12, CAST(GETDATE() AS date))
),
giorni_fatturati AS (
    SELECT DISTINCT r.IdMezzo, c.Giorno
    FROM RigaNoleggio r
    JOIN Calendario c
      ON c.Giorno >= r.DataInizio
     AND c.Giorno <= r.DataFine
    WHERE c.Lavorativo = 1
      AND r.Fatturata = 1
)
SELECT COUNT(*) AS GiorniFuori,
       SUM(CASE WHEN f.IdMezzo IS NULL THEN 1 ELSE 0 END) AS GiorniScoperti,
       SUM(CASE WHEN f.IdMezzo IS NULL THEN 1 ELSE 0 END) * 100.0
           / NULLIF(COUNT(*), 0) AS QuotaScopertiPercento
FROM giorni_fuori g
LEFT JOIN giorni_fatturati f
       ON f.IdMezzo = g.IdMezzo
      AND f.Giorno = g.Giorno;

If the notes are on paper, do not digitise them in order to take the measurement: sample instead. Take sixty contracts at random from the last twelve months, stratified by machine family, and for each one compare by hand the out date and the back date against the invoiced period. Sixty contracts take half a day with two people, and across sixty the sampling error still gives you a number precise enough to decide on: if it comes out at two per cent you do not have a problem, if it comes out at seven you do, and you already know what it is worth.

Then do the second pass, the one that tells the truth: group the same measurement by machine family and sort by uncovered days. You will almost always find that twenty per cent of the serial numbers generate between sixty and seventy per cent of the invoiced days, and that the uncovered days cluster on two or three families only, usually the ones that go out often and briefly, which are also the ones nobody chases because each one is worth so little. Those families are the scope of your first release.

Three caveats, because the measurement is easy to distort without meaning to. Do not count recorded planned maintenance as uncovered: those are deliberate stoppages and belong in another figure, the utilisation rate. Do not count transfers between yards if you have the document that justifies them, but do count them if you have not, because that is precisely the point. And count uncovered days even when the customer eventually paid a lump sum settlement: the fact that he paid something does not mean he paid for those days, it means you reached an agreement in the dark, and in the dark you lose, because the other side knows how long they kept the machine and you do not.

The four thresholds, and what you can do at each

Under three per cent: the register works. Somebody in the company, usually one person and for twenty years, keeps in their head where everything is and chases every return. That is an excellent result and also the biggest risk you have, because that number hangs on one person: the day they retire it doubles within six months. Here software will not bring you margin straight away, it brings continuity, and the right spend is a module, not a project.

Three to six per cent: the problem is the return. You write the contract properly, but the moment the machine comes back produces no data: the return note travels with the lorry and reaches the office days later, or the customer brings the machine back himself and leaves it in the yard without telling anybody. Here the recovery comes from one thing only, recording the return at the moment and in the place it happens, on the yard man's phone. It is also the band where the return on investment shows up fastest, typically within four months.

Over six per cent: the problem is the extension. Rentals carry on by verbal agreement between the customer and the sales rep and nobody writes them up again. It almost always happens in companies where the sales rep also sets the price and does not want to be the one nitpicking with the customer. Here software helps, but first you need a company rule: an extension exists only if it produces a document, and the sales rep can raise that document from a phone in thirty seconds. Without that rule, whatever system you buy will have an end date field that nobody updates.

Never measured: you do not know. This is the most common case, and it is not a failing: nobody asks for that number, neither your accountant nor the person selling you the software, who would much rather talk about how pretty the colour coded calendar is. It is also the best case, because the measurement costs half a day and tells you, before you spend a euro, whether you have a forty thousand or a three hundred thousand euro a year problem.

The fleet is the project, the yard app is the tip of it

This is the part everybody underestimates and the one that decides whether the project works. The colour coded calendar they show you in the demo is beautiful because the sample data is perfect. In your company that data does not exist, and the real work is building it. For every serial number in the fleet you need eight pieces of information, and today they live in eight different places.

Serial number, model and configuration. It is on the manual and in the asset register, which however talks about accounting codes rather than machines. If it is missing, the customer asks for the twelve metre boom lift and you do not know which of your four has the narrow basket that fits through the workshop door.

Where it is right now. It is in the yard man's head. If it is missing, you turn down a rental you could have taken, or you send a lorry to fetch a machine that was already in another yard.

Hour meter or kilometres at the last return. It is on the machine, you only have to look. If it is missing, you service on the calendar and it breaks down on site.

Statutory deadlines. The annual periodic inspection for mobile elevating work platforms and lifting equipment, the road test for road going machines, insurance, rope inspections. They live in a folder and a spreadsheet. If this is missing, you hire out a machine with an expired inspection, and if something happens on site the position you are in is far worse than the lost revenue the rest of this article is about. This one piece of information, in many companies, justifies the whole project on its own.

Rental history with the customers who had it. It is in the invoices. If it is missing, you do not know which machines earn and which sit still, and you keep buying the wrong model.

Damage and repair history with costs. It is in the workshop notes, when there are any. If it is missing, you do not know that the maintenance cost of that serial number passed the margin it generates two years ago.

Accessories that travel with the machine. Battery, charger, forks, chains, remote control, cables. It is in the memory of whoever loads it. If it is missing, four machines out of five come back complete and nobody knows who kept the charger.

Residual value and planned exit date from the fleet. It is in the depreciation schedule. If it is missing, you keep machines worth more sold than rented and you find out when nobody wants them any more.

How to build it without stopping the company

You do not build all of it and you do not build it perfect. You start from the serial numbers that had at least one rental in the last eighteen months, which for the reference company is about five hundred and twenty out of seven hundred and forty: the other two hundred and twenty are small tools and idle machines, and their absence blocks nothing. For each one you load the first four pieces of information, which you get by cross referencing the asset register, the manuals and the inspection spreadsheet. The rest is written by the field over the following months, at every out and every back.

It is the opposite of what almost every vendor proposes, because they want the complete master data before starting, which makes the project theirs rather than yours. A seventy per cent master file that gets used every day becomes accurate within six months. A hundred per cent master file that nobody uses, because the software arrived a year later, stays frozen at the day it was loaded. If your fleet is made of many small items that go out as packages, as in technical hire, the coding and counting rules are the warehouse ones and I have set them out in warehouse management software: here it is enough to know that a package has to be one thing going out and sixty things coming back, otherwise the cables will keep disappearing.

Availability: the calendar is the heart, and almost nobody gets it right

The availability calendar is the function that sells the software and the one almost every product implements badly, because they treat it as a diary. A diary has appointments that do not overlap. A rental fleet has five different states that overlap a great deal, and the difference between a system that works and one that makes you promise machines you have not got lies entirely here.

The states are these. Booked, meaning a customer has asked but not confirmed: it holds the machine but it has to expire on its own, otherwise within three months your whole fleet shows as booked by quotes that never became contracts. Committed, meaning the contract is signed and a delivery date is set. Out, meaning delivered and currently with the customer. Returning, meaning the customer has rung or the date has passed but the machine is not in the yard yet, and this is the state almost no software has and the most important of all, because that is where you decide whether you can accept Monday's rental. Down, for maintenance, for repair or because an inspection has expired.

The overlap check is two lines, and getting it wrong is surprisingly common. Two commitments on the same machine overlap if and only if each starts before the other ends, and the request needs a turnaround buffer added to it, that is the time it takes to bring the machine back, wash it and check it before it goes out again:

public enum TipoImpegno { Prenotazione, Contratto, Manutenzione, Trasferimento }

public sealed record Impegno(int IdMezzo, DateOnly Dal, DateOnly Al, TipoImpegno Tipo);

public static class Disponibilita
{
    public static bool SiSovrappone(Impegno a, Impegno b) =>
        a.IdMezzo == b.IdMezzo && a.Dal < b.Al && b.Dal < a.Al;

    public static IReadOnlyList<Impegno> Conflitti(
        Impegno richiesta,
        IEnumerable<Impegno> agenda,
        int giorniDiRientro)
    {
        var conCuscinetto = richiesta with
        {
            Dal = richiesta.Dal.AddDays(-giorniDiRientro),
            Al = richiesta.Al.AddDays(giorniDiRientro)
        };

        return agenda
            .Where(impegno => SiSovrappone(conCuscinetto, impegno))
            .OrderBy(impegno => impegno.Dal)
            .ToList();
    }
}

The turnaround buffer is what separates a real calendar from a fake one. If a machine comes back on Friday at five, it is not available on Monday at seven: it has to be unloaded, washed, checked, refuelled and sometimes repaired. One day of buffer on equipment and two on large machines is the value to start from, and you tune it on real data after six months. Skip it and you will be delivering dirty machines, which is the fastest way to turn a customer into a former customer.

Then there is a design choice that decides half the value of the system: do you book the serial number or the category. Booking the serial number is easy to program and disastrous to use, because it locks that one machine, and if it comes back late the rental falls through even though you had three identical ones in the yard. Booking the category, meaning ten metre scissor lift, and assigning the serial number only the day before delivery, is harder and earns you between three and five per cent of utilisation, because the system can interlock rentals in a way no person with a ring binder can. If you are evaluating a product, this is the first question to ask the salesperson, and the right answer is the second one.

The last thing about the calendar concerns transfers between yards. Once you have more than one site, the machine you need is almost always in the other yard, and the transfer costs a lorry and half a day. A system that shows group availability without showing where the thing physically is makes you promise deliveries that end up costing more than the rental. The rule that works is to show three columns in the availability result: available here, available within two hours by lorry, available but has to be scheduled. On how those trips are organised and costed I have written at length in transport management software.

Rate card, tiers and invoice: where the margin quietly goes

A rental company's rate card is the most complicated thing in the business and almost nobody treats it as such. You have a daily rate, a weekly one that is not five times the daily, a monthly one that is not four times the weekly, a minimum charge, a surcharge for double shifts and weekends if the machine works, outbound and return transport depending on distance and lorry type, fuel on return, an optional damage waiver, and on top of all that the discounts agreed with long standing customers that nobody has ever written down.

The sore point is the tier change. A customer takes a machine for six days: do you apply the weekly rate or six times the daily. The correct answer is whichever is lower, and almost every system instead applies whatever the contract said at the start, because the rate is set at departure and not recalculated at closing. When the count goes against you, you lose margin; when it goes against the customer, the customer notices, complains and gets the discount. You lose both ways. A system that always recalculates the rate at closing on the period actually accrued, and picks the cheapest tier for the customer by itself, loses you a little on the individual line and earns you a great deal in trust, which in rental is what makes people come back.

The second thing that eats margin is invoicing long rentals across month ends. A machine out from March to July has to be invoiced every month on the accrued amount, otherwise your cash arrives in July while the depreciation and the finance instalment have gone out every month. In companies that invoice only at closing, the working capital locked up in open rentals is often worth more than two months of revenue, and it is fixed with one line of code and a decision, not with a loan.

The third is recharging transport. Many rental companies give it away to close the deal and do not notice that on short rentals transport is fifty per cent of the cost of the operation. A system that shows the line margin including estimated transport at quoting time changes the sales rep's behaviour in a fortnight, with no need for meetings.

And finally, recharging hours above the allowance on long term contracts. If you rent out a forklift for thirty six months with fifteen hundred hours a year included and the customer does two thousand four hundred, you are paying for those nine hundred extra hours in maintenance. To recharge them you have to read the meter, and to read it without sending somebody you need telematics on the machine or a reading recorded at every service visit. That is why long term contracts run without software are almost always loss making from the second year, and nobody notices, because the fee arrives punctually every month.

Delivery and return: the photographs are worth more than the contract

Delivery and return are the only two moments in which your machine changes hands, and they are the two moments that settle every argument that follows. In most companies they are also the two moments handled worst: a carbon copy note signed in a hurry, often by somebody on site with no authority to sign it, and no record of the machine's condition.

What is needed is little and has to be done every time. At delivery: six standard photographs, the same set for every delivery, the meter reading, the list of accessories going out, the fuel level, the printed name of whoever takes it, their signature on the screen. At return: the same six photographs, the meter, the accessories coming back, the fuel, and the signature of whoever hands it over. Done that way, the damage document writes itself, because it is the comparison between two sets of dated, geotagged photographs.

The resistance to this is never technical, it is cultural, and it always comes from the same place: the yard man or the driver says there is no time. They are right if the process is badly built. Six photographs on a phone take forty seconds if the app asks for them one at a time with an outline overlay; they take six minutes if you have to open the gallery, pick the contract and attach them. The difference between forty seconds and six minutes is the whole project, and it is why the yard app has to be tested in the yard with gloves on, not in the office.

Two details that look minor and are not. First: the app has to work without a connection, because the sites and sheds you deliver to are exactly the places with no signal. A driver who has lost a delivery twice for lack of coverage will never open that app again, and the project dies there. Second: the signature needs to come with a printed name and a photographed identity document, at least for new customers, otherwise a signature on the glass of a phone is worth what it is worth.

Anyone delivering mostly to construction sites has an extra problem, namely working out who the site really belongs to and who is authorised to commit the customer, and the orderly handling of sites with their crews and dates is in construction site management software. For the rental company the practical rule is one: the site is a master record, not an address field scribbled on a note, because the day you have to go and recover your machine that address is all you have.

What it costs: ERP module, subscription product or custom

All three roads exist and picking the wrong road costs more than picking the wrong vendor. These are the orders of magnitude I see in the Italian market, for a company like the reference one.

The rental module of the ERP you already own. Setup between eight and twenty eight thousand euros, a fee between one hundred and fifty and six hundred euros a month. The advantage is enormous and underrated: customers, rate cards, invoices and accounting are already there, so there is no integration to build, which is the line that blows the budget on every other project. The drawback is that almost all these modules treat machines as serialised stock items and the calendar as a diary: they are fine if you rent few things for long periods, and poor if you have a varied fleet, short rentals and four yards.

A vertical rental product on subscription. Priced per user, between sixty and one hundred and forty euros a month, or per managed machine, between three and eight euros a month. For the reference company that is between eleven and twenty two thousand euros a year, plus a setup between fifteen and fifty thousand euros that is mostly fleet master data, rate cards and the ERP link so you do not have to re enter customers or rewrite invoices. Good vertical products exist, some of them very good, and they do things nobody would rebuild from scratch on that budget.

A custom system. It starts at forty five thousand euros for fleet master data with serial numbers and history, an availability calendar with booking by category, the contract, delivery and return with photographs, a tiered rate card and invoice generation. It reaches one hundred and seventy thousand with a customer booking portal, a yard app that works offline, maintenance driven by hour meters and machine telematics. Plus fifteen to twenty per cent a year of maintenance, which always has to be budgeted, and which anyone who hides it in the quote will ask you for later.

The threshold. Under twenty two thousand euros a year of total spend on running rental, fees and depreciation included, the product almost always wins: custom does not pay back and the time it takes you costs you twice. Break even between the two roads falls between year four and year five, as in the chart, which means the right question is not which costs less, but whether in five years the way you run rental will still be an administrative function or will be the reason customers choose you over the rental firm ten kilometres away. It is the same reasoning that applies to any choice between off the shelf and bespoke, and I have set out all the criteria in business management software, off the shelf or custom.

There is a fourth road I recommend more often than people expect, which is a vertical product for the core of rental plus a custom piece for the thing that sets you apart. If your competitive advantage is that you deliver within two hours anywhere in the province, you build that piece and integrate it; you buy everything else. Why this hybrid route almost always works better than either pure one is explained in custom software development.

Where to start: the first release in ninety days

The first release does not have to be complete, it has to be useful to somebody within three months. This is the order I use, and the first three steps cost little and are worth a lot because they happen before the software.

Week one: measure. Run the uncovered days query, or sample sixty contracts if the notes are on paper. By the end of the week you need a number and a main cause, and with that number in hand every subsequent conversation, including the ones with vendors, becomes concrete. Take the number to the sales reps too: the uncovered day rate is not their fault, but it does not come down without them.

Weeks two and three: the first version of the fleet. The serial numbers with at least one rental in the last eighteen months, with model, configuration, home yard and statutory deadlines. Accept that it will be dirty. For the reference company that is about five hundred and twenty machines out of seven hundred and forty, and it is the right list: the field will add the others.

Week four: write the rate card, properly. Rates, tiers, minimum charges, transport, surcharges, waivers and the discounts agreed with your top twenty customers. It is the most tedious week of the project and the one that determines half the software, because the rate card is the business logic of rental. If you do not write it first you will write it inside the program, which is the most expensive place to write it.

From month two: the first release to the yard. Three things only: the machine record with status and location, out and back recorded on the spot with photographs, and an availability calendar by category. No customer portal, no telematics, no lorry route optimisation. Start with one yard, the one whose yard man is willing, not with all four: the one that goes first becomes the one that teaches the others, and the project stops being a management thing.

Month three: invoicing from the system. Rental lines generated from real movements, with the tier recalculated at closing and monthly instalments on open rentals. This is the point at which the uncovered days number starts falling on its own, because for the first time somebody sees it every week.

One last piece of advice on what not to do first. The portal where customers book for themselves is the function that sells best and is needed last: if the internal calendar is not reliable, the portal promises machines you do not have and loses you customers faster than it brings them. It comes later, and when it comes it works. The same logic I described for customer facing portals in B2B portal applies: a portal does not create order, it exposes it, and if there is disorder behind it, it exposes that to the people who pay you.

If the number says this is not your problem

It happens, and it is worth saying because almost nobody does. If your uncovered day rate is under three per cent, if returns are recorded the same day, and if when the phone rings you genuinely know what is free on Monday, rental management software will not give you margin back: it will give you order, continuity when people change, and numbers for deciding what to buy and what to sell. Those are worth having, but they are worth the price of a module, not of a project.

In that case the bottleneck is almost always somewhere else, and in rental companies it is one of these three: the wrong fleet, that is too many machines in a family that sits still and too few in the one you always say no to; transport, which eats the margin on short rentals and nobody measures it per line; or credit, because in rental the customer who does not pay is still holding your property, and it is the only sector where debt collection and logistics are the same problem.

And there is a case where software is not the answer even when the numbers are bad: when the uncovered days come from a commercial decision. If the company has decided, perhaps without ever saying so, that the three biggest customers do not get nitpicked over days, no system will change that decision, it will only tell you precisely what it costs. Which, incidentally, is already an excellent reason to measure: many concessions made to keep a customer are worth more than the margin that customer brings, and until the number exists the conversation cannot even begin.

If you have read this far you probably have your own ring binder in mind, and a fairly precise idea of which of the five costs applies most to you. Take the uncovered days measurement before you watch any demo: it is half a day of work, it costs nothing, and it tells you whether you are buying margin or only order. From there the decisions are much simpler, and you make them yourself instead of leaving them to the most convincing quote.