Выбор времени без двойной записи: календарь как транзакция

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

Автоматизация расписания состоит из чтения доступности, краткого удержания или повторной проверки и подтверждённой записи. Чат лишь ведёт диалог; источником истины остаётся календарная система. Практический вопрос: какие проверки должны пройти между показом вариантов и словами «вы записаны»?

Определите единицу бронирования

Слот — это не только начало. У него есть длительность, ресурс, специалист, место, подготовка и буфер. Две услуги в одно время могут использовать разные кабинеты или один общий аппарат. Эти ограничения должны вычисляться календарём или сервисом бронирования, а не текстовой моделью.

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

Если длительность зависит от параметров запроса, сначала соберите их. Нельзя предлагать короткое окно для работы, которая занимает дольше.

Читайте доступность непосредственно перед выбором

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

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

После выбора перечитайте слот либо используйте предусмотренный механизм удержания. Возможность удержания зависит от внешней системы; если её нет, честно предупреждайте, что время подтвердится при записи.

Записывайте идемпотентно

Запрос на создание получает ключ, связанный с подтверждённым черновиком. Повтор из-за сетевой ошибки возвращает ту же запись или обнаруживает её, а не занимает соседнее окно. Ответ транспорта сам по себе не доказывает успех: выполните чтение по идентификатору и сравните время, ресурс и контакт.

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

Отмена и перенос — отдельные операции с собственными правами. Создание новой встречи до подтверждённой отмены старой может оставить две записи, поэтому порядок задаётся явно.

Моделируемый сценарий

Родитель пишет в репетиторский центр: «Нужна консультация по математике после школы, лучше во вторник». Система уточняет часовой пояс, возрастную группу и формат. Календарь возвращает несколько окон подходящих преподавателей. Пользователь выбирает вечернее.

Перед записью помощник показывает резюме: предмет, формат, дата, локальное время, длительность и контакт. Пока пользователь подтверждает, выбранный слот занимает другой человек. Повторная проверка получает конфликт. Вместо сообщения «готово» система предлагает два свежих окна.

После нового выбора создаётся запись с ключом черновика. Контрольное чтение подтверждает идентификатор и параметры. Только теперь отправляется финальное сообщение. Ссылка на подключение берётся из созданной встречи, если внешний сервис её предоставил.

Разберите границы и исключения

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

Не обещайте напоминание, если согласие и канал уведомления не настроены. Не меняйте часовой пояс по геолокации без подтверждения. При запросе «как обычно» покажите прошлое предпочтение как вариант, а не как действующий приказ.

Сотруднику нужна очередь конфликтов и неподтверждённых запросов. Черновики не должны блокировать ресурс бессрочно; срок удержания, если оно есть, задаёт календарный контракт.

Чек-лист запуска

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

Оценивайте двойные брони, ложные подтверждения, конфликты, правильность часового пояса и долю ручных исправлений. Скорость выбора не важна, если календарь расходится с сообщением.

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

Конкуренция как штатный случай

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

Пользователю полезно видеть точную дату, время, зону и исполнителя перед подтверждением. Относительное «завтра в три» преобразуйте только после уточнения местной зоны. Буфер между встречами, рабочие часы и длительность услуги считаются правилами доступности, а не подсказками, которые можно отбросить при конфликте. Если календарь отвечает медленно, не показывайте старый список как свежий.

Моделируемый сценарий: два собеседника выбирают одно окно. Первый подтверждает его раньше, и календарь возвращает успех с идентификатором записи. Попытка второго получает конфликт. Агент не повторяет создание вслепую, а запрашивает обновлённые варианты и объясняет, что выбранное время уже недоступно. Он не раскрывает, кто его занял. Если ответ на создание потерялся из-за таймаута, сначала выполняется чтение по идемпотентному ключу, а не новая запись.

Приёмка включает переход календаря на летнее время, отменённую встречу, смену длительности, параллельные подтверждения и недоступность провайдера. Отдельно проверьте письмо или уведомление: оно отправляется после подтверждённой записи и содержит тот же идентификатор, а не служит единственным доказательством успеха.

После записи проверьте весь жизненный цикл: пользователь получает подтверждение, календарь содержит ту же зону и длительность, а отмена освобождает ресурс. Изменение встречи выполняется как отдельная подтверждённая операция, не как создание второй. Если уведомление не доставлено, сама запись всё равно остаётся фактом календаря; интерфейс показывает эти статусы раздельно и предлагает безопасный способ получить детали.

Назначьте владельца календарной интеграции и способ сверки спорной записи. Он должен уметь найти событие по устойчивому идентификатору, отличить отказ создания от ошибки уведомления и объяснить пользователю фактическое состояние. При изменении правил рабочего времени повторите тест конкуренции: прежний успешный пример не доказывает корректность новой конфигурации. В отчёте храните входные зоны и длительности, но не личные детали участников.