Field Sales

A rep's route is planned tight: 12 stops, 8 hours, margins thin. Then at 1:47pm a freeway closure upstream of Stop 5 adds 18 minutes of gridlock to the planned segment. The rep's now running late, Stop 5's appointment window is at risk, and Stop 6 might slip past close-of-business. Instead of gutting through a broken plan, Velocity X re-solves the remaining five stops in 1.8 seconds, presents the new order as "accept or reject", and the rep makes the call with full context. This piece explains how live traffic re-routing works, why the architecture matters, and how constraints stay locked while the order flexes.

The Cost of Stale Routes When Traffic Hits

Most routing systems solve once at 8am and call it a day. Traffic is baked into the arrival estimates, but traffic isn't static. A 15-minute segment at 1pm becomes 40 minutes at 2:15pm. A rep following a stale route is now chasing a plan that no longer exists. Customers get no-shows or short-notice "running late" calls. Reps spend mental energy on re-sequencing instead of selling. Deals slip because appointment windows close.

Real data: a 10-person team with stale routes loses roughly 8–12 appointments per month to traffic-driven lateness. Each appointment is a deal window closed. Live re-routing that adapts in real time cuts those losses by 60-70%. The rep sees the problem within 90 seconds, makes a conscious accept-or-reject call, and moves on with a fresh plan that fits the new reality.

How Live Traffic Re-Routing Works

The system runs three parallel operations on every rep's active route:

1. Traffic polling every 60 seconds. The backend polls Google Maps Routes API with the rep's current GPS position and all remaining stops on the route. It pulls live traffic conditions for each segment and compares planned drive time against expected arrival time given current conditions. Think of it as a heartbeat: every minute, the system asks "is the plan still valid?"

2. Threshold detection. If any remaining segment's expected drive time exceeds the planned time by more than 8 minutes (configurable per team), the system flags a "route change detected" event. This isn't spam — a 2-minute slowdown doesn't trigger anything. But a 15-minute anomaly gets immediate attention: the rep sees a card in their dashboard saying "Traffic on Route 78 detected — Stop 5 now at 2:18 instead of 2:00. Remaining route will be re-solved if you accept."

3. OR-Tools re-solve. When the rep taps "accept", Velocity X calls Google Routes API once more to get the current distance matrix for the rep's position and all remaining stops. This matrix feeds OR-Tools, which solves the constrained Travelling Salesman Problem in under 400ms. The result is a new visit order that minimizes total drive time while respecting locked constraints — appointment windows, lunch break, territory boundaries, any stops the rep has pinned. The new order surfaces as a prompt: "New route: Stop 5 → Stop 7 → Stop 6 → Stop 9. Accept or dismiss?"

Round-trip latency from threshold detection to re-solve result: under 3 seconds in most cases, sub-2-second is common. This speed matters. A rep won't trust a system that thinks for 20 seconds; they'll just manually reorder. Sub-2-second feels instant and builds confidence in the re-route suggestion.

Constraint Handling — What Stays Locked

A naive re-solve would shove all remaining stops into a new order without mercy. Reality is messier. Velocity X respects a set of hard constraints that don't flex even when traffic hits:

Appointment windows. A 2:30pm appointment slot can't be moved to 4:15pm just because traffic is bad. The solver treats this as a hard constraint: the stop must be visited within the window or flagged as at-risk and surfaced to the rep for decision. If the re-solve can't fit it, Velocity X tells the rep "Stop 5 no longer fits its window — reschedule or accept late arrival?"

Lunch break. Most teams have a 30-60 minute lunch block pinned to 12:00-1:30pm. This doesn't move. The solver optimizes stops before and after the break independently, then concatenates them.

Territory boundaries. Some reps operate in a postcode block or geographic zone. Velocity X locks this in — the re-solve won't suggest a stop outside the territory even if it's faster, keeping rep territories clean.

Rep-pinned priority stops. A rep can pin "do Stop A first no matter what" or "do Stop B last". These are explicit overrides and survive re-solves. Useful for VIP customers or stops with hard dependencies.

What flexes: the order of unpinned stops. That's where the 8-minute traffic anomaly creates value. Instead of a re-solve that ignores appointments and breaks territory rules, Velocity X re-solves within the constraints. The rep gets a plan that works in the new reality and respects what matters.

Architecture: API Polling + Persistent Solve Engine

The performance win comes from not spinning up a new solver on every re-route request. Instead, Velocity X runs a persistent backend process that owns each active rep's route:

Polling service. For each active rep (someone currently on a route, not just planned), the backend spawns a lightweight polling loop. Every 60 seconds it hits Google Routes API with the rep's latest GPS and the remaining stops. Cost: ~$0.02 per poll. Total cost for a team of 10 reps running 8 hours a day is roughly $2-3 per month.

Threshold detection in-process. No additional latency. The polling service compares the new matrix against the cached plan and decides whether to flag a re-route event. If yes, a re-route card appears on the rep's dashboard immediately.

Warm solver. When the rep taps "accept", the actual OR-Tools invocation happens on a persistent backend service that stays warm across the day. Spin-up time is near-zero. The new matrix feeds straight to OR-Tools, which has 400ms to solve. This is why Velocity X hits sub-2-second round trips while cloud-function-based competitors (Badger Mapping, Optiway) take 8-15 seconds — cold function starts add 6-10 seconds of latency before the solve even begins.

Frequently Asked Questions

What happens if the rep ignores a re-route suggestion?

The suggestion sits on the dashboard as a dismissible card. The rep can ignore it and keep the original plan. Nothing changes. Velocity X doesn't force re-routes — it's a recommendation engine with the authority to suggest but not mandate. If a rep knows something the algorithm doesn't (e.g., "I'm going to grab fuel at 2:15, ignore that timing anomaly"), they can dismiss and carry on.

How much does live polling cost?

Google Routes API costs $0.02 per request. A team of 10 reps polling every 60 seconds for 8 hours a day is 10 reps × 8 hours × 60 = 4,800 requests. At $0.02 each, that's $96 per month. Scale to 50 reps and you're at ~$480/month. Compare that to Badger Mapping at $58/user/month for 50 users = $2,900/month. Velocity X's operational cost is radically lower because you own the API consumption.

Can a rep manually override the re-route?

Yes, fully. The re-solve is a suggestion. A rep can drag stops to reorder manually, pin a stop to a specific position, or reject the suggestion entirely. Velocity X treats manual overrides as new pinned constraints for the next re-solve.

What if traffic clears suddenly?

The polling detects it. If the planned drive time for Stop 5 drops below the 8-minute-delta threshold, the system considers the anomaly resolved and goes quiet. No "traffic cleared" notification — just resumption of the original plan. The rep keeps moving without distraction.

Does re-routing affect customer notifications?

If a stop's ETA shifts materially due to re-routing, the customer gets a proactive notification (if enabled): "Traffic on our route — we're now arriving at 2:28 instead of 2:00." Velocity X batches notifications so trivial re-solves don't ping customers. Only material changes notify.

What if a rep is offline when traffic hits?

Polling is server-side, so it happens regardless of the rep's connectivity. But the rep won't see the re-route suggestion until signal returns. When they reconnect, Velocity X surfaces the latest traffic state and asks about re-solving the remaining stops. In truly remote territories, this might mean a 20-minute delay. For teams in urban/suburban Australia, this is rarely an issue.

Can I tune the 8-minute threshold?

Yes. Teams can set a per-team threshold, per-customer type, or per-time-of-day threshold. A team that values responsiveness might lower it to 5 minutes. A team that wants fewer notifications might raise it to 15 minutes. Velocity X surfaces this as a configuration setting in the admin panel.

The Bottom Line

Live traffic re-routing is the difference between "following a broken plan" and "responding to the road in real time". When an anomaly is detected, a re-solve happens in under 2 seconds, and a rep can make a conscious accept-or-reject decision within 90 seconds, the whole system feels responsive instead of bureaucratic. Velocity X achieves this by polling traffic constantly, running OR-Tools in a warm persistent process, and respecting the constraints that actually matter — appointment windows, lunch breaks, territory boundaries. The cost is negligible compared to per-seat SaaS pricing, and the operational value is direct: fewer missed appointments, less rep mental load, and fresher plans for fresher road conditions.

Want to understand the full routing stack? Read our post on multi-stop route optimisation or check pricing tiers to see how live re-routing fits your team size.