Boosting utilisation by 20% with a bespoke real-time scheduler

The client's customers are spread across the whole of the UK, and the work happens on-site, outdoors, in conditions that have to be right. Too much wind or rain and the job cannot go ahead. To sharpen it further, the busiest stretch of their year falls at the start of it, exactly when British weather is at its worst.

Count the cost of one bad call. A crew drives three hours to site. The weather rules the job out. The day is now three hours of fuel and wages spent travelling to produce nothing, the slot the customer held is gone, and the rebooking has to be squeezed into a calendar that was already full, in the busiest month, disturbing jobs that were fine. One cancelled visit ripples through a week.

They already ran a scheduling system, and it did the routing part of its job well. What it could not see was the sky. The office was left checking forecasts by hand, job by job, town by town, which works up to a point and stops working the moment the schedule gets busy, which is precisely when it matters.

A shared calendar shows where people are meant to be. A real-time scheduler knows things: which jobs exist and how long each takes, who is qualified for what, how far apart the sites are, and what constrains each visit. When something changes, a cancellation, an overrun, a new urgent job, it recalculates and shows the office the consequences immediately, rather than leaving someone to discover them with a highlighter on Friday.

That is why these builds are substantial. The scheduler is not a diary. It is a working model of the operation, and it is only as good as the constraints it knows about. This client's operation had a constraint their system did not know about, so we gave it one more input.

We could not stop the rain falling or the wind howling. What we could do is make sure nobody schedules against them blind. The new scheduler integrates with OpenWeatherMap's API, so at the moment a job is being placed into the calendar, the person placing it sees the wind and rain outlook for that job's location on that date, anywhere in the UK. No second screen, no checking by hand. The forecast became a property of the job, sitting right where the decision gets made.

Forecasts change, so the system keeps watching them after booking. When the outlook for a scheduled job turns, the office sees it with days in hand, while the visit can still be moved cheaply, instead of finding out from a crew standing on site watching the rain come in.

A reschedule is only as good as how fast the customer hears about it, and a change the customer learns about late is a complaint even when the reason is the weather. So the second half of the build extended an existing Vonage integration to let the team text customers directly from the scheduler, choosing from message templates that fill themselves in with the customer's details and the specifics of their order.

What used to be an afternoon of phone tag became a few seconds per affected customer, which is the difference between actually doing it and meaning to. The same mechanism that spots the problem early is the one that tells the customer early. Those two halves work together or not at all.

And the routing the old system did well was not thrown away. The new scheduler kept it: each field worker's day ordered to keep time on the road down, out to the various sites and home again with as little dead mileage as the geography allows.

After investing in the system, the client's own assessment is that utilisation of their field team rose by more than 20 per cent. It is worth pausing on what that number means, because utilisation gains compound in a way headline figures rarely convey. A ten-person field team doing 20 per cent more chargeable work is delivering the output of two additional workers, without recruiting them, paying them, or putting two more vans on the road. The capacity was already being paid for. It was being spent on motorways and cancellations.

The knock-on effects follow the same direction. Fewer wasted journeys means less fuel bought and less carbon produced for the same completed work. Workers on commission complete more jobs, and better routing gets them home earlier, which matters for keeping good people. And customers wait less: more completed visits in the same weeks shortens the queue, and the ones who do get moved hear about it days early by text rather than on the doorstep.

Not every business should build one, and it is cheaper to know in advance. The signals that a bespoke scheduler will pay for itself look like this: a field team big enough that a percentage point of utilisation is real money, work constrained by things generic tools do not model, whether that is weather, qualifications, equipment or site access windows, a high cost per wasted journey, and a utilisation number you actually measure and know to be lower than it should be.

If your field team is a van or two doing unconstrained work, an off-the-shelf field-service tool will do the job at subscription prices, and building would be the wrong call. Where the constraints are genuinely yours, though, the arithmetic changes: a build in the £30,000 to £75,000 band we publish for departmental systems against the standing cost of a field team spending a fifth of its time unproductively is not a close decision.