Safe field-service scheduling: availability, holds, and conflict-free booking

Availability is a deterministic calculation, not an AI guess

A Resource represents a technician or team. It carries weekly availability, date-specific exceptions, skills, service zones, and buffers before and after work. The service contributes its duration and booking rules, while the request contributes the selected service and property postcode. Slot search combines those inputs in the workspace timezone and returns only intervals that can actually contain the visit.

The calendar explains fit instead of hiding it. Eligible resources are prioritized, while an operator can see why another resource lacks the required skill or normally works outside the service zone. This distinction matters for field service: a postcode outside the usual area may require a human override, while a missing electrical qualification should remain a hard operational boundary.

Skills, zones, exceptions, and buffers decide which slots are valid

Choosing a time creates a temporary hold rather than an immediate appointment. The hold has an expiry and blocks the same resource interval while the customer or operator confirms. An expiry worker releases abandoned holds, and confirmation rechecks the hold, the current request version, and the latest availability. An expired or stale hold cannot be converted into a booking simply because the user still has an old screen open.

Conflict prevention lives in the database. Active held and confirmed appointments for one resource cannot overlap, so two requests racing through separate server processes cannot both win the same time. Idempotency makes repeated hold or confirm calls return the existing result instead of duplicating it. This is stronger than checking a calendar in application memory and hoping nothing changes before the insert completes.

Temporary holds protect the decision window

Confirmation and cancellation are operational events with durable delivery. A confirmed appointment and its customer notice are queued in the same transaction; the outbound worker can retry a temporary channel failure without undoing the appointment. The inbox, request panel, and calendar read the same committed state. Cancelling releases the schedule and records the reason without pretending a message was delivered before the channel accepts it.

Database conflicts and durable delivery protect the final promise

Native scheduling is implemented, but autonomous Book mode remains intentionally unavailable to Ven today. The agent still needs allowlisted tools for availability search, hold, and confirmation, plus policy checks for each call. Until that layer is connected, Qualify ends at Ready for scheduling and a teammate chooses the valid slot. The boundary keeps the product honest: the scheduling engine can be complete before the AI is authorized to make the promise.

Try the five scheduling failures a demo usually avoids

Create two resources with different skills and zones, add one availability exception, and give the service a duration plus buffers. Search the same week from an eligible and an ineligible request. The valid list should respect the timezone, exception, visit length, skill, zone, and the time that must remain clear around the visit.

Open the same slot from two sessions and place competing holds. Only one should succeed. Let a hold expire and try to confirm it, then repeat a successful confirmation twice. The expired hold must fail, while repeated confirmation must return the same appointment rather than consuming another interval.

Finally simulate an outbound delivery failure after confirmation. The appointment should remain committed, its customer notice should remain retryable, and the operator should be able to see the delivery problem. A scheduler is reliable when its hardest states are explicit, not merely when an empty calendar accepts the first click.