Understanding the TimingGuide

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 two time windows

1. Booked time window

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.

2. TimingGuide time window

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.

Important: the TimingGuide is NOT an arrival or departure prediction

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.

Why Orbit calculates a second window

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.

Example

A tour has two stops:

To arrive at B by 16:00, the driver must leave A by 14:30. With 30 minutes of service time, arrival at A must happen by 14:00. But the customer at A only books until 12:00, so the latest possible departure from A is set by that booking.

Orbit surfaces this as: TimingGuide window at A = 09:00–12:00, tightened on the back end by the downstream route.

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."

Time Window Conflicts

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

Where you see the TimingGuide

• 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"

In short

• 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.