Rate cards, availability and utilisation: the hard parts of rental software

Our heavy-equipment platform quotes by day, week or month, with rate cards per equipment class. The moment a card has more than one period, you need a rule for hires that don’t fit neatly. Here is a made-up card to show the choices. These aren’t real prices.

All three are defensible, and the difference is 40% on the same machine. Whichever you choose must be explicit, the same every time, and printed on the quote. Your software shouldn’t be the place where this policy gets decided by accident. Other questions to settle before coding:

• Is a day a calendar day or 24 hours from handover? What is the grace period on return?
• Does an extension re-price the whole hire at the longer rate, or only the new days?
• Does an early return lose the weekly rate? If so, is the customer told when they book?
• Do weekends and public holidays count? Is standby charged differently from working time?
• Do customer-specific prices replace the card, or apply a discount to it?

Store the rate that applied on the contract line, not just a link to the card. When prices change next year, last year’s invoice must still explain itself.

Two periods overlap when each starts before the other ends. That one condition catches every case, including a booking that fully contains another:

SELECT id FROM unit_holds
WHERE unit_id = :unit
  AND starts_at < :requested_end
  AND ends_at   > :requested_start;

The query isn’t the hard part. These three things are:

• Everything is a hold. Confirmed hires, provisional quotes, maintenance and transit should go in one table with a type. A unit in the workshop is unavailable in the same way as one on hire, and checking several tables is how gaps appear.
• The end date is a guess. A machine due back on Friday may not be. Decide what the system shows for overdue units, and warn whoever has promised that unit to the next customer. Add buffer time for delivery and checks to the hold itself.
• Two people can book at once. Checking and then writing leaves a gap between the two steps. Do both in one transaction with a lock on the unit row, so the second request waits and then sees the first booking.

DB::transaction(function () use ($unitId, $start, $end) {
    $unit = Unit::whereKey($unitId)->lockForUpdate()->firstOrFail();

    $clash = $unit->holds()
        ->where('starts_at', '<', $end)
        ->where('ends_at', '>', $start)
        ->exists();

    abort_if($clash, 409, 'Unit is no longer available.');

    $unit->holds()->create([
        'starts_at' => $start,
        'ends_at' => $end,
        'type' => 'hire',
    ]);
});

Include maintenance holds early. A machine that breaks down mid-hire creates a chain of decisions: swap the unit, stop the charges or credit the customer. The system should prompt for them rather than leave staff to remember.

Our equipment platform reports utilisation and revenue, and the first task with any report like this is defining the terms. Two managers can look at the same fleet and report different percentages, with both correct by their own definition.

Use the first two together. If the gap between them is wide, you may have a workshop problem rather than a sales problem. A class that is always out at low revenue suggests a pricing question. Decide how to treat units delivered but not yet working, part days, and machines sold or bought during the period, then write those rules on the report.

All of this depends on the hold table above being right. If maintenance is logged late or returns are entered at the end of the week, the report will be precisely wrong. Making returns quick to record, on a phone in the yard, does more for your reports than any chart.