One Loop a Week: Field Service Dispatch and Command Centers Inside the CRM
A lithium-battery manufacturer with a field-service arm, four active service territories, and inside, outside, and OEM sales teams · Ongoing, part of a five-year engagement
- Salesforce
- Custom
The Challenge
Service was dispatched by hand. A case came in, someone looked at a map, guessed a day, and called a driver. Drivers made solo runs across the same area on different days. When the drive-time estimate was wrong, and it was wrong by a lot, the day fell apart in the field.
Sales had the opposite problem: plenty of data and no single place to read it. The head of sales ran the team from a spreadsheet and a dozen tabs. Month-to-date numbers read near zero on the first of every month, so nobody trusted the dashboard that showed them. OEM partners who had never ordered sat in the same list as the ones who ordered every week.
Our Approach
We audited read-only first: the case object, the appointment and territory objects the field-service suite already provided, the existing reports, and the head of sales' spreadsheet. The rule was to build on the standard field-service objects rather than beside them, so the client's own admins could keep running it.
Every number on every board would carry a "how this is calculated" note. Every automated decision would have a manual-review queue behind it, and the queue would nag until it was empty.
The Solution
A zone-based dispatch engine. Each service area is served on one set day a week, so a driver makes one loop instead of repeated solo runs. When a case becomes a job, the system checks whether the address is in range and offers two dates: the zone day, or an expedite date on a flex day. A driver already working nearby gets the stop; otherwise the day's primary driver takes it. Capacity is checked warehouse to stops to warehouse, at 15 minutes per stop, an 11-hour daily ceiling, and a 50-stop cap, scanning up to 30 days out. Over cap, the job overflows to a teammate with room. If every driver is full, it lands in a manual-review queue.
A customer self-scheduling portal. The customer gets a private, signed link from their case and picks a day. The portal hides days that are already full unless the new stop is a cheap add. Submissions go through a queue so the public user never touches a field-service record directly, and each one writes an audit row and a confirmation with a reschedule link that only offers valid days.
A nightly optimizer. Sunday through Thursday evening, it re-sequences the next day's stops per distribution center on live drive times, rebalances when one driver's day passes six hours while a teammate sits under nine, and posts each driver's route to the team chat in driven order. A driver day view mirrors that post with an open-in-maps link.
A service dashboard for dispatchers and field leads: open cases, dispatched today, backlog, response time, first-time fix, techs on shift, and attention lists for stale cases, routing failures, warranties awaiting review, and jobs stalled in repair, filtered by territory.
Command centers for sales and OEM. The sales home page opens on a command center (KPI strip, my numbers, momentum, dealer health, leaderboard) with six dashboard tabs behind it, including the commissions and territory tabs from the commissions engine and territory engine. The OEM app has its own: partner health, never ordered, who slipped, pipeline, program readiness, and tasks. Both use 90-day windows instead of month-to-date, and every card has a help note explaining the calculation.
Results
- One live check showed the straight-line drive-time estimate at 594 minutes against 374 actual, 59 percent high. Real drive times now decide assignment.
- Raising the service radius from 180 to 200 minutes moved 15 cases out of manual review and flipped 35 more into a routable band.
- Once the OEM health cut matched how partners actually buy, "dormant" went from 88 partners to 12, and the 76 that had never ordered got their own board.
- The new-dealers-with-no-first-order report went from 64 rows to 15 after tightening the window, and three people now get it every Monday morning.
- One honest miss: the service dashboard's five-minute auto-refresh was popular enough that open tabs saturated the org's concurrent request limit. We removed polling the same day and left the manual refresh. The mechanisms behind it cover what we'd do differently.
No AI in this build. Here's why that was right: a stop either fits a driver's day or it doesn't, and a dashboard number is either calculated the same way every time or it isn't. Every decision here has a right answer.
Zone resolution, capacity math, overflow, the nightly re-sequence, the self-scheduling portal's slot filter, every command-center calculation, and the failure alerts. If the drive-time service goes down, one consolidated alert posts and unrouted stops re-post every morning until a person clears them.
The mechanisms behind it
Facing a similar challenge?
Let's talk about what's going on with your systems. 30 minutes. No pitch deck. We'll tell you if AI is the wrong tool.
We'll respond within 24 hours.