The agent keeps booking jobs an hour past the edge of the map

Stop treating the boundary as geography. The question a booking has to answer is not whether an address falls inside a shape, it is how many extra minutes this stop adds to a specific technician's day. That number changes hourly. A house on the far edge of the map is cheap when someone is already working that route on Thursday and ruinous when the only free slot is a Tuesday afternoon on the opposite side of the city.

What you will see on the board is a job whose travel swallows the slot it was sold into: a 60-minute diagnostic that costs 3 hours of a technician-day. Plot those jobs and they do not scatter randomly. They sit in one tail, at the perimeter, and usually inside 2 or 3 specific postcodes.

Prove it with a drive-time scatter

The argument is always whether this is a real pattern or 3 memorable bad days. One chart settles it in an afternoon.

1. Take 90 days of completed jobs with a geocoded service address, a scheduled date and an assigned technician.
2. For each job, compute the drive time from the nearest other stop on that technician's same day. For the first job of a day, measure from the technician's start location instead. This is the only number that matters, and it is not distance from the depot.
3. Plot drive time against job duration. Anything above the diagonal — travel exceeding on-site time — is a job that cost more to reach than to do.
4. List every job over your operator-set threshold, with its postcode, its booking channel and who created it. 30 rows is usually enough to see the shape.
5. Split that list three ways: perimeter postcodes, geocoding failures, and jobs that were deliberate exceptions. The proportions tell you which of the five causes below you actually have.

Why a postcode allow-list always leaks at the edges

Five causes, ranked by how often each turns out to be the one operating. The first two account for most of the tail.

The centroid case deserves attention because it is invisible to every other check. When a geocoder cannot resolve a specific building it commonly returns the centre of the locality or the postcode instead, silently. That coordinate sits comfortably inside your boundary, passes the distance test, and the truck then drives to a farmhouse 9 km further out. The same unresolved address is what produces a repeat caller arriving as a brand-new customer record, so one normalisation fix moves two symptoms at once.

The test that replaces the list: marginal travel

The rule to encode is the added cost of this stop, not its position. For each candidate slot, compute the extra travel that inserting this job creates in that technician's day — the detour, not the distance.

• Inside the normal envelope. Marginal travel is small enough that the job is ordinary work. Book it without ceremony.
• Reachable but expensive. The detour is real but bounded, and it may be worth doing on a specific day rather than any day. This is the band where the agent should offer the day the route already goes that way, instead of the caller's preferred day.
• Beyond policy. Marginal travel exceeds the operator's stated limit on every candidate day. The agent refuses and offers the alternative it has been given, rather than inventing one.
• Unreachable in the promised window. The address is servable in principle but not inside the arrival window this job type sells, which is a capacity answer rather than a geography one — see capacity booking versus time-slot booking.

Where the thresholds sit is the operator's decision, and it should be written down in minutes rather than kilometres because minutes are what the day is made of. What must not happen is a threshold living in a prompt. It belongs in configuration next to the reserved-capacity and bump rules, whether those sit in ServiceTitan, Jobber, Housecall Pro or your own layer, so changing 45 minutes to 60 is a policy edit rather than a redeploy. A related caution: the travel estimate the test consumes is itself unreliable if it was computed once at free-flow speeds, which is the failure in why the drive times are wrong by eleven o'clock.

A postcode tells you where a house is. It does not tell you what it costs to get a technician there on the only afternoon you have left.

The exceptions that have to be encoded

In most operators a good share of perimeter bookings are correct decisions made by people applying rules that exist only in their heads. Tightening the boundary deletes real business. Encode them instead.

• Agreement holders. A maintenance customer at the edge is owed a visit the contract already promised, and refusing them is a breach dressed as efficiency.
• Commercial accounts with multiple sites. One site may sit past the line while 8 others do not, and the account is judged as a whole.
• Equipment you installed. Warranty and callback obligations follow the unit, not the map. A callback on your own install is not an optional trip.
• Third-party dispatches. A warranty company's work order arrives with its own coverage rules, and the boundary question is different — see why a home warranty dispatch books differently.
• Genuine emergencies against your own definition. Whether the tier justifies the drive is a policy question answered once, in where the emergency, urgent and routine line actually sits, not per call.

Saying no on the call, and the approval path behind it

A hard boundary loses work that was worth having; an open one loses days. The workable middle is a soft boundary with three defined outcomes, and an agent that can reach only two of them.

1. Book it, when marginal travel is inside policy. No approval, no mention of the boundary to the caller.
2. Offer it conditionally, when the job is reachable only on a day the route already runs that way, or with a travel charge the operator has set. The agent states the condition plainly and books only if the caller accepts it.
3. Refuse and hand off, when policy is exceeded on every candidate day. The agent offers the operator's own alternative — a referral, a callback from a named person, a place on a waiting list for the next day that route runs — and never grants an exception itself.

Two notes on delivery. The boundary test needs a service address early, but front-loading address capture ahead of the caller's actual problem loses calls, as callers hanging up in the first eight seconds sets out: take the problem first, capture the address second, test third. And expect to be interrupted mid-refusal, which is why barge-in tolerance matters more than phrasing here — see how interruption handling decides whether callers trust the agent.

The same test has to run on every channel

A boundary enforced on the phone and nowhere else moves the problem rather than fixing it. The web form has to run the identical test and say the identical thing, or it silently collects perimeter leads a human refuses a day later — a specific version of a booking form that gets traffic and no booked jobs. A staffed answering service usually cannot run the test at all, having no view of the day's route, which is one of the axes in what a voice agent and an answering service each actually book.

None of this is large engineering. It is a geocoder, a travel matrix you already pay for — Google's Distance Matrix, Mapbox, or a self-hosted OSRM — a rules table, and one endpoint every channel calls. It is also the kind of business-specific logic no platform vendor will build for you, which makes it a build-or-extend decision — ground covered in choosing an AI development partner and in how we scope AI agents and automation. The rest of the intake path sits in intake and call capture, within our field service and trades work.

• intake
• service area
• routing
• booking rules