Add route optimisation to an existing dispatch workflow

Start with the operational bottleneck

Dispatch planning is constrained work: vehicle capacity, delivery windows, driver availability, depot processes, loading order, and customer exceptions all matter. A route that looks short on a map may be operationally impossible.

Begin with a structured view of a normal planning day and a difficult one. Record the constraints dispatchers actually use, including those that currently live in notes or experience. Identify which are hard requirements and which are preferences that can be traded off.

Design the target workflow

Extract jobs and resource availability from the transport-management system. Validate locations, time windows, capacities, and identifiers before optimisation. Use a routing solver or an evaluated planning service for the constrained search. A language model can help classify free-text notes or explain a proposed plan; it should not replace the solver with a plausible narrative.

Return the route, unmet constraints, assumptions, and changes from the previous plan. A dispatcher reviews exceptions and releases the accepted version. New work or a vehicle failure creates a replanning event with its own version rather than silently altering a driver’s instructions.

Connect to the existing systems

Connection	Information	Control
Transport-management system	Jobs, windows and resources	Validate and version the planning snapshot
Optimisation component	Constraints, objective and candidate routes	Expose infeasible or relaxed constraints
Dispatch interface	Reviewed plan and operational exceptions	Require release by the dispatcher

Use stable identifiers and versioned inputs. A retry should resume the same piece of work, with the original permissions and evidence attached. Treat an upstream outage as a visible workflow state.

Fit the model to the task

Choose models by subtask. Text extraction and note classification can use a small local model. Route optimisation is generally a structured optimisation problem. Stronger language reasoning may help explain exceptions, but only validated constraints should enter the solver.

Keep a clear human boundary

Dispatchers own the release and can override a proposal with a recorded reason. Include breaks, capacity, delivery restrictions, and uncertainty in travel time. Keep manual planning available when data quality or service availability is insufficient.

Measure the complete operating cost

Measure planning effort, constraint violations, rework after release, and the chosen operational objective. Include solver charges, integration, map data, and maintenance. Do not attribute changes caused by demand or fleet availability solely to the planning system.

Pilot checklist

• Capture hard constraints and soft preferences explicitly.
• Validate addresses, capacities, and time windows.
• Test impossible schedules and last-minute resource loss.
• Compare against dispatcher baselines on the same jobs.
• Retain plan versions, override reasons, and manual fallback.

Agree on acceptance thresholds before testing, then compare the proposed workflow with the same work handled through the current process. Expand only after the operation can explain both successful and failed cases.

Further implementation detail

• Choose the lowest-cost model that meets the task requirements
• Serve a local model to a team
• Ollama’s local API reference