Travel time configuration in Field Service

For service organisations dispatching technicians, travel time is often a quarter to a third of the working day. Underestimating it causes missed appointments and angry customers; overestimating it wastes capacity. Dynamics 365 Field Service builds travel time into the scheduling and dispatch model — but the configuration controls how realistic the numbers actually are.

Source of travel times. Field Service uses Bing Maps (or alternative map providers, configurable) to compute travel time between locations:

• Resource start location → first booking location.
• Booking → next booking.
• Last booking → resource end location.

Travel time is a function of:

• Distance (straight-line vs road network).
• Mode (driving, walking, public transit).
• Time of day — Bing Maps factors in traffic patterns.
• Day of week — weekday rush hour differs from weekend.

For non-real-time scheduling (planning tomorrow), historical traffic patterns are used. For real-time re-optimisation (during the day), live traffic data refines the estimate.

Configuration. Each resource has:

• Start location — where they begin the day (typically home address; can be the depot).
• End location — where they end the day (often the same as start).
• Travel mode — Driving (default), Walking, Public Transit, Cycling.
• Travel charges — billable hourly cost during travel (typically reduced from on-site billing rate).

Booking-level travel. Each booking has a separate travel time field showing the calculated travel from the previous booking (or start location). The schedule board displays travel as a grey block before each booking, visually showing how much of the day is on the road vs on customer site.

Constraints. Travel-aware scheduling respects:

• Maximum travel time per booking — refuse to schedule a job that would require more than 90 minutes of travel.
• Maximum daily travel — cap the total travel across all bookings in a day.
• Resource territory boundaries — keep bookings within the resource's geographic area.
• Optimisation weights — minimise travel as a scheduling objective (see the Resource Scheduling Optimization guide).

Cross-day travel. For multi-day projects (e.g. installation jobs spanning several days at the same customer), the system models overnight stays and morning return travel rather than calculating one massive travel time. Configure overnight policies per resource.

Real-time updates. As the day unfolds, actual travel times diverge from planned. The mobile app captures real-time positions; the schedule board updates predicted arrival times for downstream bookings. Customers can receive arrival window notifications based on updated estimates.

Travel charges. Many service organisations charge customers for travel time at a different rate from on-site work. The configuration lets travel post to a separate revenue line (or be embedded in the on-site charge). Per-customer overrides handle contracts that include or exclude travel charging.

Alternative routing providers. For customers needing more sophisticated routing (commercial vehicle routing with weight/dimension constraints, hazmat routing, multi-stop optimisation beyond what Bing offers), integration with commercial-vehicle-routing services is available through partner ISVs.

Common pitfalls.

• No resource start location configured — defaults to a generic point and produces wild travel estimates.
• Outdated location data on customers — drives wrong travel calculations. Validate customer addresses periodically.
• Travel as billable / non-billable confusion — be explicit per contract whether the customer pays for travel.
• Cross-region routing — Bing maps quality varies by region; verify for less-mapped countries.

Operational reality. Travel time accuracy directly drives schedule reliability. Spending the configuration time on it returns hours of dispatcher work per week and reduces customer "where's my technician" calls.