The plant hire system that knows where every machine is

One screen for the desk, one for transport, one for the workshop.

A typical business running one of these has 15 to 50 staff, one or two depots, a fleet running to a few thousand items from breakers to twenty-tonne excavators, and a hire desk of two or three taking 40 to 80 hire requests and off-hire calls a day. Drivers move somewhere between 30 and 120 deliveries and collections a day, and a few dozen machines a month come in on cross-hire. Whether the desk went in during 2003 or 2018, the job it does is the same.

In the controller's words, it holds the register: every machine with its fleet number, category, hours, service dates and thorough examination dates. It takes the hire, customer, site, delivery date, rate by day or week, delivery and collection charges, then prints the contract and the delivery note. Transport works the day's movements, the off-hire call gets a number, and the workshop logs damage on return. Then the invoice run, weekly or monthly in arrears, applies the minimum periods and the weekend rules and sends the lot to Sage.

The rules it holds are what make it worth keeping:

• Minimum hire is a week for excavators and dumpers and a day for breakers and small tools, whatever the off-hire date says.
• A weekend counts as one chargeable day, and none at all if the off-hire call came in before three on the Friday.
• Off-hire takes effect from the time of the call and the number issued; if transport cannot collect within two working days, the hire still stops.
• Lifting equipment does not leave the yard past its LOLER thorough examination date: typically every six months for lifting accessories and anything that lifts people, every twelve for the rest.
• A cross-hired machine goes on the customer's contract at the yard's rate, with the supplier's cost booked against the same contract, so the margin on it is known.

None of it is written down anywhere else. The desk screen and the invoice run are the rulebook.

The hire desk was written between 2001 and 2006 in Visual Basic 6, usually by a contractor who had run a hire desk himself and knew what a weekend rule was. Around 2010 the transport and workshop screens were added in .NET Framework, often by the same contractor, so the system has two halves sharing one SQL Server database, with the invoice run exported to Sage each week. It runs on a server in the depot office, and the delivery notes still print on the carbon-copy stationery.

When the contractor retired, the support arrangement retired with him. Nobody ever wrote down how the two halves meet, so every change is a bet that the other half will not notice, and the depot stopped placing bets years ago. It cannot be opened from site, the drivers work from paper, and the machines' own hours never reach it.

The same desk built between 2016 and 2022, by a small agency or a freelancer, as a web system in React, Angular or Node or .NET Core, with a driver app in React Native. Some plant divisions used Power Apps instead, because the licences were already paid for. The desk opens in a browser, the drivers tap through a delivery note on a phone, and the bigger customers have a login that shows what is on hire.

The customer login is often where it went wrong. It read from a copy of the contracts refreshed overnight, so a machine off-hired at ten still showed as on hire the next morning, and the site managers went back to ringing the desk. A later change to the weekend rule charged a customer for a Saturday, and with no tests to show what had moved, the rule was frozen where it stood. The agency that wrote it was bought, and the new owners quote for a rewrite instead of a fix. Since 2023 some hire firms have had an off-hire app half built in an AI app builder, and those projects mostly stall where the app has to write back to the contracts. Being newer has not helped: the online desk is as stranded as the VB6 one.

Every machine either earning or accounted for, and an invoice for every day it was out.

A hire desk of two or three cannot track a few thousand items across a hundred sites by memory. The register does it. Every machine is on hire, in the yard, in the workshop or cross-hired, and the screen says which, so when a customer rings for a dumper the desk knows in a moment whether one is free.

The invoice run is the other half. Because the hire, the off-hire and the rules all sit in one place, the run bills everything that was out at the right rate, with the minimum periods and weekend rules applied every time. The off-hire number ends the argument about when a hire finished. The service and LOLER dates on the register keep the fleet legal without a separate diary, and the utilisation report by category is what decides what gets bought next spring.

Systems like this keep working. The world around them has moved.

The server went out of support in 2023. Systems like this often sit on a Windows Server 2012, which ended in October 2023, with a SQL Server 2008 R2 underneath that lost its updates in July 2019. The insurer's questionnaire and the Cyber Essentials form both ask about it, and the office has run out of ways to answer.

Two halves, and nobody who knows which owns what. The VB6 desk and the .NET transport screens talk through the database in ways the contractor never wrote down. A rate changed in one half shows up wrong in the other, so changes are now asked for only once something has already broken.

Site managers ring the desk for everything. A site manager who wants to know what is on hire at their site, or wants a machine off, has to phone. The desk reads the list out, takes the off-hire, and writes the number on a pad in case of a dispute later. Half the desk's day is those calls.

The machines report to the manufacturer, not the system. The newer excavators send hours and position to the manufacturer's portal. Neither the VB6 desk nor the browser version built later ever sees it, so the workshop keys hours from the drivers' notes and the service planner keeps a spreadsheet of the services and examinations due.

The same desk, in a browser, with the drivers, the customers and the machines feeding it.

Every one of these grows out of something the system already does.

Off-hire from the site manager's phone. A login that shows what is on hire at each of their sites, an off-hire button, and the number back by text within the minute. The desk sees it on the screen it always used.

Deliveries and collections on the driver's phone. Photos and a signature at each end, in the system before the lorry has left the site. A damage charge with a dated photo at each end is one that gets paid.

The register fed by the machines. Hours and position from the telematics the fleet already has, written against the fleet number. Services fall due on real hours, the LOLER examination dates sit beside them with a warning before each lapses, and the planner's spreadsheet is retired.

Utilisation you can see. Which categories earned last month and which sat in the yard, from the same data the invoice run uses.

Off the 2012 server. The database and the server under it both on versions that are still supported, with a backup that has been restored on purpose, and an answer for the insurer's questionnaire.

One program instead of two halves. The desk, transport and workshop screens opened in a browser, on the same data, with the minimum periods, the weekend rule, the cross-hire treatment and the customer rate cards in tables the desk can see and change.

None of it needs the old programs switched off. Each piece goes in beside them.

Hire requests in somebody else's layout, questions the desk answers by scrolling, and cross-hire invoices nobody wants to tick.

Three places stand out, none of them a decision about the fleet.

Hire requests read from the inbox. A buyer emails for a dumper and a breaker from Monday, often with a purchase order attached, and the controller keys the contract by hand. AI reads the email and the order, matches customer, site and category, and drafts the contract at the customer's rate for the controller to check against the register. Of the 40 to 80 requests and calls a day, perhaps half arrive by email, and a few minutes saved on each typically adds up to between one and two hours across the desk.

"What is on hire at the school job?" answered from the contracts. Site managers ask it all day, along with what has run past its minimum hire. AI answers in plain words from the contracts and the off-hire numbers, listing each contract behind the answer, so the desk checks and sends instead of scrolling and reading out. Across a hundred-odd live sites, that is typically the better part of an hour back each day.

Cross-hire invoices checked against the contract. The supplier's invoice arrives with its own dates and its own idea of when the hire ended. AI sets its dates and rate against the contract and flags anything charged past the off-hire number. For a few dozen cross-hires a month, a day of ticking at month end becomes an hour with the flagged lines.

Not worth doing: AI demand forecasting for the fleet. The desk knows the season and which sites are about to finish better than any model, and the utilisation report already says what sat in the yard.

The invoice run has to be tried against a copy before anything new touches its data, which puts AI after the first stage. The assessment says which of the three would pay back soonest on this hire system.

Off the old server first, then one process at a time, with the VB6 desk running until the last stage.

1. Stabilise. Source for both halves found and matched to what is running, the database and the server under it on versions that are still supported, a backup restored, and a test copy of the whole thing. This goes first because the server date has already passed, and because the two halves cannot be changed safely until there is a copy to try it on.
2. The driver app. Deliveries and collections on a phone, writing into the existing database, with photos and a signature at each end. Not one desk screen changes.
3. The customer view. What is on hire per site, and off-hire from a phone, with the number sent back straight away.
4. The desk in a browser, telematics, utilisation. The desk and transport screens on the same data, run beside the old ones; the machines' hours into the register; the utilisation report. Each a stage, each priced on its own.
5. Retire the VB6 and .NET programs when nothing still depends on them. The last thing to go is usually the invoice run, once a month of new invoices has matched a month of old ones.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a plant hire system that means a few days with the desk, the workshop and both halves of the code, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, and so does each technology the system is built on: Visual Basic 6, .NET Framework, SQL Server and Sage integrations, and for the newer generation React, Angular and Node, .NET Core and React Native. If keeping it alive is the first worry, legacy software support covers that.