Most shops run mornings off a whiteboard, and the whiteboard works because one person keeps the real system in their head: which tech holds the journeyman license, which one is already committed to Plainview, which job needs a second pair of hands because the condenser is going over a parapet. The board is a display. The dispatcher is the database.
The knowledge that never got written down
When that dispatcher takes a week off, the shop finds out how much of the operation was memory. The fill-in doesn't know that the commercial account on 34th Street only wants the tech who did the original install, or that the panel change-out booked for Thursday can't legally be run by the apprentice, or that one of the senior guys can't do attic work anymore and everyone quietly routes around it. None of that is on the board. It was never anywhere except in one head, and the whole scheduling operation rides on that head showing up.
Constraints become rules
The first real work in building a dispatch system has nothing to do with software: it is writing the constraints down. A panel change-out needs a journeyman or better on site under state licensing rules — that's a hard constraint, and the assignment engine treats it as one, refusing to draft an apprentice onto that ticket no matter how close he is. Refrigerant work needs the tech's EPA 608 card. A condenser going up on a lift, or over a wall, is a two-person job, so the engine won't schedule it against a solo truck. Warranty callbacks route to the tech who did the original work, because he knows what he did and because sending someone else doubles the diagnostic time. Each of these is a sentence in a rules file, checked automatically against every proposed assignment. The rules file is itself the first deliverable, and it has value even on paper: it is the first time the shop's actual operating constraints have existed outside of somebody's memory.
Drive time is a real input out here
A shop based in Lubbock that serves Levelland, Brownfield, Post, and Plainview is routing across thirty to fifty miles of two-lane in every direction. A tech sent to Post for an 8:00 call cannot make a 10:00 in Shallowater, and a day sequenced without geography burns two billable hours in a truck seat. The engine treats drive time between stops as a first-class input: jobs cluster by direction, a Brownfield morning stays a Brownfield morning, and the estimated windows quoted to customers come from the actual sequence rather than from optimism. That is not sophisticated technology. It is arithmetic the dispatcher was doing in their head, done consistently, for every truck, every day.
The proposal, then the gate
Here is the shape of the morning. Overnight, the system drafts the board: every open ticket assigned to a truck that satisfies the rules, sequenced by geography and time windows, with the drive times shown. Nothing has gone to the crews. At 6:45 the dispatcher opens the draft and reviews it the way an editor reads a page — most of it stands, two things move. The system didn't know the customer who called at 9pm furious about yesterday's visit, and it didn't know truck three went into the shop with a bad alternator. The dispatcher drags those two assignments, approves the board, and only then do the day's tickets go out to the techs' phones. The approval gate is not a training-wheels phase to be removed once the system earns trust. It is the design.
Why the gate stays
The system knows exactly what it has been told and nothing else. It cannot read the tone of a callback, weigh the politics of a warranty dispute with a builder, or notice that a good tech is having a bad month and shouldn't draw the worst customer on the list. Those calls belong to a person. What the system changes is the cost of the morning: reviewing a competent draft takes five minutes; building the board from memory took an hour, and it took the right memory. The hour is the win. The judgment was never for sale.
What survives a vacation
Mid-day works the same way at smaller scale — a job runs long or an emergency call lands, the system re-proposes the affected trucks, and the dispatcher approves the change from a phone. But the deeper payoff shows up the week the dispatcher is gone. The fill-in inherits a rules file and a drafted board instead of a blank whiteboard and a decade of unwritten knowledge. Approving a draft is a job a capable office manager can do on day one. Reconstructing the dispatcher's head is not. That is the honest case for encoding the constraints: not replacing the person, but making the operation survivable without them for a week.
When this is the wrong tool
A shop with two or three techs, where the owner dispatches from his cell between his own calls, does not need an assignment engine; a shared calendar and discipline are the honest answer, and anyone selling more is selling. If certifications and skills aren't recorded anywhere, the first weeks are inventory work — pulling license numbers, expiry dates, and who-can-do-what into a list — and that is manual, unglamorous, and unavoidable. Duration estimates start out wrong: the engine's guess at how long a change-out takes comes from your own job history, and until a few months of that history accumulates, the dispatcher will be correcting optimistic sequences. And none of this touches people problems. A tech who pads his windows or a customer who abuses the schedule is a management conversation, not a routing input.
Where to start
Ask whoever runs your board today to write down the ten things they check before assigning any job to any truck. Licenses, crew size, customer preferences, geography, whatever they actually weigh. That one page is the specification for everything above — and it is worth producing even if no software ever gets built, because right now it exists in exactly one place, and that place drives home at five.