Бот для записи клиентов: как избежать двойного бронирования

Определите, что именно бронирует клиент

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

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

Выберите единственное рабочее расписание

Если администратор записывает людей в одну программу, а бот — в отдельную таблицу, конфликт рано или поздно придётся разбирать вручную. Лучше определить одну систему, которая решает, свободно ли место. Бот получает из неё доступные варианты и передаёт подтверждение обратно. Если интеграции нет, надо честно выбрать другой процесс: бот принимает пожелание, а администратор подтверждает время.

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

Проверяйте место при подтверждении

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

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

Дайте управлять собственной записью

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

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

Отделите бронь от напоминания

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

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

Подготовьте администратора к исключениям

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

У администратора также должен быть способ найти человека без точного совпадения имени в Telegram. Используйте понятный номер записи и согласованный контакт. Не собирайте дополнительные сведения просто для удобства будущего поиска. Для спорного случая полезна история: кто изменил время, когда это случилось и какой текст отправили. Она помогает восстановить последовательность без догадок.

Проведите репетицию рабочего дня

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

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

Что проверить в своей задаче

1. Названы бронируемые ресурсы и источник расписания.
2. Различаются заявка и подтверждённая запись.
3. Проверен одновременный выбор последнего места.
4. Работают отмена, перенос и старые кнопки.
5. Ошибки напоминаний видны администратору отдельно от брони.