Enterprise Scheduling Tool

The original brief could easily have become a calendar redesign.

But placing work into an empty slot wasn’t the difficult part.

A workable assignment depended on more than capacity — route, priority, service constraints and the shape of the technician’s existing day also mattered.

I worked alongside a subject-matter expert to understand how those factors shaped real scheduling decisions and what the first concept needed to represent.

But expertise by proxy could only take us so far. Once the concept was coherent enough to challenge, I put the working design in front of an experienced Field Manager.

The key user action was scheduling a work order, but the real decision was more complex: Should this technician take this work order at this time?

I worked the concept through four rounds of hand sketches before committing to higher fidelity. Each round resolved a different layer of the problem — first which layers the map should carry and let you toggle, then a second view and capacity, then the core interactions, and finally the structure that shipped.

Field Managers weren't choosing from a handful of jobs. In a market like Las Vegas, the unscheduled queue could contain more than a thousand work orders.

I designed the workflow so they could first narrow that queue using operational criteria such as priority, work type, status and duration, then assess the remaining work against the technician's existing workload and route.

The aim was to move from “What work is waiting?” to “What work realistically fits this technician's day?”

My early concepts showed every technician's route simultaneously.

Conceptually, that made sense: if route visibility was important, showing all routes appeared to provide the most information.

Engineering exposed the cost of that assumption.

Every rendered route required a routing-API request, recalculated as schedules changed. Repeating that across multiple technicians and markets would compound into meaningful operating cost.

Instead of asking “How can we preserve every route?”, I went back to the decision itself.

Field Managers needed to compare the positions of many technicians, but they only needed detailed route information for the technician they were seriously considering.

The model therefore became:

Location pins for everyone; calculated route for the selected technician.

We gave up simultaneous route comparison, reduced unnecessary API usage and also reduced map clutter.

Later evaluation supported the simplification: once a technician was selected, the participant wanted the remaining technicians removed from view altogether.

The work shifted the product from a calendar-first scheduler into a route-aware dispatch workspace.

Assignment decisions became clearer because dispatchers could see capacity, location, route impact, priority, and service constraints before work was committed.