# Route optimization: the runs bolt-on

> A run is a first-class projection over a day's jobs: an ordered list of stops. Building a run and ordering it by hand is base functionality. The optimizer that sequences stops for you is a paid, per-account bolt-on — off by default — and it is the only place an external solver is ever called.

URL: https://biloh.com.au/docs/reference/route-optimization-bolt-on
Category: Reference | Audience: operator | Updated: 2026-07-07

A **run** is a first-class projection over a day's jobs: an ordered list of stops for one crew on one date. Runs let you plan the shape of a day — which sites, in which order — without ever pinning a job to a clock time. Building and hand-ordering a run is base functionality; the automatic optimizer is a paid bolt-on.

## What is a run made of?

A run has a date, an optional crew, and a set of **run stops**. Each stop points at a job and carries a `stop_order` — its position in the sequence — plus an optional lock so a fixed stop stays put. A job appears in at most one active run per day. Runs are deletable without touching the schedule: they are a view over jobs, not a rewrite of them. Stops with no location are listed separately and never silently dropped.

## What's free and what's the bolt-on?

Creating a run and **ordering it by hand** — drag a stop up or down, lock the one that has to be first — is available on every plan. The **optimizer** that sequences stops for you is a separate, per-account **paid bolt-on**, off by default. It is enabled per tenant by configuration alone, and it is the *only* place an external routing solver is ever invoked. Until it is enabled, the run sheet is fully usable with manual ordering; there is no optimize button.

## How does navigation hand off to maps?

Once a run is ordered, each stop can hand its destination to a maps app for turn-by-turn driving. Whole-run export respects a hard external limit: a consumer maps directions URL accepts at most **nine waypoints** in the app (three in a mobile browser), so a long run is split into labelled segments rather than emitting a link that would silently truncate stops. Per-stop navigation is the primary path; whole-run export is the convenience.

## Tunables

The bolt-on's behaviour is configured through platform settings (editable in the app and by an AI assistant at the same depth): which solver adapter backs the tenant, whether to balance a fleet by time or by stop count, whether to favour clean geographic clusters, a daily optimization cap as a cost guard, and a default per-stop service duration. These are inert until the bolt-on is switched on.

## Related

- [Dispatching and triaging jobs](/docs/how-to/dispatching-and-triage)
- [Scheduling jobs by the day, not the minute](/docs/concepts/scheduling-jobs-by-the-day)