Field Service Routing Software for Multi-Day Repair Jobs

Routing software is built for a world where a job is an appointment: a technician arrives, does the thing, and leaves inside the hour. Heavy equipment repair is not that shape. A boom rebuild runs three days, a hydraulic reseal is six hours of wrench time plus two hours of driving each way, and the machine cannot come to you. Routing that only understands today's stops quietly wrecks the rest of the week.

What routing software assumes about your day

Almost every tool in this category grew up in HVAC, plumbing, and appliance service, and it shows in three assumptions baked into the algorithm:

• One job, one day. The optimizer packs stops into a shift and closes the day. A job that spans three days has no slot to fit into.
• The job is ready when you arrive. The part is on the truck, the customer is home, the bay is free. Nothing about waiting.
• The drive is the only constraint. Distance and time — not "the crane is booked Thursday" or "the seal kit lands Friday afternoon."

None of those assumptions is stupid. They are just wrong for a repair shop.

Multi-day work is the normal case, not the edge case

If half your board is multi-day work, routing has to be built around it rather than bolted on. That means:

• One work order, several scheduled days. Not three records for one rebuild — three days on one record, each with its own start time, duration, and assigned technician.
• Per-day overrides. Tuesday might be a full day with your senior tech; Thursday might be a two-hour finish with whoever is closest. Same job, two very different days.
• A route that respects the commitment. Once a tech is on day two of a rebuild, they are not available for a call across town at 10am. The router has to know that before it offers them.

The failure mode when it doesn't: you schedule a breakdown call onto a technician who is mid-rebuild forty kilometres away, and you find out when both customers call you.

Sequencing beats optimization

Route optimization sells itself as finding the shortest path. For repair work, sequencing matters more than distance — the right order in which things can happen.

A realistic multi-day sequence looks like this:

1. Diagnose on day one, while the machine is still assembled and you can see what failed.
2. Order the parts the same afternoon, once the diagnosis is confirmed rather than guessed.
3. Schedule the repair days around the parts window, not around what looks tidy on a calendar.
4. Leave the reassembly day flexible for the second part that always turns up on day two.

Software that can't hold a "waiting on parts" state with a date attached will show that job as scheduled and nobody will chase the supplier. Two weeks later the customer calls to ask when their machine is coming back, and the answer is a shrug.

The parts window is a routing constraint

This is the part most tools miss entirely. In a repair shop, the single biggest cause of a job slipping is a part that hasn't arrived. So the schedule has to carry the parts state, and the router has to treat an unarrived part the way it treats a closed road.

Practically, that means:

• Approved estimates that were never booked should be impossible to miss — on the board and on the dashboard.
• Jobs parked waiting on parts should carry a supplier, an expected date, and a name against them.
• The morning board should show what's actually movable today, not what was typed in three weeks ago.

Put that next to the calendar and the shop's week fills itself from work that was already sold. For how the assignment side of this works, see technician dispatch software; for the map-and-calendar combination in practice, see scheduling field service technicians with a map.

What to look for in routing software

Forget the demo. Ask these:

• Can one job span several days, each with its own technician and hours? If not, you will maintain duplicate records forever.
• Does the route respect existing commitments? A tech on day two of a rebuild must be invisible to the router for that day.
• Is travel time visible? If drive time is invisible, a three-job day looks fine on paper and runs until seven.
• Can a job sit in a waiting-on-parts state with a date? And does something chase it?
• Does the technician's phone work without signal? Their day, their job, their timer — cached, offline. A route that only loads with bars fails at exactly the remote jobs where routing matters most.

If it fails the first question you'll be re-entering work orders forever. If it fails the last, your technicians will run the day off a screenshot and a text message, and the board will be wrong by ten o'clock.

The honest test

Take your worst week last month — the rebuild that ran long, the part that arrived late, the breakdown call that landed on the busiest day. Ask any routing tool to show you that week: where each tech was, what they were driving between, which job was already committed, and what was waiting on a supplier.

If it can't, you are not looking at a routing tool. You are looking at a map with pins on it.

JSD ServicePro runs the calendar, the map, and the work orders over one record — multi-day jobs with per-day technicians, waiting-on-parts states with dates, and a technician view that works offline on the phone. Beta is open: run a real repair week on it free and see whether the board matches the way your shop actually dispatches.