Every stop on a tour in Orbit has two time windows. Understanding the difference, and what the TimingGuide is not, helps you plan tours that actually run on time.
The hours agreed with the shipper, consignee, or customer, for example "pickup between 09:00 and 12:00". These come from the order and describe when the customer is available at the stop.
The operationally possible time window at the stop, calculated automatically from the tour's route plan. It is always equal to or narrower than the booked window.
This is the most common misconception. The TimingGuide does not tell you when the vehicle will actually arrive or leave. It only defines the boundaries within which arrival and departure are allowed to happen without breaking the rest of the tour.
- It is not an ETA.
- It is not the planned arrival time.
- It is not the planned departure time.
- It is a corridor of allowed times for servicing the stop so that the tour as a whole remains feasible.
The actual arrival can land anywhere inside this corridor, depending on traffic, the tour's start time, and what happened at earlier stops.
For each stop, the TimingGuide gives you:
- The earliest sensible arrival time: arriving earlier adds no value, because the previous stop isn't finished yet, or the customer isn't open.
- The latest possible departure time: leaving later means downstream stops can no longer be reached within their booked windows.
The booked window only tells you when the customer is available. It doesn't tell you whether the stop can realistically be served while keeping the rest of the tour on time. The TimingGuide takes into account:
- Driving time between this stop and neighbouring stops
- Expected service time at the stop (loading / unloading)
- Booked windows of all other stops on the same tour
Orbit runs a forward pass (starting from the tour's first stop) and a backward pass (starting from the last stop) across the full route, and intersects the results with each stop's booked window.
A tour has two stops:
| Stop | Booked window | Service time | Next leg |
|---|
| A | 09:00–12:00 | 30 min | 90 min drive |
| B | 12:00–13:00 | none | none |
To arrive at B by 13:00, the driver must leave A by 11:30. With 30 minutes of service time, arrival at A must happen by 11:00. The customer at A books until 12:00, but leaving A any later than 11:30 would make B miss its window. So the downstream route, not the booking, sets the latest departure from A.
Orbit surfaces this as: TimingGuide window at A = 09:00–11:30, the booked window tightened at the back end by the downstream route. At B the booked window already holds: the earliest arrival the route allows is 11:00, before the window opens, so the TimingGuide window at B stays 12:00–13:00.
Again: this does not say the driver will arrive at 09:00, nor at 12:00, nor at any specific moment in between. It says: "the stop must be served somewhere in this window, otherwise the tour breaks."
If no feasible TimingGuide window exists for a stop, meaning the booked window is too tight to fit both the drive leg and the service time, Orbit flags the stop with a Time Window Conflict.
This is a planning warning, not an execution error. The tour can still be dispatched, but it is unlikely to run on time. Typical resolutions:
- Reorder the stops
- Renegotiate the booked time window with the customer
- Adjust the expected service time at the stop
- Move the stop to a different tour
- On the tour details page, in the timing column next to each stop
- In the ShipmentsRouter, where stops with unreasonable timings are highlighted as conflicts
- In tour-list views, aggregated as "Tour Timing Guide Warnings"
- The booked window comes from the customer.
- The TimingGuide window is the outer boundary of when the stop may be served without breaking the tour.
- It is not a prediction and not a plan of actual arrival or departure, only the limits of what is feasible.
