Routes built on real durations
The optimiser places stops against the time they take, rather than against an average that suits none of them.
PlatformIntelligentRolling out
How long the stop takes,
learned from your own rounds.
Service time is the part of a delivery that happens after the van stops — the walk, the floor, the lift, the signature. Urbantz learns it from your completed deliveries and predicts it per task, so the plan is built on the time the job actually needs.
01/Why it matters
Two minutes out per stop.
Fifty stops. A round that ends late.
Service time is usually one fixed number: typed in by a dispatcher, sent in the payload, or produced by a script somebody has to keep current. It is the same whether the drop is a ground-floor shop or the fourth floor without a lift. Underestimate it and the driver falls behind from mid-morning on, and every ETA after that is wrong. Overestimate it and you have paid for capacity nobody used.
ETAs that survive the afternoon
The ETA is calculated from the same number, so it stops drifting as the accumulated error builds through the round.
No rule table to maintain
The model keeps up with the operation on its own, instead of someone revisiting a script each time the mix of orders changes.
It stands down when unsure
A prediction is only applied when the model is confident. Otherwise your existing service time is used, exactly as it is today.
02/Features
How the prediction is made.
Enabled for your platform, then hub by hub, so you can see it on one before it runs on all of them.
Your data, and only yours
The model is trained per platform on your completed deliveries. Nothing is pooled across customers and no other operation's patterns reach yours.
Retrained every working day
It learns from the deliveries you completed, so it follows the operation as rounds, order mix and hubs change.
What it reads
Item dimensions, floor and whether there is a lift, city and postcode, hub, task type, and when the time window starts.
Your estimate is an input
The duration you already plan is one of the strongest signals the model uses. It corrects your number rather than discarding the knowledge in it.
Measured from real rounds
Training uses the service time actually observed at the stop, taken from driver GPS, and only where that measurement was itself reliable.
Applied where it changes the plan
On announcement, on task update, and when slots are offered at checkout — the three moments the duration shapes what you promise.
You keep the override
Send a service time and it wins. Turn it off for one request, or untick automatic calculation on the task. Nothing is recalculated behind you.
Visible in the data
The predicted value and its confidence sit on the task, in the task list and in exports, and come back through the API.
03/In context
Where it sits.
- Pillar
- Intelligent
- Requires
- Completed delivery history on your platform
- Best fit
- High-volume delivery — parcel, grocery, big & bulky without added services
It predicts the delivery itself, not installation or assembly work carried out at the address — those depend on the product rather than the stop. A platform needs enough completed deliveries before the model will predict anything, and it is switched on by us per hub rather than self-served.
How far out is your
service time today?
We can measure your planned durations against what your drivers actually spent at the door, on your own completed rounds, before you change anything.