Бот для записи клиента в телеграм я собираю чаще всего для салонов красоты, стоматологий, автосервисов и репетиторов - везде, где администратор тратит половину дня на телефон и ручное ведение журнала записи. Задача обычно звучит просто: клиент открывает бота, выбирает услугу и время, получает подтверждение и напоминание за день до визита. На практике за этой формулировкой скрывается десяток решений про архитектуру, логику слотов и интеграции, от которых зависит, будет бот реально разгружать администратора или превратится в игрушку, которой перестанут пользоваться через неделю.
Зачем бизнесу бот для записи клиентов в Telegram
Из проектов, которые я делал для барбершопов и частных мастеров, вижу одну и ту же картину: до бота 30-40% звонков приходится на «а когда у вас свободно» и «а можно перенести на среду», и это съедает время администратора, который мог бы обзванивать текущую базу или готовить зал. Бот забирает эту рутину полностью: показывает свободные окна, бронирует и присылает напоминание за сутки и за пару часов до визита.
Второй эффект, который клиенты недооценивают на старте, это снижение количества неявок. Простое напоминание в мессенджере с кнопками «приду» и «отменить» сокращает no-show на 15-25% по моим наблюдениям на нескольких проектах в сфере услуг, люди просто забывают о записи, если единственное подтверждение было устным на кассе неделю назад.
Третье это данные. В отличие от бумажного журнала или разрозненных звонков, бот пишет каждую запись в базу, и дальше эту базу можно выгружать в CRM, считать конверсию из первой записи в повторную, смотреть, какие слоты вообще не пользуются спросом.
Из каких этапов состоит разработка телеграм-бота для записи
Разработка бота для записи клиентов в Telegram у меня обычно разбивается на пять этапов, и от того, насколько подробно проработан первый, зависит, сколько раз придется переделывать логику на третьем.
Техническое задание и сценарий диалога
Сначала я рисую сценарий: с какой команды бот стартует, какие услуги предлагает, как выбирается мастер, что происходит при отмене записи клиентом. На этом этапе всплывают вопросы, которые заказчик сам не формулирует заранее, например, может ли клиент записаться на несколько услуг подряд одним визитом, или нужен ли выбор конкретного специалиста, а не просто времени.
Выбор стека и архитектуры
Для ботов такого типа я работаю на Python с библиотекой aiogram, она даёт удобную машину состояний FSM, через которую диалог с клиентом ведётся пошагово: выбор услуги, выбор мастера, выбор даты, выбор времени, подтверждение. Бот работает через вебхук на сервере с HTTPS, а не через постоянный опрос polling, это стабильнее при нагрузке и не теряет обновления при перезапуске.
Разработка логики и клавиатур
Дальше идёт основная разработка: инлайн-клавиатуры для выбора даты и времени, обработка отмен и переносов, хранение записей в базе, обычно PostgreSQL или SQLite для небольших объёмов, уведомления администратору о новой записи в отдельный чат или канал.
Тестирование и деплой
Тестирую сценарий на граничных случаях: что будет, если два клиента одновременно выбрали последний свободный слот, что если клиент отменяет запись за пять минут до визита, что если время указано в выходной день мастера. После этого разворачиваю бота на сервере, настраиваю автозапуск через systemd или Docker, чтобы он не падал при перезагрузке.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Логика бронирования: слоты, календарь и повторные визиты
Здесь скрывается основная сложность, которую заказчики обычно недооценивают, когда просят сделать как в записи к врачу.
Слоты формируются из трёх параметров: рабочих часов мастера, длительности конкретной услуги и буфера между визитами. Стрижка на 40 минут и окрашивание на два часа занимают разное количество слотов в сетке, и если это не заложить в логику, бот будет предлагать время, которое физически пересекается со следующей записью.
Отдельная задача, защита от двойного бронирования. Если два клиента одновременно открывают один и тот же свободный слот, база должна блокировать его на время подтверждения первого из них, иначе администратор через час увидит две записи на одно время у одного мастера. Я закрываю это на уровне транзакции в базе данных: слот резервируется в момент выбора, а не в момент финального подтверждения.
Перенос и отмена записи самим клиентом тоже отдельный кусок логики, а не просто отмени и запишись заново. Хорошая практика, дать клиенту кнопку перенести прямо в напоминании, чтобы он не терял историю записи и не создавал администратору путаницу с двумя карточками одного и того же визита.
Интеграция с оплатой и CRM
Для салонов и студий, где практикуется предоплата или депозит за запись, подключаю приём платежей через T‑Bank, клиент оплачивает прямо в чате, бот получает подтверждение через вебхук и только после этого фиксирует слот как занятый. Это отсекает часть неявок ещё на этапе записи, потому что человек уже вложил деньги.
Для передачи заявок в отдел продаж или менеджеру интеграция обычно идёт в amoCRM или Bitrix24: каждая новая запись создаёт сделку или карточку контакта с историей визитов. Часть таких связок я собираю не кодом бота напрямую, а через n8n, туда удобно вынести логику «новая запись в базе бота, карточка в CRM, напоминание в Google Calendar мастера», и при этом не трогать сам код бота при каждой мелкой правке сценария.
Если помимо самого бота компании нужна полноценная система для отдела продаж с отчётами и правами доступа, а не просто карточки в CRM, я отдельно делаю разработку CRM-панелей и веб-сервисов под задачи бизнеса.
По хранению контактов клиентов есть отдельное требование: телефон, имя и историю записи держу на серверах в России, а не во внешних облачных таблицах, это требование 152-ФЗ по локализации персональных данных, и для бота с реальной клиентской базой закладываю это архитектурно с самого начала, а не по итогу проверки.
Сколько стоит и сколько времени занимает разработка бота для записи
Цена зависит не от отрасли заказчика, а от того, сколько внешних систем бот должен связывать между собой. Простой бот с выбором услуги, времени и напоминаниями, один контур. Бот с оплатой, CRM и синхронизацией календарей мастеров, совсем другой объём тестирования и обработки ошибок.
| Что входит | Срок | Цена |
|---|---|---|
| Запись на услугу, выбор времени, напоминания за сутки и за час | 5-7 дней | от 30 000 ₽ |
| То же плюс приём предоплаты через T‑Bank и передача заявок в amoCRM или Bitrix24 | 2-3 недели | от 60 000 ₽ |
| Бот с AI-консультантом на базе знаний, отвечает на вопросы об услугах и ценах, а затем ведёт к записи | 3-4 недели | от 50 000 ₽ |
Отдельно оплачивается хостинг сервера, на котором бот работает круглосуточно, обычно это 300-600 рублей в месяц за виртуальный сервер начального уровня, я не включаю это в стоимость разработки, потому что заказчик оплачивает такой сервер напрямую хостинг-провайдеру.
Частые ошибки при заказе бота для записи
Из того, что регулярно вижу на доработках чужих ботов:
- Нет буфера между визитами - бот честно показывает слот сразу после окончания предыдущей записи, а мастеру физически нужно убрать рабочее место или отдохнуть 10-15 минут.
- Не учтён часовой пояс сервера - бот развёрнут на сервере с UTC, а напоминания уходят клиентам в московском времени со сдвигом на несколько часов, и люди приходят не туда и не тогда.
- Заявки складываются в Excel-таблицу вручную вместо базы данных - при росте потока это превращается в отдельную работу для администратора, которая должна была исчезнуть вместе с ботом.
- Нет ограничения на количество активных записей у одного клиента - без него часть пользователей записывается про запас на несколько дат сразу и не приходит ни на одну.
Частые вопросы
Сколько времени занимает разработка бота для записи клиентов?
Простой сценарий с выбором услуги и времени я делаю за 5-7 дней. Если добавляется приём оплаты и интеграция с CRM, срок растёт до 2-3 недель из-за тестирования вебхуков и обработки ошибок на стороне платёжной системы.
Можно ли подключить бота к уже существующей CRM?
Да, если у CRM есть открытое API, это касается amoCRM, Bitrix24 и большинства современных систем. Связку обычно собираю либо прямым кодом на стороне бота, либо через n8n, если нужна гибкая логика с несколькими условиями и площадками.
Что будет с записями, если бот упадёт или сервер перезагрузится?
Все записи хранятся в базе данных на сервере, а не в памяти бота, поэтому перезапуск процесса их не затрагивает. Для устойчивости настраиваю автозапуск бота через systemd или Docker, чтобы он поднимался сам после сбоя без ручного вмешательства.
Нужно ли отдельно разрабатывать админ-панель для просмотра записей?
Не обязательно на старте, на первом этапе администратор получает уведомления о новых записях прямо в отдельный чат в Telegram, и этого хватает для небольшого потока. Полноценную веб-панель с фильтрами и статистикой имеет смысл добавлять, когда записей становится больше нескольких десятков в день.