Custom scheduling and dispatch software
Scheduling software is abundant and cheap. Businesses still end up building their own, and it is almost always because of constraints the generic tools refuse to model.
Short answer
Firms build custom scheduling when off-the-shelf tools cannot express real constraints like certifications, equipment location and site access windows. Let dispatchers override the optimiser, and make the field app work offline. Builds start at $1,900.
On this page
- Why off-the-shelf scheduling keeps failing
- Optimise, but let the human win
- The field app is the hard part
- Write down the constraints before you look at software
- Travel time is not a straight line
- Handle the day falling apart
- What the field app has to survive
- Whose schedule is it
- What it is actually worth
- What it costs
Why off-the-shelf scheduling keeps failing
Generic tools assume interchangeable people and interchangeable jobs. Real field work is full of hard constraints that break that assumption:
- Only two technicians hold the certification this job legally requires
- That equipment is on one truck, and the truck is two hours away
- This customer's site is only accessible before 9am
- These four jobs must happen in sequence, on the same site, in that order
- A crew cannot exceed regulated hours this week
A tool that cannot express those constraints will keep producing schedules a dispatcher has to override, and a schedule that is always overridden is not a schedule. That is the moment custom becomes cheaper than the subscription.
Optimise, but let the human win
Route and sequence optimisation is genuinely valuable — the difference between a naive schedule and a good one is real fuel and real hours. But a dispatcher who cannot override the optimiser will stop using the system, because they know something it does not: which customer is difficult, which tech is having a bad week, which site the plow has not reached.
Build the optimiser as a strong suggestion with a visible reason, and make the override one click. Systems that argue with their operators get abandoned.
The field app is the hard part
Dispatch is a two-sided problem and the office side is the easy one. The field side has to work on an aging phone, in a basement with no signal, wearing gloves, in a hurry. That means large targets, few taps, and honest offline behaviour — queue the update, sync when signal returns, and show clearly whether it has synced.
The worst outcome is an app that silently discards a completed job because it could not reach the server. Technicians stop trusting it immediately and permanently, and they go back to paper.
Write down the constraints before you look at software
Most failed scheduling projects fail at the same point: nobody wrote down the rules before choosing a tool. The rules are usually known but unspoken, held by whoever currently does the dispatching, and they are the entire reason off-the-shelf products do not fit.
They look like this. This certification is required for that work. This piece of equipment is on a truck and cannot be in two places. This site only permits access between certain hours. This customer will not accept a particular technician. Two people are required for this task. Write them down in plain language first. That list determines whether you need custom software at all, and if you do, it is most of the specification.
Travel time is not a straight line
Scheduling tools that estimate travel by distance produce schedules that collapse by mid-morning. Real travel time depends on traffic, on the season, on ferries and bridges, and in much of Canada on weather that makes a forty-minute drive into ninety.
The practical answer is not a perfect model. It is buffer, plus an honest treatment of uncertainty: schedule fewer jobs than the theoretical maximum, keep slack in the afternoon for the one that runs long, and show dispatchers when a day has no room left. A schedule that is achievable at eighty percent utilisation beats one that is optimal on paper and wrong by ten in the morning.
Handle the day falling apart
Every dispatch system is judged on the bad day, not the normal one. Someone calls in sick, a job overruns by three hours, an emergency arrives at two o'clock. If the system's only answer is to re-optimise everything, the dispatcher will go back to the whiteboard and never return.
What they need is smaller and more specific: see what is affected, move one job without disturbing the rest, find who is genuinely free and qualified right now, and notify the customers whose windows just changed. That last part is most of the perceived value of dispatch software, because the customer who gets a text saying the technician is running late rarely becomes a complaint.
What the field app has to survive
The field half of the system is used standing up, in bad light, in gloves, on a phone with a cracked screen and no signal. It is a genuinely harder design problem than the office half, and it is usually given less attention.
Offline is the requirement that dictates everything else. The app must hold the day's work locally, accept notes, photographs and signatures without a connection, and sync when signal returns — without losing anything and without creating duplicates when two changes meet. Beyond that, keep it to the few things a technician does repeatedly: see the job, start it, add what happened, attach photographs, capture a signature, close it.
Whose schedule is it
There is a political question inside every dispatch project and pretending otherwise is why some of them fail. Introducing scheduling software changes who decides the order of work, and it makes technician performance visible in a way it was not before.
Handled openly, that is fine and often welcome, because it also makes unreasonable workloads visible. Handled by surprise, you get quiet resistance: jobs marked complete in batches at the end of the day, notes left empty, times that do not reflect reality. If the data is being entered by people who did not want the system, the reports built on it are fiction. Bring the dispatcher and a couple of technicians into the design early.
What it is actually worth
The return is usually not the scheduling itself. It is the data that falls out: how long jobs really take versus what you quoted, which techs are consistently over or under, how much of the day is drive time. Most firms have never measured this, and it feeds directly back into estimating.
What it costs
Builds start at $1,900 for platform access, $3,800 to own your modules outright on a perpetual platform licence, and $14,400 for a full custom build with 100% of the IP assigned to you. Hosting from $99/month, optional maintenance from $175/month, changes at $125/hour. Nothing recurring starts until launch.
Scheduling builds tend toward the upper tiers, because constraint logic and an offline-capable field app are both real work. We will tell you honestly if an off-the-shelf tool would serve you, and we have.
Common questions
Do we need GPS tracking?
It is useful for dispatch decisions and corrosive if used as surveillance. Decide the policy before the feature, and tell your crews what it does.
Can it integrate with our accounting?
Yes, and it should. A completed job that does not become an invoice without retyping is where much of the value is.
What if we already pay for a scheduling tool?
Then the question is which specific constraints it cannot express. If the answer is none, keep it. We would rather say that than sell you a build.
Can we not just use a shared calendar?
Up to a point, and plenty of firms should. A calendar stops working when you need to check qualifications, equipment or site access before assigning, or when you need to know what a job actually cost. If you are not hitting those limits, do not build software.
How accurate does the optimisation need to be?
Less accurate than people expect. A schedule that respects the real constraints and leaves slack beats a mathematically optimal one, because the optimal one assumes a day that does not happen. Dispatchers need a good starting point they can adjust, not an answer.
What about GPS tracking of technicians?
Technically straightforward, and the issues are legal and cultural rather than technical. There are employee privacy obligations in Canada around location monitoring, and doing it without a clear stated purpose and a conversation with staff reliably damages trust. Decide whether you need it for dispatch or only want it for oversight.
Talk to us
Tell us what the business does and what it has to accomplish. We will tell you honestly if a cheaper option fits you better.