The customers on your proposed delivery run are relying on the time windows you've agreed with them. Your plan has to work for the customer near the end of the route as well as the first one. Receiving hours and the work at earlier stops affect when the driver can get there. If you're responsible for approving the run, you need to understand exactly what each customer expects to happen within the window before you can judge whether the timing is realistic.
| Schedule component | Calculation or input | What to verify |
|---|---|---|
| Arrival | Previous departure plus leg travel | Correct origin, route order, date, and travel assumption |
| Service start and waiting | Later of arrival or opening; wait until service can start | Receiving hours and early-arrival arrangements |
| Completion and departure | Service start plus the required stop duration | Unloading, paperwork, and other time before leaving |
| Closing-time slack | Window end minus the promised event time | Event definition and acceptable margin |
Define the delivery promise before routing
Put each delivery's stable ID, service address, window start, and window end in the workfile. Add a field stating whether the window applies to arrival, service start, or completion. Ask the receiving customer to confirm what the window means. A truck starting to unload before closing may satisfy a start-time promise and still fail a completion deadline.
Distinguish a firm receiving limit from a preferred window. Record any permission to arrive early and where the driver can wait. For an arrival promise, check both the opening and closing limits against the arrival time. Waiting until opening doesn't change the time the truck arrived. For a service-start promise, the start event can occur later than arrival, after any required waiting.
Keep the operating date and time zone with the timestamps. For a route crossing midnight, enter the closing time with its actual date. A closing time after midnight belongs to the following calendar day when that is what the customer means. Use a consistent time basis for the calculations, and keep the local times the driver and customer will use.
Record loading time, the planned departure, the operating-day limit, and any required return to the depot. Keep customer instructions and expected stop durations with the delivery records. These fields give the route reviewer what they need to test the order.
Review the route in Maptive
Choose Create New Map to import the workfile. Enter a name and click Continue. Upload or paste the data with headers, then click Map Now. Check the address columns in Data and Categorize Data. Window and service-duration fields can stay in the imported records for reference. Use those fields in the separate schedule calculation rather than treating them as Maptive optimization constraints.
Click the first route marker, open its tools icon, and choose Add to Route. Repeat for the remaining locations, or use Add Additional Location. Lasso & Fill Locations can collect mapped stops within a closed area. Check the selected IDs against the intended deliveries, then arrange the required order using the stacked equals controls.
Set the start and finish correctly. Maptive supports up to 73 locations in a route, so count the locations you include, including the endpoints. Optimize Route keeps the first and last locations fixed while changing the intermediate order. Check whether the finish is a depot return or the last customer before you compare alternatives.
Click Get Directions for the selected order. Use Optimize Route and Add another directions instance to keep a route comparison. Name the route with the Settings icon next to the route, then Edit Route and Save. Review the changed stop order and carry that exact order into the timestamp schedule. A shorter or more compact route still needs the customer-window calculation before approval.
Calculate each stop's schedule separately
Calculate arrival and early waiting
Give the schedule one row per delivery in route order. Start from the vehicle's planned departure after loading. For each stop, add the travel time for that leg to the previous stop's departure time. The result is the planned arrival. Use the calculated previous departure, including its service and waiting time, when calculating the next row.
Use recent travel observations for comparable legs and operating conditions where you have them. Keep the date range and source of those observations with the estimate. If you need a provisional travel value, identify it as an assumption and assign someone to check it. Missing travel evidence shouldn't turn into a zero-minute leg.
Service starts at the later of the planned arrival and the customer's opening time, provided the site is ready to receive the delivery then. Waiting is the time between arrival and service start. Add any known receiving queue or access delay to the plan where it applies, using your operating records to support the allowance.
Calculate the rows in sequence. An early wait can affect every later delivery because the vehicle leaves that stop later. If you use a different departure time or reorder a stop, recalculate from that point through the rest of the route. Keep full dates in those calculations so waiting across midnight remains positive and meaningful.
Add service time and compare the promised event
Add the stop's expected service duration to service start to calculate completion. Then add any required time after completion before departure, unless your service-duration field already includes it. Use the same definition each time. Unloading, checks, signatures, and getting back out of the site all take time before the next leg can begin.
Choose the timestamp that matches the customer's promise. Compare arrival with an arrival window, service start with a start window, or completion with a completion deadline. Check that the required event is no earlier than the opening limit where that limit applies. Then subtract the event time from the closing time to calculate closing-time slack.
Positive slack is the time left before the deadline under the stated assumptions. Zero slack leaves no room before closing. Negative slack means that stop fails the closing-time test in the current plan. Keep the result for every stop rather than checking only the final delivery or the route's total travel time.
Include loading, breaks, and the return leg in the plan. Place a break at the point where it affects the next departure instead of subtracting it from a day-wide total after the stop calculations are done. Check the final return or finish against the operating-day limit as well as checking the customer windows.
Test the weak margins before approval
Review the stops with the smallest slack first, then look backward at the legs and service events that lead to them. A late delivery can come from a long stop earlier in the route as well as the final drive. Use measured travel and stop-duration ranges to test whether the plan still works when those inputs take longer than their usual value.
Match service-duration evidence to the work you are planning. Check the load size, receiving method, and site access in the observed records before using their stop times for a new delivery. A small hand delivery may offer little support for a larger unloading job at the same address. Keep the reason for the selected duration with the schedule.
Choose the allowance from your own operating conditions and the consequence of a missed window. There isn't one useful percentage for every customer and route. A site with a firm receiving cutoff needs a different review from a customer who has agreed to a flexible arrival. Record the accepted assumptions beside the affected stop.
Change the route in Maptive if another order looks more workable, then recalculate the whole remaining schedule. Keeping the endpoints fixed during optimization doesn't preserve the appointment timing of the intermediate stops. Recheck the promised events after every order change.
A drive-time polygon can help with a separate origin-reach check. In Map Tools, open Drive Time Polygon Tool, enter the origin, set the hours and minutes, and click Add Drive Time Polygon. Its perfect-driving-condition model excludes current and historical traffic. It also doesn't account for the sequence of unloading and waiting events on a delivery round. Use it to inspect reach, then use the per-stop schedule to assess the windows.
If a negative margin remains, reduce the assigned work, use another feasible order, or discuss a different commitment with the customer. Keep the original promise until a change is agreed. Update the accepted route and schedule together once the problem has been resolved.
Compare the plan with actual timestamps
Keep the evidence traceable
Retain the route name and order, the dated departure plan, and the delivery IDs. Keep the travel assumptions, observed service-time ranges, customer event definitions, and per-stop slack in the same review file. Save the version used before the run so later changes don't erase the plan you are testing.
Collect actual arrival, service-start, completion, and departure times from your normal operating records. Use the same definitions as the schedule. A timestamp from the first unloading scan may show service start, while an entry-gate record may show arrival. Confirm what the record means before using it to prove a customer commitment.
Keep the actual depot departure too. Compare it with the planned departure before blaming all later delay on travel. If loading ran late, that difference already affects the first arrival. Avoid counting loading twice when an estimate starts from a departure timestamp that already follows loading.
Match the actual events to the delivery IDs and route date. Use those records to separate travel delay, waiting, and service duration. Maptive's route view supplies the geographic plan for this workflow. The actual timestamps and delivery evidence come from the records you collect while making deliveries.
Report the tested period honestly
Compare each actual promised event with its agreed window. To report the share delivered on time, divide the deliveries that met the defined window by the deliveries you assessed. State the period, the number of deliveries, and the event definition with the result. Mark missing timestamps so reviewers can see which promises you couldn't check.
Record exceptions that affect the interpretation, such as a receiving delay or an agreed window change. Show the original promise and the later agreement where both matter. Don't remove a failed delivery from the count simply because its reason is inconvenient. Review the cause separately from whether the original commitment was met.
Use the observed travel, waiting, and service times to improve the next plan. Check whether the tested days represent the days you intend to operate. Evidence from one less busy period supports a narrower claim than a record covering busy days and the service conditions the customer expects.
Release the route with its feasibility record
Keep the accepted Maptive route and dated timestamp schedule together. Name the person responsible for checking unresolved assumptions before the route is used, and identify any customer commitment that still needs agreement. State the operating conditions and measured period that support acceptance. After the next run, compare the actual promised events with the plan and update the travel or service inputs where the evidence calls for a change.
