TL;DR
There is no route optimiser in this product. It is listed as planned on the top tier and deliberately not granted, which means nothing in the system will reorder your day by drive time. This post is about what a five-to-fifteen van operation actually does instead, and which parts of the schedule make hand planning less of a guess than it sounds.
Why this post is not a feature page
Most scheduling vendors sell route optimisation with a map screenshot and a number. The number is usually a percentage of fuel or drive time saved, and it is usually generated from a scenario the vendor chose.
We have not built it. Saying so is cheaper than the alternative, which is a customer discovering it after signing.
It is also worth saying that for a team of this size, optimisation is rarely the constraint. A true vehicle routing problem — dozens of vehicles, hundreds of stops, time windows, capacities — is genuinely hard and genuinely worth solving with software. Five vans and thirty stops in a city, where half the stops have a fixed time the customer agreed to, is a problem a person with local knowledge solves well in fifteen minutes. The bottleneck in a company that size is almost never the ordering of the stops. It is that the hours were never written down and the van went to the address on last month's job.
Anchors first
The method, in the order it works.
1. Place the anchors. Every job with a time the customer was promised goes on the board first, on the day it was promised, at the hour it was promised. A delivery window, a tenant who is only home between four and six, an installation that needs the building's lift booked. These do not move. Any optimiser that reorders them is solving a different problem than the one you have.
The schedule supports this directly: a job can carry an earliest start and a latest start alongside its planned time, which is how you record "any time between eight and twelve" without pretending you promised eight.
2. Cluster the flexible work by postcode. Not by customer, not by service type — by where it is. Most service companies find that four or five clusters cover eighty per cent of their work, and the clusters barely change year to year.
3. Assign clusters to people, not jobs to people. Somebody owns the southern cluster on Tuesdays. Local knowledge compounds: they know which street has no parking, which building's back entrance is faster, which caretaker is there before nine.
4. Fill each person's day from their anchors outward. Flexible work goes nearest to the anchor either side of it.
5. End the day nearest home. The last stop of the day is the one that costs you paid travel after it. Put the far one at ten in the morning, not at three in the afternoon.
Record travel as travel
This is the part most companies skip and the one that makes everything else measurable.
Reported time carries a type: work, travel or overtime. Choosing travel for the drive costs the person one tap and gives you three things.
The hours report breaks approved time down by type per person, so "how much of the week was driving" stops being an opinion. The invoice basis names travel time as restid on its own line, so a customer who is charged for it sees what they are charged for and a customer who is not still sees that it existed. And because travel starts out unbilled, a line of travel time nobody has decided to charge is carried as a zero line with a reason attached rather than deleted, so the hours on the basis still add up to the hours on the timesheet. Travel never carries ROT or RUT either way.
That last rule sounds pedantic until the first time a customer asks why the invoice says six hours when the crew was there from eight until five.
Measure your estimates, in three piles
Every job can carry an estimate in minutes. Every completed job has an actual duration, if somebody clocked it.
The orders report compares the two and counts three piles: within estimate, overran, and not measurable. The third pile is the point. A job with no estimate, or with no clock on it, cannot be judged either way, and folding it into "within estimate" would flatter the figure by exactly the jobs nobody measured.
So the first number to move is not the percentage that overran. It is the size of the third pile. A company that consistently under-quotes by two hours cannot find that out any other way, and no route optimiser fixes an estimate that was wrong before the van left.
Two practical uses once the third pile is small:
- Catalogue durations. Each service carries a default duration. If "fönsterputs, villa" has averaged 40 % over its default for six months, change the default. The estimate is what the planner packs the day with.
- Travel as a share. If travel is over a quarter of approved hours for a person, their cluster is wrong or their anchors are badly placed. That is a planning conversation, not a driving conversation.
Leave the gaps you actually need
Two details about how the schedule reads a day, because they change how you should fill one.
A break of sixty minutes or less between two runs of working hours is read as one working day. So you can record a genuine lunch — 08:00–12:00 and 13:00–17:00 — without every ordinary midday job flagging itself as outside working hours. Record the lunch. The system expects it.
A genuine split shift, though — 06:00–10:00 and 18:00–22:00 — is not merged, and an afternoon job placed into that gap is correctly reported as outside the person's hours. That is the warning working as intended.
And the conflict check is silent about drive time entirely. Two jobs forty kilometres apart with ten minutes between them are not a clash by any definition the system holds. The gap between stops is the planner's responsibility, and pretending otherwise would be the more dangerous design.
What we will not claim
Plainly, so there is nothing to discover later:
- No route optimisation. Planned on the top tier, not granted on any tier, not in the price today.
- No online booking. A customer cannot pick their own slot. Same status.
- No navigation. The system holds the address and the access notes, which only the office and the worker booked on the job can see. Getting there is the phone's map app.
- No live vehicle tracking. Position is read when somebody taps a button, not continuously. There is a whole post on what GPS in a field app can and cannot do.
The honest summary
If your constraint is genuinely routing — you have twenty-plus vehicles, hundreds of daily stops and capacity constraints — buy a routing product and integrate it. That is a real category and it is not this one.
If your constraint is that the week lives in a spreadsheet, that the promise made on the phone never reached the board, and that nobody knows how many hours went to which job, routing is the fourth problem on the list. Fix the first three and you will find the fourth was smaller than it looked.