FillRoutes
Fill Routes is the FieldRoutes (ServiceTitan) tool that slots unscheduled appointments into existing technician routes, weighing availability, skills, and appointment windows. The optimizer could already produce a route, but dispatchers still had to manually verify it against a cluttered, low-hierarchy interface before publishing. I led the redesign of that review workflow, rebuilding how routes and conflicts were shown so dispatchers could catch problems in minutes instead of second-guessing every route by hand.
Problem to Solve
Fill Routes is a scheduling tool inside FieldRoutes (acquired by ServiceTitan) that pest control companies use to place unscheduled appointments onto existing technician routes. Before a dispatcher sees anything, the optimizer already handles the hard part:
• Technician availability and scheduling windows
• Appointment duration and required skills
• Existing routes and how much room they have left
That part worked well. The problem started right after, when a dispatcher, routing manager, or office manager, depending on how the company was set up, had to review what the optimizer produced before publishing it.
The review screen made that harder than it needed to be. Route cards, map pins, and technician details all competed for attention with almost no hierarchy, so answering a simple question meant hunting across several parts of the screen at once.
This project left the optimization engine alone. It focused entirely on the moment after: could a dispatcher look at a generated route and quickly tell whether it was actually good.
Solution Overview
I didn't think the answer was a better algorithm. Research kept pointing at something else: experienced dispatchers didn't want the software to decide more for them, they wanted enough visibility to decide for themselves, quickly and with confidence.
That reframed the project from routing tool to decision-support tool. Instead of asking how to make routing more automatic, I asked a different question for every decision that followed:
• How does a dispatcher verify this recommendation quickly?
• What does the optimizer not know that a person would catch immediately?
• How do we fix it without losing the flow of the review?
That question shaped everything from how technician colors worked to how manual editing worked.
Research highlights
The filtering is really easy and very helpful. Narrowing down to a specific stop was intuitive. I’d say this is an improvement for sure!
The redesign makes routing more efficient. The overall experience felt effortless.
This makes route planning infinitely faster, and the design feels crisper and cleaner than the current version.
Key design challenges
Results
I left the company shortly after design handoff in February 2026, before implementation finished, so I don't have adoption or efficiency numbers to report. What I can point to is what shipped: release documentation shows that most of the research-driven concepts from this project, including richer route and stop cards, technician and date filtering, route isolation, redesigned map pins, and skills indicators, reached production in the May 2026 release.
- Richer route and stop cards shipped in the May 2026 release
- Technician filtering and date filtering shipped
- Route isolation shipped
- Skills validation warnings shipped
- Redesigned map pins with synchronized map/list highlighting shipped
Reflection
I started this project thinking I was redesigning a routing interface. I finished it having designed a decision-support system, and that distinction changed how I look at enterprise software generally. Expert users weren't asking for less complexity, they were asking for the right complexity, shown at the right moment. Dispatchers were never going to stop reviewing generated routes, and they shouldn't have. They know things about their technicians and customers the optimizer never will. The job of this redesign wasn't to replace that judgment. It was to make it faster to exercise.
View more work ↗