Most vendor answers stop at "the AI finds the best plan," which is not an explanation. It is a shrug with a price tag attached. If you suspect the phrase covers a list of if-then rules in a trench coat, that suspicion was earned honestly. The question worth asking — how does AI scheduling work, mechanically — has a real answer, and none of it requires equations.
This article assumes you know what AI scheduling is and want the machinery. Start with the shape of the problem: a set of jobs, a set of technicians, a calendar and a map. Every job needs one technician, at one time, at one address. That sounds like sorting. It is not.
Ten jobs across five technicians is not ten decisions; it is a web of decisions where each changes the cost of the others. Give the 8 a.m. call across town to one tech and you have moved his whole day, which moves the two jobs behind him, which strands an afternoon call with nobody nearby. The pieces do not settle independently. That is what makes a schedule hard in the formal sense, not the tedious one.
This is well-trodden ground in operations research, not a category invented for a funding round. Michael Garey, David Johnson and Ravi Sethi proved in "The Complexity of Flowshop and Jobshop Scheduling" (Mathematics of Operations Research, Vol. 1, No. 2, 1976, pp. 117–129, DOI 10.1287/moor.1.2.117) that these scheduling problems are NP-complete — meaning no known method finds the guaranteed-best answer without, in the worst case, checking an impossible number of arrangements.
So real systems narrow the problem until it is small enough to search honestly. The rest of this article is how that narrowing works, using OnTyme's own scheduler as the worked example.
Everything the software knows about your business arrives as a constraint, and constraints come in two kinds. The difference is the whole design.
Hard constraints eliminate. A slot that breaks one is not a worse slot, it is not a slot, and it is never offered. In OnTyme every one of them is something you configured, not something the vendor decided:
That list is your calendar and your promises, in a form the software will not negotiate away to save nine minutes of driving.
Soft constraints get scored. Here is where most vendor pages go vague, so here is the specific answer for this one: OnTyme's scheduler optimises exactly one number — total travel time. Travel to the job plus travel away from it. That is the entire objective function.
Not workload balance across the crew. Not continuity with a customer's usual technician. Not overtime cost. One number.
Read that as a design choice rather than a gap, because a single legible objective is defensible and a black box that "weighs everything" usually is not. But it does tell you what to check. If balancing hours across your crew matters to you, that is a job for your dispatcher here, not the solver — and it is exactly the kind of question worth putting to every vendor you evaluate.
Given a job location and how long the job takes, the scheduler walks every remaining installer, every day in the range you picked, and every 30-minute mark inside each day. Openings come in four shapes:
Each candidate is checked for fit — does the job plus both legs of travel finish inside the workday — and then scored on travel in plus travel out. The lowest total wins. If nothing fits anywhere in the range, you get told that, rather than being handed a bad slot.
Travel is not estimated from straight-line distance. OnTyme queries Google's Routes API in driving mode with traffic awareness on, so a candidate is judged on the road network as it actually behaves. Every leg starts or ends at your company's depot address unless another job anchors it.
One honest limit: when a single job plus its travel is longer than your whole configured workday, the scheduler stops enforcing the end-of-day boundary rather than reporting no availability. Long jobs will therefore be offered slots that run past closing.
The OnTyme user guide covers configuring the pieces this reads — working hours, vacations, holidays. For where assignment sits relative to routing and workflow automation, see AI scheduling vs. route optimization vs. dispatch automation.
"AI" covers two different technologies, and vendors rarely say which one they are selling. The distinction is worth holding onto, because it changes what you should ask for.
Optimization is the older branch and the one that decides assignments here. The machine examines an enormous number of possible arrangements and returns the best one by a stated measure. It is what runs airline schedules and delivery fleets, it has six decades of research behind it, and it needs no training data — which means it works on your first day with an empty history exactly as well as it will next year. There is no cold start and nothing to teach it.
Machine learning is the newer branch: a model that sharpens with historical data. Its natural jobs in field service sit around a scheduler rather than inside it — learning how long a job type really takes at your shop instead of trusting a typed-in estimate, learning how traffic behaves on your routes at 7:40 a.m., flagging the appointments most likely to slip. Each improves the inputs the optimizer reasons over.
So ask a vendor which one is doing the work. If the pitch leans on learning, ask what it learns, how long before it is useful to you, and how you would know it improved. If the pitch is optimization, ask what it optimizes for and whether it will tell you why it chose what it chose — questions you can check on the first demo rather than in six months.
Building a schedule on a quiet Sunday night is the easy version of this problem. The hard version is a technician calling out at 6:40 a.m. with eight jobs on his board — so be precise about what any tool does at that moment, because this is where the category oversells hardest.
OnTyme places one job at a time. Ask it for a slot and it solves for that job. It does not watch the board and re-solve the day on its own when something breaks. So the sick-tech morning goes: mark the vacation or unavailability, then re-place the displaced jobs through the same tool, one at a time, each one landing in the cheapest opening across everyone still available. Faster than a whiteboard and a phone. Not a button that rebuilds the morning.
The moving parts around it are automatic. Dragging a job to a new time is blocked outright if it would overlap another booking. Technicians get a push notification when they are assigned to a job and when an appointment's time changes, and "Send ETA & Start Navigation" tells the customer the arrival estimate in the same action that opens the tech's navigation. Re-solving a board while leaving eight customers on yesterday's promise is not a fixed morning.
If automatic re-optimization is what you are shopping for, ask for it by name and make the vendor show it: when a technician becomes unavailable mid-day, does the system re-assign the affected jobs by itself, and does it leave unaffected appointments where they are? That second half matters as much as the first. A system that rebuilds the whole day to save four minutes of driving hands you eleven customers who need new arrival windows.
A schedule you cannot interrogate is a schedule you will not trust, and a dispatcher who does not trust the board keeps a parallel one on paper — a worse outcome than no software at all.
So treat explainability as a purchasing requirement, not a nicety, and note that a plain-language sentence beats a confidence score every time. OnTyme puts a Reason line on every recommendation, and it names which of the four openings it found and shows the arithmetic:
"Empty day: Travel from depot takes 21 minutes. New job (30 minutes) starts at 3:47 PM. Travel back to depot takes 23 minutes."
A gap between two jobs reads the same way, naming the site you are coming from and the one you are heading to. Nothing is hidden, and a dispatcher can check it against what they know about that route before pressing Accept & Assign.
Keep pushing on the harder half, with any vendor including this one. Showing why the chosen slot won is easier than showing why the others lost, and no shipping product here shows you the runners-up.
Override matters just as much. Your dispatcher knows things the software structurally cannot: the customer who will only let two specific technicians through the door, the account that goes sideways after 3 p.m., the new hire you want shadowing someone senior this week. None of that is in any database — which is why the search is yours to aim. You choose which installers to consider, the date range, and how long the job should take, and the answer arrives behind a button rather than as a fact.
The design principle underneath: the software proposes, a person approves. The goal was never an unattended board, but a strong first draft in seconds — so your dispatcher's judgment goes into the five decisions that need it instead of the forty-five that do not.
Machinery is only interesting if it moves numbers you already track. Two should move directly, and how much depends entirely on where you started.
Drive time per job — the most directly attributable measure, because travel minimisation is the objective. Also the easiest to verify: pull a month of your own data before and after.
Technician utilization — billable hours as a share of paid hours. Shorter drives convert windshield time into wrench time. A shop with dense routes has less room here than one where crews criss-cross a county.
Two cautions. Results vary by baseline, and any vendor quoting a percentage improvement without asking your current numbers is quoting someone else's shop. And the software inherits your data quality — job durations you enter, addresses, working hours and time off are what it reasons over, so stale records produce a confidently wrong plan. Clean records are the highest-return work before go-live.
How does an AI scheduling algorithm decide assignments?
It eliminates every candidate that breaks a hard rule — on vacation, a holiday, outside working hours, overlapping a booked job — then scores the survivors on a cost and takes the cheapest. In OnTyme that cost is total travel time, and candidates are the 30-minute openings in each installer's real day.
Is AI scheduling machine learning or rules?
Neither, usually — it is optimization: enumerate the feasible options, price each one, take the best. That is a well-established branch of AI, it is considerably more capable than a fixed rules list, and unlike a learned model it works from your first day. Machine learning's natural home in this category is sharpening the inputs, such as duration and travel estimates, rather than making the assignment itself.
What happens when a technician calls in sick?
In OnTyme, you mark them unavailable and re-place their jobs through the recommendation tool, one at a time, into the cheapest openings across everyone still free. There is no automatic board-wide re-solve. Ask any vendor claiming one to demonstrate it on a real board.
Can dispatchers override AI assignments?
Yes, and the design assumes they will. The recommendation appears with an Accept & Assign button, events can be created manually, and appointments can be dragged to a new time — with overlaps blocked. Local knowledge that lives in your team's heads belongs in the final call.
How does the AI estimate job durations?
In OnTyme it does not estimate — you tell it. The scheduling panel takes an estimated completion time in hours and minutes and plans around that figure plus the travel it calculates. Worth knowing, because it makes your own estimates load-bearing. Learning durations from history is where machine learning earns its place in this category; ask any vendor whether theirs are entered, inherited from job type, or learned.
Strip away the vocabulary and the machinery is legible: a problem too large to brute-force, hard rules that eliminate, one cost that decides, a sentence explaining the answer, and a person with final say. A demo then stops being a slideshow and becomes a test.
Bring your worst morning as the test case — the sick tech, the two emergencies, the job nobody has room for — and watch what the board actually does.
%20-%20%EB%B3%B5%EC%82%AC%EB%B3%B8%20(1).png)