Geofences and contacts

Two things turn a location from an address into something the system can act on: a radius that decides when a driver counts as having arrived, and a set of people who can be reached there. Both are easy to misplace, because neither lives quite where you would first look.

There is no geofence field on a destination or an origin. The radius belongs to the stop — the visit — not to the place, because the same warehouse can warrant a tight radius on a precision delivery and a loose one on a bulk drop. Three layers resolve it, each overriding the one above:

The organisation-level controls sit together under the Geofence group of Customization → Operations:

• Arrival radius — how close counts as being there. Defaults to 150 m, and the panel previews the circle as you drag it.
• Approach radius — the wider ring at which a vehicle is treated as approaching. Defaults to 500 m.
• Dwell time — how many seconds inside the arrival radius before arrival is confirmed. Defaults to 30, and exists so a red light outside a customer’s gate is not recorded as a delivery.
• Auto arrival update — whether arrival metadata is written onto the manifest automatically. Off by default.

When a stop is marked arrived with a position attached, two things are recorded on it: how far the driver was from the pin, and whether that distance fell outside the effective radius. An arrival with no GPS fix records neither — it is not counted as inside or outside, it is simply not sampled.

Those two values then feed everything downstream. An arrival outside the radius can raise an Arrival Outside Geofence exception, and across many visits they aggregate into a per-destination health figure. See Exceptions for what happens to the flag once it is raised.

A destination whose recent arrivals keep landing outside its radius shows a Geofence may be misconfigured banner on its detail page, quoting the share of sampled arrivals that fell outside and how many were sampled. It appears only when the sample is large enough to mean something, so a single odd delivery will not trigger it.

It is a data-quality signal, not a driver-behaviour one. Drivers who all stop in the same wrong-looking place are usually stopping in the right place, and the pin is what is wrong.

Destinations and origins each carry a contact name, phone and email. On a destination’s overview these render as a tap-to-call number and a mailto link, so the person handling an exception can reach the site without leaving the page. They are the site’s directory entry: who to ring when a driver is at the gate.

The bridge between the two is the destination’s default tasks, configured on its Tasks tab. Each default task has its own contact name, phone and email fields, and the whole blueprint — title, type, required proofs, contacts — is copied onto every stop created at that destination, whether the stop came from the trip builder or from a delivery pool. Put the recipient’s address on the default task and every future delivery there mails the right person, configured once.

Defaults are only seeded into a stop that has no tasks of its own, so a dispatcher who has already edited a stop never has their work overwritten. They can be reviewed, edited and removed before the trip is submitted.