Job scheduling and routing for field teams

What does job scheduling and routing cover?

It is the difference between a list of addresses and a plan for the day. The office needs to allocate work fairly and without clashes; the engineer needs a sensible order to drive in; and both need the plan to stay accurate when things change, which on a live field operation is constantly.

• Territory rules. Each engineer or franchisee sees the jobs that belong to their patch, scoped by the same ownership model that powers the Franchising module. A franchisee never sees another franchisee’s work, and head office sees the whole network.
• Drive-time day plans. The plan orders jobs by travel time rather than as a flat queue, with fixed appointment windows treated as anchors the route works around. The aim is fewer wasted miles and a realistic day, not a theoretical one.
• Capacity and duration per job. Every job carries its own expected duration and any skill or kit requirements, so the day plan reflects how long work actually takes rather than assuming every visit is the same length.
• Live reassignment. When priorities change, the office moves a job between engineers and both day plans update. Because the plan syncs rather than being relayed by phone, nobody drives to a job that has already been reassigned.
• Allocation that cannot double-book. Claiming or accepting a job runs under a per-job lock, the same serialised capacity check proven in the Booking Engine’s checkout reservations, so two engineers cannot both end up owning the same visit.

How it behaves at the edges

Scheduling looks simple until two things happen at once, which on a field operation they always do. These are the cases that separate a real dispatch design from a demo.

• Two engineers accept the same job. The first accept to commit wins; the second receives an explicit already-taken outcome rather than a silent duplicate. This is the proven per-record concurrency pattern, not a hopeful timestamp comparison.
• A job is accepted offline, then reassigned at head office. Both actions are reconciled on reconnect against a clear precedence rule, so the job resolves to a single owner and the other party’s plan corrects itself. The offline sync page sets out exactly how conflicting actions are resolved.
• A job overruns. When a visit runs long, the remaining plan reflows and the office sees the knock-on effect on later appointments, so a customer who will now be visited late can be warned rather than left waiting.
• A no-access visit. An engineer who cannot get in records the attempt against the job, and the app routes them on rather than stranding the visit in an ambiguous state. The abandoned visit stays visible to the office with its reason.

Integration points

Job scheduling does not sit on its own. It draws on the modules the rest of the platform already runs.

• Booking and capacity come from the Booking Engine, including the serialised capacity checks and facilitator-style assignment that field allocation reuses.
• Notifications use backend-triggered push with deep links, so a reassignment opens straight onto the new job rather than a home screen.
• The franchise layer scopes territory visibility and per-territory reporting through the Franchising module.

Why it matters

A day plan that is wrong by mid-morning is worse than no plan, because people stop trusting it and revert to phoning the office. Getting scheduling right means the plan stays true as the day changes: allocation that cannot clash, an order that respects the roads, and reassignments that reach the engineer without a phone call. The companion guide below sets out the wider requirements to put to any field app vendor, including yours.