Telegram-бот для записи клиентов: полный разбор за вечер

Почему запись – идеальная работа для бота

Запись на услугу – самый механический диалог в бизнесе: услуга, время, контакт, оплата. Никакого творчества – и именно поэтому администратор делает эту работу плохо: отвечает через час, забывает перезвонить, путает время, уходит спать. Статистика беспощадна: клиент, которому не ответили за 15–30 минут, уже пишет конкуренту. А пишут люди вечером и в выходные – ровно тогда, когда отвечать некому.

Бот закрывает ровно эту дыру: отвечает за секунду в 2 часа ночи, не забывает, не путает пояса и не просит зарплату. Администратор остаётся для нестандартных ситуаций – их процентов десять.

Скелет: стейт-машина, а не «свободный чат»

Первое инженерное решение противоречит моде: основной сценарий записи – это конечный автомат (FSM, finite state machine) на кнопках, а не свободный диалог с языковой моделью. У каждого клиента в базе хранится его текущее состояние: выбирает услугу → смотрит слоты → вводит имя → бронь → ожидание оплаты → записан. Каждое нажатие кнопки – переход по строго описанному ребру.

• кнопки не дают клиенту «уйти не туда» – конверсия выше, чем в свободном тексте, где половина людей пишет «а сколько стоит?» и теряется;
• состояние переживает рестарт бота: клиент вернулся через сутки – диалог продолжился с того же места, а не с «здравствуйте»;
• каждый переход логируется – потом по логу видно, на каком шаге люди отваливаются.

Языковой модели в этом скелете отведена одна умная роль – о ней ниже, в разделе про ИИ. Спойлер: она разбирает свободные фразы вроде «перенесите меня на четверг», но саму запись всегда ведёт автомат.

Слоты: откуда берутся свободные окна

Источник правды о времени – календарь, который и так ведёт владелец: Google Calendar, Яндекс Календарь или таблица слотов в базе. Бот раз в пару минут синхронизирует занятость и строит сетку доступных окон. Настроек у сетки немного, но каждая критична:

Обязательное правило: у занятости один источник. Если встречу можно создать и руками в календаре, и ботом – busy-маска календаря главнее: слот, перекрытый личной встречей владельца, автоматически исчезает из выдачи бота.

Бронь: гонка за слот и время жизни

Самая красивая задача всей системы. Пятница, 19:00 – популярный слот, и два клиента жмут на него одновременно. Если бот наивно «проверил – свободно – записал», оба получат подтверждение, а владелец – скандал. Это классическая гонка (race condition), и лечится она на уровне базы: бронь – атомарная вставка с уникальным ограничением на слот. Кто успел первым – того и время, второй в ту же секунду получает «увы, только что заняли, вот соседние окна».

Вторая половина механики – время жизни брони (TTL). Слот, забронированный без оплаты, живёт 15–20 минут: счётчик тикает прямо в сообщении. Не оплатил – бронь испаряется, слот возвращается в выдачу сам, без ручной чистки. Без TTL сетку за день забивают «мёртвые души», которые нажали кнопку и ушли думать.

Оплата: предоплата против неявок

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

Технически бот выставляет платёжную ссылку (ЮKassa, Robokassa – любой агрегатор с API): нажал – оплатил – вернулся в чат. Дальше три правила, выстраданные продом:

• вебхуку не верят на слово – уведомление об оплате может прислать кто угодно. Получив вебхук, бот сам запрашивает статус платежа у платёжной системы по API и только после подтверждения двигает запись;
• идемпотентность – вебхуки приходят дублями, иногда по три раза. Обработка ключуется по ID платежа: повторное уведомление – молчаливый no-op, а не вторая запись и не второе письмо;
• чеки по 54-ФЗ – у агрегаторов фискализация встроена, но её надо включить и проверить тестовым платежом до запуска, а не после первого вопроса налоговой.

Напоминания: за сутки, за два часа, к началу

Каждое напоминание срезает долю забывших. Рабочая лесенка: за 24 часа (можно перенести без потерь), за 2 часа (выходите), в момент начала (ссылка на видеовстречу или адрес). Два тонких места, где все спотыкаются:

• окна, а не точки – планировщик проверяет «пора ли» раз в минуту, и напоминание должно сработать в интервале, иначе перезапуск сервиса в 23:59 съест «за сутки» у всех завтрашних клиентов;
• дедупликация – уникальный ключ «запись + тип напоминания» в базе. И отдельный случай: клиент записался за час до встречи – слать ему «за сутки» и «за два часа» разом нельзя, устаревшие ступени пропускаются.

Перенос и отмена: самообслуживание

Треть обращений к администратору – «а можно на другой день?». Бот делает это кнопкой: «Перенести» показывает ту же сетку слотов, старый слот освобождается, новый бронируется той же атомарной механикой, оплата переезжает без возврата и повторного платежа.

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

CRM: воронка, которую бот ведёт сам

Каждая запись – сделка в CRM (у меня это Битрикс24), и по стадиям её двигает бот, а не человек: новая → забронирована → оплачена → встреча состоялась → успех или проигрыш с причиной. Владелец открывает воронку и видит картину дня без единого вопроса администратору: сколько записей, сколько оплат, кто отвалился на оплате, кто перенёсся.

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

А где здесь ИИ

Ровно в одном месте – и очень к месту. Люди не читают кнопки: пишут «болею, давайте на понедельник», «а можно пораньше», «отмените пожалуйста». Без ИИ такие сообщения падают администратору. С ИИ – языковая модель разбирает свободную фразу в структурированное намерение: перенос, отмена, вопрос о цене – и дальше его исполняет всё та же стейт-машина со всеми её проверками. Модель понимает, автомат решает: галлюцинация физически не может записать человека на занятый слот, потому что запись делает не модель.

Что мерить после запуска

• воронка шагов – старт → выбор слота → бронь → оплата. Провал между соседними шагами показывает, что чинить: мало слотов, дорого, неудобно;
• доля неявок – до предоплаты и после: самая наглядная цифра для владельца;
• доля переносов и отмен – растут переносы «за 2 часа» – двигаем стоп-порог;
• время от старта до брони – у здорового сценария это 1–2 минуты; дольше – где-то лишний шаг;
• доля диалогов, ушедших человеку – здоровые 5–10%. Больше – сценарий не покрывает реальные вопросы, меньше при жалобах – бот зажимает эскалацию.

Грабли, на которые уже наступил

Часовые пояса – грабля №1: клиент в одном поясе, бизнес в другом, сервер в третьем. Всё время в базе – в UTC, показывается клиенту в его поясе, и это решение принимается в первый день, а не при первом инциденте. Грабля №2 – кнопка «назад»: клиент ушёл на три шага назад и нажал устаревшую кнопку из старого сообщения; каждая кнопка несёт свой контекст и проверяется на актуальность, иначе бронь встаёт на давно занятый слот. И грабля №3 – «брошенные» состояния: человек застрял на вводе имени и ушёл навсегда; всем состояниям нужен таймаут с мягким пинком «продолжим?», иначе база пухнет от вечных «в процессе».

Вопросы и ответы