• State Not Answered
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 6 views
  • Users 0 members are here
Options
Related

Pro tip addition: Route optimization with traffic awareness

Sylvia Chen

Following up on the discussion about route optimization logic — wanted to share something that isn't obvious in the UI.

The route optimizer calculates distance first, then factors in your technicians' Work Hours and Service Area constraints. What it doesn't do by default: live traffic.

But here's the workaround we use at scale (50+ techs, metro area):

  • Set Service Area polygons conservatively — we shrink them by ~15% during rush hours
  • Adjust Work Order Duration estimates upward for cross-town routes (we add 20% buffer)
  • Use Manual Schedule Lock on your first two jobs of day — lets the optimizer sequence the rest around fixed anchors

The 3.2 release added traffic-aware ETA calculations for customer notifications, but the actual sequencing logic still runs on straight-line distance + your configured parameters. Worth knowing the difference.

Related: Route Optimization Not Accounting for Traffic — this was logged as expected behavior, not a bug.

  • 0

    Pro tip: if you're running the same routes daily, build a Template Route with locked stops, then clone it. Saves the optimizer from recalculating stuff that never changes (warehouses, depots, etc).

    Also — morning vs afternoon matters more than distance. We learned that one the hard way when a 12-mile AM route started taking 90 minutes.

  • 0

    Seconding the buffer approach, but I'd push back slightly on shrinking service areas. We tried that and ended up with techs sitting idle at zone edges while calls stacked up just outside.

    What worked better for us: overlapping zones with priority weighting. Techs can flex across boundaries when needed, and the dispatcher has visibility to override.

    Also worth noting — the ETA shown to customers pulls from live traffic, but your internal dispatch view doesn't. Creates confusion if you're not aligned on that.

  • 0 in reply to Gwen Albright

    Fair point on zone edges. We solved that with Secondary Service Areas — techs have a primary zone (tight) and secondary (wider) that only activates when primary coverage is maxed. Takes more upfront config but reduces dispatcher overrides by a lot.

  • 0

    ...so the "optimized" route might send someone straight through a construction zone that started last week because the system doesn't know about it.

    Good to know. I'll keep overriding manually I guess.

  • 0

    Hi Sylvia, thanks for surfacing this — and Josh and Gwen for the additional context!

    You're correct that the routing engine optimizes on distance + your configured constraints, not live traffic data. The ETA calculations for customer notifications do incorporate real-time traffic from our mapping provider, which is why you sometimes see a discrepancy between the sequenced route and the arrival time shown to customers.

    We're actively evaluating deeper traffic integration for the scheduling engine itself. No timeline to share yet, but it's on our radar.

    For now, the manual lock + buffer approach Sylvia described is the recommended pattern. I've added a note to Route Optimization: How It Works to clarify this distinction.

    Ray — if you're seeing specific roads that should be excluded from routing (long-term construction, bridge closures, etc), those can be flagged at the account level. Reach out via support and we can configure avoidance zones.