Field Sales

A live ETA chip is the small card on a sales rep's dashboard that shows "arriving at 2:47pm" and updates in real time as traffic changes. When gridlock hits an unexpected freeway closure, the chip recalculates to "now arriving 3:15pm" and your system can notify the customer proactively — "Hey, we're running 28 minutes late but you'll see us before 3:30pm." No surprise no-shows. No wasted waiting time on either side. This piece explains how the tech works, why field-sales teams actually need it, and how Velocity X handles the hard problem of keeping those times accurate without hammering your API bill.

Why Live ETAs Matter More Than You'd Think

Field sales reps live on the road. A customer books a 2pm appointment and expects the rep between 1:50-2:10pm. If traffic is unexpected — a crash, roadworks, a school pickup zone clogging at 2:15pm — the rep is now late and the customer is checking their watch. No notification, no expectation reset, and suddenly it's a trust issue.

The lived version: a rep has 12 stops across a territory. Six of them have hard appointment windows. Live ETAs mean every customer gets a realistic arrival time and updates only when traffic actually changes. No phantom late notifications (boy who cried wolf). No "expected 2:15, actually 2:37, actually 2:29" jitter. Velocity X solves this by polling Google's real-time traffic layer every 60 seconds and re-calculating only when the delta exceeds a configurable threshold — default 8 minutes — so small slowdowns don't ping the customer every 90 seconds.

How Live ETA Chips Work Under the Hood

The flow is straightforward in principle, complex in execution. Rep's dashboard has a planned route for today: Stop A (1:15pm), Stop B (2:00pm), Stop C (3:10pm). As the rep drives, the system runs three jobs in parallel:

1. Traffic polling every 60 seconds. The backend calls Google Maps Routes API with the rep's current GPS position and the remaining stops. It pulls live traffic conditions for each segment and updates the expected arrival time at each stop.

2. Threshold checking. If a stop's ETA shifts by more than 8 minutes (configurable per team), the system flags it as "route change detected" and surfaces a prompt: "Traffic on Route 78 — you'll now arrive Stop B at 2:28 instead of 2:00. Accept re-route?" The re-route option re-solves the remaining stops using OR-Tools to see if a different order saves time.

3. Customer notification. If the rep accepts a re-route or if an ETA shifts materially, your CRM triggers an automated outbound SMS or in-app message: "We're on the way — now arriving at 2:28pm." Tone matters here. Velocity X templates this as opt-in per customer (don't spam) and batches notifications so a 5-minute shift doesn't trigger one but a 20-minute shift does.

The hard part is latency. A re-solve request hits Google's Routes API (get new distance matrix), then OR-Tools (solve the TSP), then returns the new order to the rep's phone. Velocity X targets sub-3-second round trips. This is why caching matters: the distance matrix is cached for 2 minutes (traffic doesn't change that fast in most urban areas) and re-used across multiple re-route checks. Actual solve time on OR-Tools for 8 remaining stops is under 400ms, so the latency budget is mostly network.

Integration with Calendar + Customer Notifications

The ETA chip lives on the rep's dashboard but its real value is in the handshake with the customer's calendar and your CRM. When a rep's ETA shifts beyond threshold, Velocity X can:

Auto-push a notification to the customer via SMS or your app's in-app notification. "We're 20 minutes late due to traffic — arriving 3:15pm" removes the anxiety of being stood up.

Block the rep's calendar for the new arrival window so they don't accidentally get double-booked by the back-office. If a 2pm was pushed to 2:45pm, the calendar extends the blocked window to 3:15pm (buffer for the visit itself).

Flag the next stop if a re-route pushes it past the appointment window. Some Velocity X customers have 30-minute service level agreements — if the re-route puts you at 2:50 for a 2:30 appointment, the system can auto-offer the customer a quick reschedule or notify the rep that this stop is at-risk.

None of this is fire-and-forget. It's observable: the rep sees the customer notification go out, can override it if needed, and can manually push a different ETA if they know something the algorithm doesn't (e.g., "actually I'm going to stop for fuel, add 15 minutes").

Velocity X vs Competitors — The ETA Difference

Most field-sales SaaS tools (Badger Mapping, Optiway, Mapview.ai) include "live ETAs" but implement it as: show Google Maps ETA. That works for a single trip but breaks down on multi-stop routes because Google's ETA doesn't account for stop duration, appointment windows, or team-wide traffic context. Velocity X layers in three things competitors don't:

Constraint-aware re-solves. When traffic hits, Velocity X doesn't just re-order by fastest-first. It re-solves the constrained problem: which order minimizes total drive time while respecting appointment windows, territory rules, and priority pins? Google Maps doesn't do that.

Batched customer notifications. Per-seat SaaS tools notify the customer every time the ETA changes. Velocity X batches: unless the shift exceeds 8 minutes (tunable), the customer doesn't get pinged. Reduces notification fatigue by 70-80% in typical urban routing.

Sub-3-second re-solves. Badger and Optiway can take 8-15 seconds to re-route because they're cloud functions spun up on demand. Velocity X's backend runs persistent polling so the solve is already warm. This matters for real-time UX on the rep's phone.

Frequently Asked Questions

How often does the ETA update?

The backend polls Google Maps every 60 seconds. Customer notifications only go out if the ETA shift exceeds 8 minutes (configurable). So the ETA chip updates frequently but the customer only gets notified for material changes. This keeps the signal-to-noise ratio high.

What if the rep is offline?

Routes are cached on the rep's device, including the planned ETAs from when the day was created. If the phone loses signal, the rep can still navigate the cached sequence. ETAs won't update until the signal returns, but that's acceptable — most field reps in Australia are urban or suburban and rarely go more than 20 minutes without bars. Velocity X queues any stop check-ins or notes locally and syncs when signal returns.

How accurate are the ETAs?

Google Maps' ETA is accurate within ±5 minutes in urban areas (based on their own public accuracy tests). Velocity X adds rep-specific calibration: if your reps historically take 8 minutes to complete a stop but Google estimates 0 minutes at that location, Velocity X learns this and adjusts future ETAs. Over time, the system gets tighter.

Does it notify customers automatically?

Yes, but it's opt-in per team or per customer. You control the trigger threshold (8 minutes by default), the message template, and the channel (SMS, in-app, email). You can also turn it off for specific appointment types — e.g., don't notify for administrative check-ins, only for customer-facing visits.

Can multiple reps affect each other's ETAs?

No. Each rep's route is solved independently. However, Velocity X can flag territory conflicts at planning time — if two reps are assigned to overlapping postcode blocks, the system highlights it before the day starts. Once routes are live, they operate in isolation.

What if my area has no Google Maps data?

Google Maps covers Australia comprehensively but some rural areas have sparse data. Velocity X falls back to straight-line distance + a configurable speed factor (65km/h for rural roads). The ETA will be less accurate but won't break. For teams in remote territories, disabling live re-routes and using static ETAs is sensible.

The Bottom Line

Live ETA chips are the difference between "your rep is late" (customer's perspective) and "traffic hit us, you're now arriving 2:28" (rep's perspective). When the system notifies the customer proactively and recalculates the remaining route in real time, trust holds and no-shows drop. Velocity X handles the hard part — sub-3-second re-solves, constraint-aware re-routing, batched notifications — so your team doesn't have to choose between responsive reps and frustrated customers.

Want to see how live ETAs work in your own territory? Check the pricing tiers or read our post on multi-stop route optimisation to understand the full routing stack.