A dispatcher orders the stops by proximity and gets a route that looks tidy. The first shop will not receive until late morning, another requires a vehicle with suitable equipment, and unloading at the third takes much longer than the plan allows. Multi-stop delivery optimisation software becomes useful when it makes those conditions explicit before the vehicle leaves.
The shortest line is only one possible objective. A business may first need a feasible plan, then fewer unassigned orders, then a reasonable balance of travel and vehicle use. This guide explains how to evaluate that planning capability using TrackAsia's documented VRP inputs and outputs, while keeping order operations, approval and driver communication in the surrounding application.[6]
Describe the day before asking for an optimum
Start with a real planning question: which jobs must be performed, by which available vehicles, under what conditions? A route optimiser cannot infer a customer's receiving window from a street address or know how long unloading takes from the number of stops. Missing conditions produce a different problem from the one the dispatcher believes is being solved.
Use an illustrative depot with several shop deliveries, two vehicles and one customer pickup. Some customers accept deliveries throughout the shift; one has a narrow receiving window. This is a proposed evaluation scenario, not a reported deployment or an achieved saving. Its purpose is to expose the decisions that a short demo can hide.
The pickup needs special attention. If the collected goods must be delivered to another location on the same trip, that relationship is different from two independent visits. If goods merely return to the depot, a different model may be sufficient. Agree on what physically moves before choosing fields in a request.
Set the planning horizon too. A morning run, a whole day and a multi-day schedule are not interchangeable. The first pilot should use a horizon that operators can review completely, with known starting locations and shift limits. It is easier to identify an incorrect assumption in one depot-day than in an apparently impressive network-wide plan.
Turn operational conditions into usable inputs
TrackAsia VRP v1 documents jobs, shipments and vehicles. Jobs represent tasks; shipments connect pickup and delivery steps. The model includes service durations, time windows, capacity, skills and priorities. Coordinate arrays use longitude,latitude, timings use seconds and distances use metres.[6] Those conventions should be written into the import specification, not left to each spreadsheet owner.
Use unique integer task identifiers for the API and keep a mapping to your order references. A result containing a task ID must lead back to the exact business work. Do not substitute a spreadsheet row number if sorting or filtering can change it between planning and reconciliation.
Confirm locations before solving. A point in the centre of a building may be a poor representation of a loading entrance. Keep a status for unknown or unreviewed locations, and decide whether such work is excluded pending correction or handled separately. Hiding an unlocated order from the input without showing it to dispatch creates an apparently successful but incomplete plan.
Capacity arrays can represent several dimensions, such as item count and weight, according to the documentation.[6] Every participant must use the same dimension order and unit. A vehicle capacity [100, 500] is meaningless until the business agrees what each number means. Do not assume the optimiser will infer kilograms, cartons or cubic volume.
Service duration should reflect work at the stop. Setting every stop to zero can make a route pass a time-window check while leaving no time to unload or obtain confirmation. Begin with defensible estimates by stop type, then improve them with observed data. Treat those estimates as assumptions, not measured facts until observations exist.
A small input example reveals the modelling choices
The following JSON is an illustrative problem body using documented fields. It uses a relative horizon: zero is the start of the planning period, not midnight or a Unix timestamp. It demonstrates data structure, not a guaranteed solution for a particular operating day. The VRP endpoint documented by TrackAsia is /api/v1/vrp; confirm the current request arrangement and account configuration when integrating it.[6]
{
"jobs": [
{"id": 101, "location": [106.70, 10.78], "service": 600,
"delivery": [8], "time_windows": [[1800, 10800]]},
{"id": 102, "location": [106.72, 10.80], "service": 900,
"delivery": [12], "time_windows": [[0, 14400]], "skills": [1]}
],
"vehicles": [
{"id": 1, "profile": "car", "start": [106.68, 10.76],
"end": [106.68, 10.76], "capacity": [25], "skills": [1],
"time_window": [0, 14400]}
]
}Here the quantity dimension is defined by the example as cartons. The first job cannot start service before 1,800 seconds into the horizon; the second requires skill code 1, which the vehicle has. Skill codes are application-defined eligibility labels, not automatic proof that a truck satisfies road restrictions or a driver has been professionally certified.
Returning to the depot is explicit because start and end are the same. The documentation explains that omitting an end allows the route to stop at its last task.[6] That choice affects the apparent plan cost. Comparing a closed route with an open route and calling the difference “savings” would be misleading.
Distinguish hard requirements from preferences
A receiving window may be a genuine restriction or a preference that a customer can renegotiate. Vehicle capacity is a physical condition, while a preference to keep familiar territories may be operationally negotiable. Do not encode every habit as an absolute restriction without considering the effect on feasible assignments.
TrackAsia documents time windows for service start, vehicle working hours, eligibility through skills and priority values for tasks.[6] Priorities influence which tasks tend to be included when not all can be served; they should not be described as a guarantee that a high-priority task is always feasible.
The interpretation of a time window matters. If the documented constraint is service start, a business that requires unloading to finish before closing needs to model or validate that additional requirement deliberately. Ask the implementation team to show an example at the boundary rather than assuming the two meanings are identical.
Likewise, an equipment skill can express that only certain vehicles may serve a task. It does not make routing legally suitable for every vehicle dimension or road rule. Keep vehicle eligibility, road routing and site access as related but separate checks. Confirm any required restriction support directly instead of inferring it from a field name.
Read unassigned work before celebrating the route
VRP output includes a status code, summary, routes and unassigned tasks. The documentation separates travel duration, service, setup and waiting time in its indicators.[6] The application should preserve those distinctions rather than showing one attractive number labelled “total time.”
Every input task must be accounted for: assigned to a vehicle, explicitly unassigned or rejected before the solve with a visible reason. Reconcile IDs mechanically. A successful request with unassigned work may be a useful answer, because it exposes insufficient capacity or incompatible conditions. It is not the same as a complete dispatch plan.
Do not manufacture an exact explanation from an output that only identifies the unassigned task. The application can guide investigation through location, capacity, skills and windows, but should distinguish a confirmed cause from a suspected one. An operator may need to relax a condition, add a vehicle or contact the customer.
Check the released plan independently against the business rules that matter. Confirm quantities, service-start windows, required eligibility and shift endpoints. This provides a defence against data mapping errors and assumptions outside the solver model. It also gives dispatch a plain explanation of why a plan is usable.
The solver is one component of delivery software
An API calculates a candidate plan from a problem description. The surrounding software receives orders, validates data, manages permissions, presents exceptions, approves a version, communicates work and records what actually happened. Those responsibilities remain even when optimisation is purchased as a service.
A simple architecture has four boundaries: order intake, planning data preparation, optimisation, and execution. Keep the original order record outside the solver request. Store the input version and output together so a dispatcher can reconstruct which conditions produced a plan. Publish only a reviewed version to drivers.
TrackAsia presents TMS separately with planning, order and driver management, tracking, reports and integration capabilities.[7] Evaluate that product if the missing capability is the whole operating workflow. If a business already owns those functions, the VRP API can be a focused planning component. Compare the actual implementation and ongoing responsibilities of both paths.
Maps are still useful for reviewing a plan, but they should be accompanied by a task list and exceptions. A line cannot show whether one order was omitted, a carton unit was misread or a customer window was applied in the wrong timezone. The data view and geographic view should explain the same approved version.
New orders during a shift need an operating rule
A fresh order arriving at noon should not silently reshuffle every driver's remaining work. Some tasks are complete, some are in progress and some have commitments already communicated. Decide what may change and who must approve it before implementing repeated optimisation.
Replanning requires an updated description of available vehicles and remaining work. Completed tasks should not be treated as unvisited jobs again. A current vehicle position and current load may matter, but they need reliable input. Do not pretend the original morning depot start still describes a vehicle already on the road.
The VRP documentation discusses vehicle steps and different uses in planning and solving modes.[6] Do not assume that supplying an initial sequence always freezes it exactly. Confirm the documented semantics of the chosen integration and independently enforce your application's release policy.
When a change is approved, record the new version, affected work and acknowledgement process. The driver should know whether the old instruction has been replaced. If a device is offline, the system needs a reconciliation path rather than assuming that a successful API call also delivered the new instruction.
Compare plans on equal work and constraints
Replay an anonymised day using the same tasks, start/end conditions, service durations and windows for both the existing and proposed plan. Separate source-data corrections from optimisation effects. If the new plan uses better coordinates, report that improvement honestly rather than attributing all of it to the solver.
Proposed evaluation measures include assigned-task coverage, travel duration, waiting time, service time, vehicles used, manual edits and planning effort. Add execution measures after the plan is run, such as actual completion and unresolved exceptions. These are evaluation ideas, not claimed TrackAsia results.
Use cost categories appropriate to your operation. Travel distance alone may miss vehicle availability, driver time, subcontractor minimums and failed delivery cost. Conversely, an internal optimisation cost is not automatically a currency invoice; the documentation identifies cost values as part of the optimisation objective.[6] Explain how your commercial analysis maps to those values before presenting a monetary result.
The strongest next step is a small data-backed test with a deliberately impossible task as well as normal jobs. Ask TrackAsia or the implementation team to show the input mapping, unassigned output, operator decision and released plan. Choose software that makes an executable day easier to understand, not merely a route picture shorter to look at.
Try the source: Sequence stops with time windows
Evaluate six permutations for three time-window stops; change departure time to test feasibility.
Illustrative data and assumptions; not TrackAsia product UI, customer results or a quote.
Unzip, run python3 -m http.server 8080 in the extracted folder, then open http://localhost:8080/index-en.html. Vietnamese and English READMEs are included; no npm or build step is needed.
