На главную

DF-АВТ-006 · Автоматизация процессов

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

Редакция Deskforge · 30 октября 2026 · 4 мин чтения
Бот для записи клиентов: единое расписание без дублей
Из статьи вы узнаете
  • какие данные подготовить до разработки бота
  • как провести клиента от выбора услуги до подтверждения
  • как защитить расписание от двойной записи
  • какими сценариями проверить готового бота

Клиент вечером спрашивает, какие окна остались на завтра. Администратор отвечает утром, но выбранное время уже занято. Бот сокращает такую переписку, однако нескольких кнопок с часами для этого недостаточно.

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

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

Что подготовить до разработки бота?

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

Затем выберите единственный источник расписания — CRM, специализированную систему или собственную базу. Бот не должен хранить независимую копию свободных окон. Иначе администратор закроет время в основной системе, а клиент по-прежнему увидит его в чате.

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

Что учесть при работе с персональными данными?

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

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

Статья 22 закона № 152-ФЗ устанавливает общее правило об уведомлении Роскомнадзора и перечисляет исключения. Их применимость зависит от конкретной обработки. Перед запуском также сверяют трансграничную передачу по действующей редакции статьи 12, если хотя бы один участник маршрута находится за пределами России.

Как провести клиента от выбора до подтверждения?

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

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

Telegram Bot API поддерживает встроенные и обычные клавиатуры. В личном чате обычная клавиатура может запросить контакт пользователя. Обновления получают через webhook либо методом getUpdates; одновременно эти способы не используются.

В MAX сообщения, кнопки, диплинки и события через webhook также доступны через официальный API. Long Polling документация относит к разработке и тестированию. Создать бота может организация, ИП или самозанятый — резидент РФ с верифицированным профилем; пользователи получают доступ после успешной модерации.

Как защитить расписание от двойной записи?

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

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

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

Перенос нельзя собирать из двух несвязанных действий.

Если обе брони находятся в одной системе, смену слота проводят одной транзакцией: новый слот закрепляется и старый освобождается вместе, а при ошибке не применяется ни одно изменение.

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

Какими сценариями проверить готового бота?

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

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

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

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

Источники

Назад

Deskforge на связи

Где нас найти

Нажмите на карточку или наведите камеру на QR-код.