Как связать ИИ с расписанием и избежать двойной записи

Выберите источник, которому доверяют все каналы

Для владельца процесса главный вопрос — где окончательно меняется занятость. Ручная тетрадь, календарь сотрудника и бот с отдельной таблицей создают несколько конкурирующих версий. Опишите, кто вправе создавать, переносить и отменять визиты и как изменения попадают в общий источник.

Слот — это не только время начала. Важны продолжительность услуги, исполнитель, кабинет или оборудование, перерыв и часовой пояс. Если услугой одновременно пользуются несколько клиентов, задаётся вместимость. Правило «один слот — один человек» подходит не для каждого процесса.

Разберите конфликт по шагам

Таблицу можно прокрутить по горизонтали.

Проверка и фиксация занятости должны быть согласованы на стороне источника записи. Например, в документации PostgreSQL описаны ограничения пересекающихся диапазонов. Это один технический способ для собственной системы, а не утверждение о внутреннем устройстве вашей CRM. При готовом сервисе нужно проверить его фактическое поведение.

Не повторяйте создание вслепую после тайм-аута

Сервис может создать запись, а ответ до агента не дойдёт. Тогда «повторить» не обязательно означает «создать ещё раз». Интеграции нужен способ узнать результат исходной операции: ключ повторной отправки, идентификатор запроса или поиск по надёжному признаку — в пределах возможностей сервиса.

Если результат нельзя однозначно восстановить, агент сообщает, что подтверждение уточняется, и передаёт задачу. Нельзя уверенно заявить ни успех, ни отсутствие записи только по тайм-ауту. Отдельно согласуйте время удержания временной брони, если она есть, и освобождение при незавершении клиентом.

Проверьте пять конфликтных сценариев

1. Два клиента выбирают один ресурс и время почти одновременно.
2. Администратор вручную занимает окно между предложением и подтверждением.
3. Клиент меняет услугу на более длительную перед записью.
4. Создание прошло, но ответ потерян; повтор не создаёт вторую запись.
5. Перенос освобождает старое время только согласно согласованной механике.

Для каждого теста нужны ожидаемый статус клиента и фактическое состояние расписания. Снимок красивого диалога недостаточен. До завершения таких проверок можно использовать сбор пожеланий с ручным подтверждением: это отдельный честный режим, а не автоматическая запись.

Конкурентный тест: ожидаемый результат

Вход: один ресурс и слот 15:00, два независимых ключа. Тест одновременно запускает две попытки записи. При уникальном ограничении одна получает accepted, другая conflict. Повтор успешного ключа возвращает тот же booking ID; число строк остаётся 1.

Учебная SQLite-модель защищает одинаковые слоты. Она не покрывает интервалы 60 и 90 минут, несколько ресурсов, часовые пояса или API внешнего календаря. Для проекта эти проверки добавляются отдельно; ссылка на range types PostgreSQL объясняет возможный механизм пересечений, но не доказывает нашу интеграцию.

Как повторить локальный стенд

Скачайте самодостаточный Python-стенд и выполните python3 service-demos.py. Нужен Python 3, только стандартная библиотека; сеть, CRM, LLM и внешние сообщения не используются. Скрипт проверяет продажи, знания и конкуренцию за слот, выводит JSON с before/after и проверяет результат через assert. Временная база удаляется после запуска.

Ожидается: sales — 2 строки в наивном варианте и 1 после повтора по ключу; support — answer до проверки актуальности и handoff после; booking — два успешных предварительных чтения против одной атомарной записи и конфликта. Эти узкие модели не заменяют испытания реальной системы.