PR-3601 · Live
Route Builder
When the Dispatcher sits down for the next planning cycle, the route book is already waiting in a workspace. Every recurring Route is on its own row with the prior stop order, a proposed better order, the drive-time change, and a side-by-side map. The Dispatcher works the rows, locks the stops their technicians have asked to keep, and approves the cycle. On approval, the new plan is written back to the scheduling system on a set window, by default Saturday night, so nothing has to be re-keyed by hand.
The promise
The Dispatcher's planning day no longer runs on a spreadsheet. The route book is already worked out on screen, with the drive-time change named for each Route, ready to review and lock in on the schedule. The hours that used to go to exporting Routes, re-sequencing stops by hand, and re-keying everything back in come back as a plan the Dispatcher checks and approves.
How it works
The path from input to value.
- 01
The route book is pulled in
At the start of each planning cycle, every recurring Route is loaded into one workspace, one Route per row. Each row shows who is running it, what stops it has, and when each stop happens today.
- 02
Each Route is optimized automatically
Every Route gets a better-ordered version worked out for it, shown next to the current one. Each row shows how much drive time and how many miles the new order saves, and a before-and-after map is available for any Route.
- 03
The plan is open for edits
The Dispatcher can adjust any Route before it goes live: dragging stops into a different order, locking stops that should stay put, and re-running the suggestion on just the Routes that were changed. The running totals at the top update as edits are made.
- 04
The approved plan is saved back
Once the plan is approved, the new stop orders, technician assignments, and start times are written back into the company's scheduling system on a set schedule, by default the Saturday night after approval. This happens on its own, with nothing to watch.
- 05
Any Route can be undone
For a set period after approval, any Route can be returned to exactly how it was before the cycle. The earlier version is written back into the scheduling system the same way the new one was.
The day before. The day after.
Same moments. Lived differently.
Coffee, second monitor, the planning spreadsheet kept in a tab. Exports today's schedule out of the system of record one Route at a time.
8:00 AMCoffee, one monitor. The workspace is already showing the proposed cycle, every Route on a row with the drive-time change named.
8:00 AMBefore
Coffee, second monitor, the planning spreadsheet kept in a tab. Exports today's schedule out of the system of record one Route at a time.
After
Coffee, one monitor. The workspace is already showing the proposed cycle, every Route on a row with the drive-time change named.
Re-sequencing stops by hand in the spreadsheet, eyeballing the map in a second tab. The drive-time change is a number calculated on the side.
10:30 AMWorking the rows the suggestion is unsure about, dragging stops where needed, watching the plan-level totals update at the top.
10:30 AMBefore
Re-sequencing stops by hand in the spreadsheet, eyeballing the map in a second tab. The drive-time change is a number calculated on the side.
After
Working the rows the suggestion is unsure about, dragging stops where needed, watching the plan-level totals update at the top.
Two techs have texted asking to keep the same Monday stops they have been working. A note goes on the sticky pad next to the keyboard.
1:00 PMLocks the Monday stops the techs flagged. Re-runs the suggestion on the surrounding subset. Texts the techs back the same hour with the new shape.
1:00 PMBefore
Two techs have texted asking to keep the same Monday stops they have been working. A note goes on the sticky pad next to the keyboard.
After
Locks the Monday stops the techs flagged. Re-runs the suggestion on the surrounding subset. Texts the techs back the same hour with the new shape.
Re-keying the new sequences back into the system of record, one Route at a time, watching for the field that does not save right if you tab through it too fast.
3:00 PMCycle approved. The writes are queued for tonight. Spends the next hour on the schedule-buffer numbers there is finally time to look at.
3:00 PMBefore
Re-keying the new sequences back into the system of record, one Route at a time, watching for the field that does not save right if you tab through it too fast.
After
Cycle approved. The writes are queued for tonight. Spends the next hour on the schedule-buffer numbers there is finally time to look at.
Two techs call the office because their Monday stops moved without warning. The Dispatcher fields the calls.
Next morningNo surprise-move calls. Time in the huddle to coach the team on the same-day reschedule pattern.
Next morningBefore
Two techs call the office because their Monday stops moved without warning. The Dispatcher fields the calls.
After
No surprise-move calls. Time in the huddle to coach the team on the same-day reschedule pattern.
What it doesn’t do
The edges we drew on purpose.
A product that tries to do everything ends up doing nothing well. Here’s what we left out, and why we don’t feel bad about it.
- ×Plans on a cycle, not in real time during the day.
- ×Does not push the new Routes to technician mobile devices.
- ×Does not notify customers when their visit day or window changes.
- ×Does not validate skill matches during optimization; locked stops and tech-Route assignments come in as inputs the optimizer respects.
- ×Does not track GPS or live technician location.
- ×Does not replace the field service management dispatch board.