Практика автоматизации
Как проверить бота для записи: двойная бронь, переносы и напоминания
Клиент выбрал время и получил сообщение, но запись должна ещё появиться в рабочем расписании. До запуска проверьте, что произойдёт при одновременном выборе одного слота, переносе и недоступности календаря.
Опубликовано
Выберите источник рабочего расписания
Определите, где администратор ведёт визиты: в календаре, CRM или системе записи. Бот должен работать с тем же источником либо с согласованным обменом. Отдельный список свободных часов, который никто не обновляет, быстро расходится с реальной занятостью. Проверьте доступный API, правила доступа и возможность читать, создавать, переносить и отменять запись.
Опишите услугу, ресурс и длительность
Свободное время зависит от услуги, сотрудника и ресурса: кабинета, оборудования или другого ограниченного места. Укажите длительность, перерыв между визитами, рабочие часы и минимальное время до записи. Согласуйте, в каком часовом поясе показывать слот. Проверяйте весь интервал услуги, а не только время её начала.
- Учебный пример: услуга длится 60 минут, после неё нужен перерыв 15 минут.
- Визит на 10:00 занимает согласованный ресурс до 11:15.
- Следующий клиент не должен получить пересекающийся интервал.
- Если меняется услуга или сотрудник, доступные варианты рассчитываются заново.
Просмотр свободного времени ещё не создаёт бронь
Например, метод Freebusy в Google Calendar возвращает сведения о занятых интервалах выбранных календарей. Это проверка доступности, а не создание визита. Между показом слота и подтверждением другой клиент или администратор может занять время. Поэтому интеграции нужен отдельный порядок окончательного сохранения и разрешения конфликтов с учётом возможностей вашей системы.
Сценарии приёмки бота для записи
| Ситуация | Ожидаемое поведение | Что смотрит администратор |
|---|---|---|
| Два клиента выбирают один слот | Одна запись; второму предложено другое время | В расписании нет пересечения |
| Кнопку нажали дважды | Одна запись с одним идентификатором | Повторное действие не создаёт дубль |
| Клиент переносит визит | Новая запись подтверждена, старая освобождена по правилам | Нет двух активных визитов вместо одного |
| Календарь не отвечает | Бот не заявляет об успешной записи | Ожидающая операция видна ответственному |
| Визит отменён | Отмена отражена в расписании и заданиях напоминаний | Клиент не получает старое напоминание |
Проверьте одновременную запись двух клиентов
Откройте сценарий с двух тестовых аккаунтов и выберите одинаковые услугу, сотрудника и время. Подтвердите запись почти одновременно. Правильный итог — одна активная бронь и понятное предложение выбрать другое время для второго клиента. Если календарь сам не запрещает пересечения, разработчик должен согласовать механизм контроля; простой повторный просмотр свободных часов не устраняет гонку между запросами.
- Повторите опыт для записи через бота и одновременно через администратора.
- Проверьте расписание, а не только сообщения в чате.
- Успешное подтверждение должно относиться к конкретной сохранённой записи.
Повторное нажатие и потеря ответа
Клиент может нажать кнопку дважды, а система — получить повторное событие. Сохраните идентификатор операции и связь с визитом, чтобы повторное действие возвращало известный результат. Отдельно проверьте случай, когда запись уже создана, но ответ календаря потерялся: перед новым созданием нужно выяснить итог прежней операции. Для пользователя это одна попытка записаться, даже если технических запросов было несколько.
Перенос и отмена должны менять весь сценарий
При переносе сначала проверьте доступность нового интервала и согласуйте безопасный порядок изменения записи. Клиент должен понимать, какое время сейчас действительно подтверждено. Обновите связанные напоминания, сведения администратора и статус визита. При отмене освободите ресурс по правилам услуги и остановите старые задания уведомлений. Если операция завершилась частично, она должна быть видна ответственному для разбирательства.
- Клиент видит актуальные услугу, сотрудника, дату и время.
- Старый слот не остаётся случайно занятым после успешного переноса.
- Два активных визита не появляются вместо одного.
- Сотрудник видит причину и текущий статус изменения.
Проверьте условия отправки напоминаний
Для обычного Telegram-бота пользователь должен сначала начать общение с ботом: документация Telegram указывает, что бот не может сам инициировать разговор с пользователем. Запись через сайт сама по себе не подтверждает возможность отправить напоминание в Telegram. Свяжите визит с нужным чатом по согласованному сценарию и обработайте ошибку доставки. Отправленное сообщение не доказывает, что человек его прочитал.
- Напоминание привязано к текущему визиту и часовому поясу.
- Перед отправкой повторно проверяется актуальный статус записи.
- Перенос и отмена меняют задания уведомлений.
- Недоступный чат или блокировка бота отражаются как ошибка доставки.
Примите работу вместе с администратором
Используйте тестовый календарь и вымышленные контакты. Пройдите обычную запись, конфликт слотов, повторное подтверждение, перенос, отмену и временную ошибку. Для каждого опыта сохраните исходное состояние, действие, сообщение клиента и итог в расписании. Критерий готовности — совпадение подтверждённого визита с рабочей записью и понятный способ исправить исключение, а не только удобные кнопки.
Как связать проверку с задачей бизнеса
До пилота зафиксируйте, сколько обращений требует ручного уточнения и сколько времени администратор тратит на одну запись. После запуска сравнивайте те же показатели, отдельно учитывая исправленные ошибки и обращения к сотруднику. Это предложенная схема измерения; она не является обещанием сокращения затрат. В опубликованном кейсе CRUX можно посмотреть сценарий ИИ-записи для ногтевой студии, а применимость к вашему расписанию нужно проверить отдельно.
Источники
Назначение Freebusy и правила начала общения обычного Telegram-бота проверены по официальной документации Google и Telegram 13 октября 2026 года. Контроль конфликтов, переносов, повторов и приёмка — рекомендации CRUX; реализация зависит от системы записи и её API.