Dispatch radius: a travel-time boundary that only looks like a circle
In short
A dispatch radius is the boundary of what a provider can reach within an acceptable travel time. It is directional, because outbound and return differ, and it moves with the hour. The straight-line circle every platform starts with is a proxy for it, and the proxy fails wherever a river, a motorway with no junction, a one-way system or a rush hour sits between the two points.
Key takeaways
- Radius, coverage area and reachable set are 3 different objects. Only the 3rd describes what a provider can actually do.
- A single-bridge river makes the boundary asymmetric: 4 km north can cost more minutes than 12 km east.
- Declared, revealed and modelled coverage rarely agree. The gap between declared and revealed is a measurable number.
- Distance is a legitimate prefilter and an illegitimate answer. Filter wide on distance, then rank the shortlist on travel time.
- In PostGIS the geography type measures in metres and the geometry type in SRID units, so a radius on a lat-long geometry is degrees.
A dispatch radius is the set of jobs a provider can reach in an acceptable travel time. Every platform implements it as a circle at first, because a circle is one number and one index, and the circle is wrong in a specific and predictable way: it over-serves whichever directions have good roads and under-serves whichever directions have a river, a rail line, a motorway with no junction, or a city centre in the way. A provider 4 km away across a single bridge can be further in minutes than one 12 km out along a dual carriageway.
The failure is not that the distance number is inaccurate. It is that the platform answers a question about time using a measure of space, and then treats the resulting declines as a provider problem.
Radius, coverage area and reachable set are not the same thing
| Object | What it is | Where it comes from | Honest use |
|---|---|---|---|
| Radius | A single distance from a point | A number a provider typed into a form | A cheap prefilter over a large index |
| Coverage area | A declared polygon or list of districts | The provider drawing where they want work | Eligibility and commercial intent |
| Reachable set | Everywhere within N minutes of travel | A routing engine, per origin and per time of day | Deciding who is genuinely offerable |
The same provider, drawn two ways
| Direction from base | Inside an 8 km circle | Reachable in 20 min at 09:00 | Reachable in 20 min at 14:00 |
|---|---|---|---|
| North, across a single-bridge river | Yes | No | Marginal |
| East, along a motorway with a junction | Yes | Yes, with room to spare | Yes, with room to spare |
| South, through a dense centre | Yes | No | Marginal |
| West, suburban main road | Yes | Yes | Yes |
The circle says yes 4 times; travel time says yes twice at nine in the morning. Every disagreement reaches a provider as an offer to decline, and declines cost the buyer waiting time and feed straight into whatever the platform treats as an acceptance signal.
Where they will go, and where you believe they will go
There are 3 coverage figures for every provider and they are rarely equal. Declared coverage is what they set in their profile, usually optimistic and rarely revisited. Revealed coverage is where they actually accept work, and you already hold it in your acceptance data. Modelled coverage is what the dispatcher believes.
- Compute the gap. Per provider, the share of offers accepted inside 5 km against the share accepted beyond 15 km summarises how honest their declared radius is.
- Shrink modelled coverage towards revealed coverage, and tell the provider you have done it. A silent shrink reads as the platform starving them, and that is how a good provider starts taking repeat customers off-platform — where what counts as a deal that left the platform begins.
- Keep the boundary out of the ranking function. Reachability is an eligibility filter; how good a match someone is, is a score. Collapsing the two is the confusion unpicked in signal, score and sort order.
Computing it without a routing call per candidate
- Prefilter on distance, generously. A spatial index answers "within 15 km" in a millisecond, and it only has to return a superset of the answer.
- Mind the units. In PostGIS, ST_DWithin on the geography type measures in metres; on the geometry type it measures in the units of the spatial reference system, so the same call against lat-long geometry is asking about degrees.
- Send the shortlist to a matrix service. An OSRM table request returns durations in seconds and, on request, distances in metres along the fastest route, with nulls where no route exists. Those nulls are information.
- Cache by time bucket. Travel times repeat weekly far more than they vary randomly, so a matrix keyed on origin, destination cell and hour-of-week is reusable.
- Define the degraded mode first. When the router is slow, fall back to distance with a tighter threshold, and record which mode each dispatch used so decline rates can be attributed later.
That fallback is not a detail. A dispatcher is an unattended system making commitments on behalf of people who are driving, so its behaviour when a dependency fails is part of the design — the argument in what breaks when AI agents run in production, and why our AI agents and automation work insists on a written degraded path.
A circle is a statement about the map. A reachable set is a statement about the road, the hour and the person driving it, and only one of the three is a constant.
What the boundary is not allowed to decide
- It is not a ranking signal. Being 6 minutes away rather than 11 may be worth points, but eligibility and preference are separate stages, and mixing them makes both untunable.
- It is not a distribution rule. Who is offered the job, in what order and how many at once, is the separate choice in the four shapes a lead can be handed out in.
- It is not a substitute for waiting a moment. Assigning to whoever is nearest the instant a request lands allocates worse than holding a short window and solving the batch — the case in why waiting two seconds beats nearest-first.
- It is not one number per provider. A boundary that does not vary by hour, vehicle and job length is wrong at least twice a day.
The rest of this silo — ranking signals, allocation rules, acceptance behaviour and what changes when supply is thin — sits under matching, ranking and dispatch, part of our marketplaces and platforms practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a dispatch radius?
The boundary of the work a provider can reach within an acceptable travel time. Most platforms store it as a straight-line distance because that is easy to index, but the thing being approximated is a time, so the true boundary is irregular, different in each direction, and different at each hour of the day.
Should a marketplace match on travel time or straight-line distance?
Both, in that order. Straight-line distance is the right prefilter, because a spatial index answers it instantly and only needs to return a superset of the candidates. Travel time is the right decision measure, applied to that shortlist through a routing or matrix service. Using distance for the decision is what produces offers no provider can accept.
Why do providers decline jobs inside their stated radius?
Usually because the radius was declared, not measured. A provider types a number describing their ambition, then declines the jobs across the river, in the centre at rush hour, or at venues where parking and access eat half an hour before the work starts. Comparing accepted against offered by direction and hour turns that into a number you can act on.
How do you handle service areas that are not circles at all?
Store the declared area as a polygon or a set of districts, keep it separate from the modelled reachable set, and treat the intersection as eligibility. The polygon carries commercial intent — where a provider wants work — while the reachable set carries physical reality, and neither substitutes for the other.
- dispatch
- geospatial
- matching
- service areas
The work behind this page
Builds from our portfolio that this page draws on.
FieldRoute
An AI field-service platform that auto-dispatches the best-matched technician, optimizes routes, and tracks first-time-fix against every SLA.
OperationsHaulBoard
An AI freight load board that matches every open load to the best-fit carrier, prices each lane on live spot-rate data, and tracks broker margin on every move.
LogisticsRead next
- Lead distribution: the four shapes a request can reach sellers inBroadcast, sequential offer, shortlist, exclusive assignment. The shapes differ in who pays when nobody answers, which is also the question that identifies yours.definition
- Signal, score and sort order: three layers people keep collapsingA signal is a measurement, a score is policy and a sort is a product rule that can ignore both. Most ranking arguments are two people proposing changes at different layers.definition
- A handful of sellers are taking everything: is it the ranker or the market?Concentration is only a defect if your ranker built it. Re-rank the same queries with every history-derived signal removed, and the share distribution tells you which answer you have.diagnostic
- Acceptance rate: what it measures, and when it measures the platformAccepted over offered sounds like a measure of a seller. The platform chooses the denominator, so an uncorrected acceptance rate is partly a measure of your own targeting.definition
- Matching got slower as supply grew: which stage stopped being linearPlot each stage's duration against candidate-set size on log-log axes. The slope names the stage that stopped being linear, and each stage has a structurally different repair.diagnostic
- Availability: a set of intervals, not a grid of day cellsAvailability is not a stored fact. It is the answer to a question, computed from recurring rules, exceptions and what has already been consumed — and a day-cell table is a cache of that answer.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation