---
title: "Understanding the TimingGuide"
description: "What the TimingGuide time window means, how Orbit calculates it, and why it is not an ETA or arrival prediction."
url: "https://support.pr-4.orbit.do/en/getting-started/understanding-the-timingguide"
locale: "en"
lastReviewed: "2026-10-09"
---

# Understanding the TimingGuide

What the TimingGuide time window means, how Orbit calculates it, and why it is not an ETA or arrival prediction.

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:

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

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