← Все статьи

Telegram-бот для записи и повторных продаж: как связать его с CRM

Начните с одного законченного процесса: клиент выбирает время, система закрепляет запись, менеджер видит её в CRM, а изменения возвращаются в Telegram. Подтверждение, напоминания и повторное предложение должны опираться на актуальное состояние записи.

Карточки диалога рядом с одним закреплённым зелёным резервом, связанным с журналом клиента; обратная стрелка возвращается к разговору

Бот предложил свободное время и написал «Вы записаны». Менеджер открыл CRM, а записи там нет — или на тот же час уже записан другой клиент. Удобный диалог заканчивается ручной перепиской, потому что подтверждение в чате не связано с фактической бронью.

Чтобы Telegram-бот для записи клиентов помогал бизнесу, нужно соединить разговор, расписание и работу сотрудника. Разберём условную студию индивидуальных занятий: один преподаватель принимает одного клиента за раз, занятие длится час, предоплаты в первой версии нет. Это правила примера, по которым можно составить требования к своей интеграции, а не готовые возможности любой CRM.

Проведите клиента от обращения до подтверждённой записи

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

  1. Клиент открывает бота, выбирает занятие и видит время в указанном часовом поясе.
  2. Сервер получает актуальную доступность из системы, которая управляет расписанием.
  3. Клиент подтверждает выбор; система повторно проверяет время и сохраняет одну запись.
  4. Запись связывается с карточкой клиента в CRM. Сотрудник получает её номер, услугу, время и статус.
  5. Бот сообщает подтверждённые детали; последующие переносы и отмены обновляют тот же процесс.

Если CRM ещё не получила данные, различайте состояния «время закреплено, передача в CRM ожидается» и «запрос получен, время не подтверждено». Во втором случае бот должен сказать, что требуется проверка, и дать путь к сотруднику. Сообщение «Вы записаны» допустимо только после подтверждения системы расписания.

Выберите, где хранится актуальное свободное время

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

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

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

Свяжите данные и подтверждения между системами

Для одной записи нужны постоянный номер брони, связь с клиентом CRM, Telegram-пользователь и чат, услуга, ресурс, начало и окончание, статус и версия изменения. Разделяйте клиентскую карточку и конкретную запись: один человек может приходить много раз. Имя пользователя Telegram может меняться и не подходит как единственный ключ; совпадение имени или введённого телефона само по себе не подтверждает доступ к чужой истории.

Доступ к CRM и ключ бота остаются на сервере, а клиент видит только собственные записи. Входящие уведомления проверяются; Bot API поддерживает секрет для проверки webhook. Если добавлено мини-приложение, его исходные данные нужно проверять на сервере, а не доверять переданному из интерфейса номеру клиента.

Не создавайте вторую запись при повторном действии

Клиент может дважды нажать кнопку, а интеграция — повторно получить уведомление. Telegram описывает update_id для распознавания повторов и повторяет неуспешные webhook-запросы. Помимо проверки такого повтора, серверу нужен постоянный идентификатор операции записи: два разных нажатия тоже могут относиться к одному намерению клиента.

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

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

Верните изменения менеджера в Telegram

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

Поздний старый ответ не должен отменить более новое решение сотрудника. Сравнивайте версии и правила перехода статусов. Например, Microsoft Dataverse описывает проверку версии при обновлении записи; механизм своей CRM нужно проверить отдельно. Такая проверка помогает избежать перезаписи, но сама по себе не защищает расписание от двойной брони.

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

Управляйте переносами, напоминаниями и повторным контактом

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

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

Обычный бот не может первым начать личный разговор: пользователь должен сам обратиться к нему. Для мини-приложений Telegram предусмотрел отдельный запрос разрешения на сообщения через requestWriteAccess. Техническая возможность написать не заменяет согласованную цель контакта; остановку сообщений и блокировку бота нужно учитывать в процессе.

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

BotMarketing.pro — пример продукта, который объединяет Telegram-бота, мини-приложение, простую CRM и программы лояльности. Для связи с уже используемой CRM и её расписанием всё равно нужно оценить конкретные операции обмена, статусы и исключения.

Согласуйте первую версию и критерии приёмки

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

Что передать для оценки записи и интеграции
ОбластьЧто согласоватьПроверяемый результат
Услуга и расписаниеРесурс, длительность, часовой пояс, перерывыПредлагается время по действующим правилам доступности
Возможности CRMЧтение, запись, изменения, права и ограничения APIПоддержанные операции отделены от ручного подтверждения
Связь клиентаКарточка CRM, Telegram-идентификаторы, проверка доступаКлиент видит свои записи без доступа к чужой истории
Повторы и конфликтыИдентификатор операции, пересечение времени, сверка после сбояПовтор не создаёт лишнюю бронь, занятый ресурс не подтверждается дважды
Изменение записиПеренос, отмена, версии статусов, задержка обратного обменаИзменение сотрудника возвращается в бот и меняет напоминания
СообщенияВремя, назначение, разрешения, отказ и недоступный чатОтправка соответствует актуальной записи и предпочтениям клиента
Работа сотрудникаОтветственный, очередь ошибок, ручная сверкаНеопределённая операция обнаруживается и доводится до решения
ЭксплуатацияДоступы, журнал, поддержка, резервное копирование и восстановлениеНазначен владелец процесса и проверен способ восстановления

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

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

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

Практический порядок решения

  1. Выберите одну услугу, ресурс и основной источник доступности.
  2. Свяжите идентификаторы операции, записи, клиента и Telegram.
  3. Проверьте повторы, пересечения времени и обратный обмен статусами.
  4. Согласуйте напоминания, отказ, ответственность за сбои и приёмку до расширения.

Источники и методология

Для проверки фактов и технических деталей использованы следующие материалы:

Свяжите запись в Telegram с работой команды

Разберём один клиентский сценарий, возможности вашей CRM и состав первой версии с проверяемыми правилами подтверждения.

Оценить сценарий записи и интеграцию