Delivery management when the team is five people, not fifty

Break-even = (minutes saved per day x 22 days / 60) x your loaded hourly cost

Why fleet software does not fit

Software for 60 vehicles is built around a role you do not have: somebody who sits at a screen all day whose only job is the board. Every design decision follows from that. Dense dashboards, configuration screens with forty options, a setup project measured in weeks.

In a five-person operation nobody is in a tool for six hours a day. The person doing dispatch is also doing invoices, answering the phone, and often driving the overflow run. They will open the screen for two minutes at 7:40am, again at 11, and again when a customer calls annoyed. Software that needs a daily driver fails that pattern, and it fails quietly: people stop opening it, go back to the chat thread, and you keep paying.

The pricing is the second mismatch. Fleet tools price per vehicle because that is how fleets budget. For five vans that often lands at a figure that is fine in absolute terms but comes with a seat minimum, an onboarding fee, or a feature tier where the thing you actually need sits two tiers up. Read the pricing of anything you shortlist for the floor, not the headline rate.

The spreadsheet is fine, until it isn't

This part gets lied about a lot. At three drivers doing a repeatable round, a spreadsheet plus a group chat is a reasonable system. It is free, everybody already knows it, and it has zero adoption risk. If somebody tells you that you are losing money every day you stay on it, they are selling something.

Here is what actually changes. Each of these is a single-condition trigger, not a scorecard — one is enough.

1. Plan-building passes 30 minutes a day. Time it for a week, honestly, including the re-dos. That is about 11 hours a month on data entry and sequencing, and it is the number to hold any monthly fee against.

2. You cannot answer a "where is it" call without phoning a driver. The cost is doubled here: your time and the driver's attention while they are at a door. Two or three of those a day is a visibility problem, not a planning problem.

3. Delivery disputes start costing real money. One a week where you cannot prove what was dropped and who took it. A spreadsheet cannot hold proof of delivery, so the evidence is a photo in somebody's camera roll, and it will not be findable in six weeks when the chargeback arrives.

4. The round only exists in one person's head. Not a volume threshold at all, and the most dangerous one. If your longest-serving driver going on holiday means a measurably worse week, the knowledge is not in the business.

5. Same-day changes have become normal. The moment a third of the day's jobs move after 9am, you are re-typing the plan rather than running it, and the sheet is the bottleneck.

No dedicated dispatcher, and the owner drives

In a five-person operation, dispatch is not a job, it is an interruption. Which means the useful question about any software is not "what can it do" but "how long does it take to do the one thing I need, from a phone, in a van, in the rain".

Three things follow.

It has to work one-handed on a phone. Not a responsive version of the desktop screen, actually usable standing up. If the reassign action takes four taps and a confirmation modal, it will not happen while the owner is parked outside a customer's house.

It has to be useful on day one with no configuration. If somebody has to define job types, skill matrices and SLA tiers before the first delivery goes through, the tool will stay half-configured forever and nobody will trust it.

It has to let the driving owner be two things at once. The owner is a driver on the board and the dispatcher of the board. Software that models those as separate users with separate logins creates a daily friction you will come to hate.

This is the case where typing an instruction beats clicking through a screen. "Move Martin's last four stops to me and send the customers new times" is one sentence at a traffic light; the same change is a dozen interactions in a dashboard built for someone sitting down.

One person off sick is 20% of capacity

A 50-van fleet absorbs an absence: the optimiser spreads 28 stops across 49 vehicles and nobody notices. At five people, one absence is a fifth of the day gone and there is no slack to spread it into.

So the question is not "can the software re-optimise". It is "how fast can I decide what not to do today, and who do I tell". Three mechanics are worth having:

• A priority field you actually fill in. When you have to shed a fifth of a day, you need to know in ten seconds which stops can move. If every job is priority normal, you will shed the wrong ones.
• A rebuild that takes one action, not a retype. Reassigning 22 stops by hand takes 20 minutes you do not have at 7am.
• A way to tell customers before they call you. The deferred stops are tomorrow's complaints unless somebody tells them this morning. A tracking link that updates itself does this without anyone typing.

Write the absence plan down once, on one page, while nothing is wrong: who covers which round, which customers can slip a day, who makes the call if the owner is the one who is sick. Most five-person operations have never written it, and improvise it four times a year.

Checking delivery management software for small business before you pay

Five questions, and you can answer all of them in a trial.

Then run the honest trial: one van, one week, both systems in parallel. It is duplicated effort for five days and it is the only test that tells you anything. If the driver prefers the app and the plan takes less time, you have your answer. If people drifted back to the group chat by Wednesday, you have that answer too, and you have saved a year of paying for shelfware. OkPilot is driven by typed instructions rather than a dashboard, which is part of why setup for a team this size is about 48 hours rather than a project: how it works and delivery management cover what that involves.