Field Visit Itineraries: A Map of Jobs Is Not an Optimised Schedule

If staff visit several customers in a day, specify whether the app should display jobs on a map, show an agreed visit order or calculate a new order. Those are different deliverables. A line joining map pins does not prove the schedule is practical or optimised.

Start with a daily itinerary your team can explain. Add automatic scheduling only when you can state the constraints it must respect and demonstrate the resulting decisions.

Separate the map from the plan

A map answers where the jobs are. A visit list says in what order someone intends to do them. Navigation provides directions for travel. An optimiser would need an agreed objective and constraints to propose a sequence; do not use that word merely because the app draws a route.

The Odoo 19 itinerary guide is a useful bounded example. Its default field-service map pins the day's task locations. It describes displaying an itinerary through a Mapbox integration and sorting tasks by Planned Date. That is not a documented claim that the system finds the shortest route or schedules every appointment around traffic.

For your brief, say whether staff follow fixed appointment times, a dispatcher-approved order or a flexible sequence. A “sort by date” feature should not quietly move a customer's agreed appointment.

Record the constraints before requesting optimisation

List the requirements that make a visit possible: service duration, customer time window, travel time allowance, required technician or equipment, breaks and the working day's start and finish. Decide which are firm restrictions and which are preferences. These are proposed planning inputs, not features established by the cited Odoo page.

For a fictional service team, a short route may still be unusable if the second customer only accepts morning visits. Ask the developer to show a feasible result or an explicit unresolved conflict. A polished route must not conceal a visit the plan cannot accommodate.

Also specify the day's starting and ending points. Home, depot and the first customer's address are not interchangeable. If the start changes during the day, decide whether the remaining plan is recalculated, proposed for approval or left alone.

Define what opening navigation hands over

Odoo documents a View in Google Maps action that includes the current location as the itinerary's start. In your implementation, test the actual handoff rather than assuming the displayed job order survives every navigation app or device.

Agree whether the button opens one destination or the whole remaining itinerary, which navigation services are supported, and what happens when the preferred app is unavailable. Let staff identify the destination before leaving the job screen. An appointment should remain unfinished when navigation opens; directions are not evidence of arrival or completed work.

Review which customer details and locations are sent to the navigation provider. A daily itinerary also does not imply permission to record a worker's location continuously. Treat any tracking proposal as a separate scoped and reviewed feature.

Make changes visible without rewriting the day

Decide how a cancelled visit, urgent insertion or technician reassignment reaches the person using an older plan. Show which plan is current and require the agreed acknowledgement where operationally necessary. Do not let dragging a stop silently notify a customer or change a promised time.

Keep unplaced or conflicting jobs visible in a review list. If an address cannot be mapped, the job must not disappear from the workload merely because it lacks a pin. Offline access and stale navigation need their own tested rules; the source does not establish either capability.

Demonstrate an awkward working day

Put a realistic synthetic day into the acceptance criteria: fixed appointments, a flexible visit, a missing map point and a cancellation after the itinerary was opened. Inspect order, unresolved work and navigation handoff on the supported devices. If optimisation is included, test the agreed constraints and what happens when no feasible plan exists.

For a field-service app discussion, bring the dispatch rules rather than only a screenshot of a map. The useful outcome is a plan staff can follow and revise deliberately, not an unsupported promise of the fastest day.