Why did the AI book a job we couldn't actually cover?
Almost always because it read availability instead of capacity. An open slot on the calendar is not the same as the ability to serve that job: it may need a skill nobody available has, a part nobody has on the truck, or a drive across the service area that breaks the rest of the day. And if the agent does not lock the slot while the call is still happening, two callers can take the same one.
Availability is not capacity
Most scheduling APIs will happily tell you a time slot is open. Whether you can serve it depends on constraints that live outside that answer: technician skill and certification, truck stock, geographic clustering, job duration for that job type, and whatever the dispatcher knows about how the day is really going.
Human CSRs handle this by knowing the business, or by checking with dispatch. An agent that only reads the calendar has none of that context, so it books legally open slots that are operationally impossible.
Four constraints worth encoding
- Skill match. Job type maps to required capability. Do not offer a slot to a caller whose work nobody on that shift can do.
- Duration by job type. A diagnostic and a full replacement are not the same block of time, and defaulting to one length wrecks the day.
- Geography. Slot offers should respect zones or existing route clusters, otherwise you sell windows that only work if a truck teleports.
- Buffer. Leave deliberate slack for emergency work, especially in peak season. An agent that fills every slot removes your ability to respond.
The double-booking mechanism
Even with constraints right, a race condition remains. The agent reads availability, spends two minutes confirming details with the caller, then writes — and in that window another call, an online booking or a dispatcher took the slot.
The fix is a soft hold: reserve the slot the moment you offer it, with a short expiry, and release it if the call ends without a booking. This is standard practice in any reservation system and it is routinely skipped in voice deployments because the happy path looks fine in testing. Building it correctly is integration work against your scheduling system, not conversation design.
Give dispatch a veto
Even a well-constrained agent should not be the last word during peak load. A practical pattern is to let the agent book freely inside a defined envelope — standard job types, standard windows, normal capacity — and to require dispatcher confirmation outside it, with the caller told a confirmation is coming rather than given a firm window.
That preserves speed for the routine majority while keeping a human in the loop where the schedule is fragile. It is the same envelope logic we use across home services automation.
Topics: scheduling · capacity · dispatch · double booking
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.