Безпечне планування виїзного сервісу: доступність, holds і бронювання без конфліктів

Доступність — детермінований розрахунок, а не AI-здогад

Resource представляє техніка або команду. Він має weekly availability, винятки на конкретні дати, skills, service zones і buffers до та після роботи. Послуга додає duration і booking rules, а заявка — вибрану послугу й postcode адреси. Slot search поєднує ці дані в timezone робочого простору й повертає лише інтервали, у які візит справді поміщається.

Календар пояснює відповідність, а не приховує її. Придатні resources мають пріоритет, а оператор бачить, чому інший ресурс не має потрібної навички або зазвичай не працює в цій зоні. Для field service це важливо: виїзд за звичний postcode може вимагати human override, тоді як відсутня професійна компетенція має залишатися жорсткою операційною межею.

Skills, zones, exceptions і buffers визначають валідні слоти

Вибір часу створює тимчасовий hold, а не миттєву зустріч. Hold має expiry і блокує той самий resource interval, поки клієнт або оператор підтверджує. Expiry worker звільняє покинуті holds, а confirm перевіряє hold, поточну request version і найновішу доступність. Прострочений або stale hold не може стати booking лише тому, що користувач залишив старий екран відкритим.

Conflict prevention живе в базі даних. Активні held і confirmed appointments одного ресурсу не можуть перетинатися, тому два запити з різних server processes не займуть той самий час. Idempotency змушує повторні hold або confirm повернути наявний результат, а не дублювати його. Це надійніше, ніж перевірити календар у пам’яті застосунку й сподіватися, що до insert нічого не зміниться.

Тимчасові holds захищають вікно рішення

Confirmation і cancellation — операційні події з durable delivery. Підтверджена зустріч і повідомлення клієнту ставляться в чергу в одній транзакції; outbound worker може повторити доставку після збою, не відкочуючи appointment. Inbox, request panel і calendar читають один committed state. Cancellation звільняє розклад і записує reason, не вдаючи, що повідомлення доставлено до прийняття каналом.

Database conflicts і durable delivery захищають остаточну обіцянку

Native scheduling уже реалізований, але autonomous Book навмисно ще недоступний Ven. Агенту потрібні allowlisted tools для availability search, hold і confirmation та policy checks для кожного виклику. До цього Qualify завершується на Ready for scheduling, а валідний слот обирає оператор. Така межа зберігає чесність продукту: scheduling engine може бути готовим раніше, ніж AI отримає право робити обіцянку.

Перевірте п’ять scheduling failures, яких уникають демо

Створіть два resources із різними skills і zones, додайте availability exception та задайте service duration із buffers. Шукайте той самий тиждень для придатної й непридатної заявки. Валідний список має врахувати timezone, exception, visit length, skill, zone і вільний час навколо візиту.

Відкрийте один слот у двох сесіях і створіть конкурентні holds. Успішним має бути лише один. Дайте hold сплинути й спробуйте confirm, а потім двічі повторіть успішне підтвердження. Expired hold має відмовити, а повторний confirm — повернути той самий appointment.

Наостанок змоделюйте outbound delivery failure після confirmation. Appointment має лишитися committed, customer notice — retryable, а оператор — бачити проблему доставки. Scheduler надійний, коли його найскладніші стани явні, а не лише коли порожній календар приймає перший клік.