DeveloctopusКомпании часто заказывают сайт у одного подрядчика, бота у другого, а потом обнаруживают, что заявки живут в трёх местах и никто не знает, откуда пришёл клиент. Разработка сайта и бота как единой системы решает эту проблему на уровне архитектуры. Разберём, как устроен общий backend, как убирать дубли, сохранять источник обращения и когда подключать второй мессенджер.
Что ломается, когда сайт и бот живут отдельно
Типичная картина: форма на сайте отправляет письмо на общую почту, бот пересылает заявки в отдельный чат, а менеджер вручную переносит всё в CRM. На первый взгляд работает, но на деле возникают проблемы:
- Дубли. Клиент оставил заявку на сайте, не дождался звонка и написал в бота. В CRM — два лида, им звонят два разных менеджера.
- Потерянный источник. Человек пришёл из рекламы на сайт, нажал «Написать в Telegram», и информация о кампании пропала. Маркетолог видит, что бот приводит клиентов, но не знает, какая реклама на самом деле сработала.
- Разные форматы. С сайта приходит одна структура полей, из бота — другая, и сравнивать их неудобно.
- Пробелы в истории. Менеджер не видит, что клиент уже писал неделю назад и о чём.
Все эти проблемы решаются, если сайт и бот передают данные в одно место по одним правилам.
Архитектура: один backend для всех каналов
В основе системы — общий сервер с базой данных. Сайт и бот становятся лишь каналами, через которые заявки попадают внутрь. Мы обычно строим такую систему из нескольких частей:
- API приёма заявок. Форма на сайте отправляет данные на сервер, а не на почту.
- Обработчик бота. Telegram присылает события на вебхук того же сервера, бот проводит диалог и создаёт заявку через тот же внутренний метод, что и сайт.
- Единая база. Клиенты, заявки, источники и история обращений — в одних таблицах, с полем «канал».
- Модуль уведомлений. Один и тот же формат карточки для менеджеров, независимо от того, откуда пришла заявка.
- Синхронизация с CRM. Одна точка интеграции вместо отдельных у сайта и бота.
Такая схема удобна и для развития: новый канал — ещё один мессенджер, квиз на сайте, виджет на маркетплейсе — подключается как ещё один вход, а не как отдельная система со своими правилами.
Единая база заявок и дедупликация
Чтобы один человек не превращался в несколько клиентов, у системы должны быть правила склейки. Опознавать клиента можно по разным признакам:
- Телефон — самый надёжный ключ, если приводить его к единому формату: без пробелов, скобок и с одинаковым кодом страны.
- Идентификатор пользователя Telegram — постоянный, не меняется при смене имени или номера.
- Email — дополнительный признак, если его спрашивают на сайте.
Дальше важно решить, что делать при совпадении. Если клиент оставил вторую заявку через час — скорее всего, это та же потребность, и новую стоит прикрепить к открытой, уведомив ответственного менеджера. Если через полгода — вероятно, новый запрос, и нужна новая сделка, но с историей прошлых обращений.
Когда клиент сначала пишет в бота, а потом заполняет форму на сайте, связать их помогает телефон: бот запрашивает его кнопкой «Поделиться номером», и в базе у клиента появляются сразу два канала связи.
Автоматическую склейку стоит делать осторожно. Один номер может принадлежать офису или семье, и тогда разные люди окажутся в одной карточке. Надёжнее помечать подозрительные совпадения как «возможный дубль» и оставлять финальное решение менеджеру: это занимает секунды, но избавляет от путаницы в истории клиента.
Откуда пришёл клиент: UTM и источники
На сайте источник определить просто: рекламные метки в адресе страницы сохраняются при первом визите. Сложнее, когда посетитель переходит с сайта в бота: метки в Telegram сами не передаются.
Решение — передавать их через параметр запуска бота. Сайт сохраняет метки на сервере и получает для них короткий идентификатор, а кнопка «Написать в Telegram» ведёт по ссылке с этим идентификатором. Когда человек запускает бота, тот получает параметр, находит сохранённые метки и записывает их в заявку. В итоге в CRM видно не просто «Telegram», а конкретную кампанию и объявление.
Для прямых переходов в бота — из рекламы, с QR-кода, из канала — делают отдельные ссылки с собственным параметром. Тогда отчёт по источникам охватывает все входы одинаково. Подробнее о том, как бот собирает заявку и квалифицирует клиента, — в статье «Бот для заявок в Telegram».
Уведомления и передача в CRM
Когда все заявки проходят через один сервер, уведомления становятся единообразными. Менеджер получает в рабочем чате карточку: канал, источник, имя, суть запроса, пометка, если клиент уже обращался раньше. Кнопка «Взять в работу» фиксирует ответственного.
Параллельно заявка уходит в CRM — с полями источника и ссылкой на историю обращений. Если интеграция двусторонняя, изменение статуса сделки возвращается в систему, и бот может сообщить клиенту, что его заказ передан в работу или готов. Как устроена связь с amoCRM и Битрикс24, описано в материале об интеграции сайта и бота с CRM.
Важная деталь — надёжность. Если CRM временно недоступна, заявка не должна потеряться: сервер сохраняет её в своей базе и повторяет отправку позже. Менеджер при этом получает уведомление в чат без задержки.
Когда добавлять MAX
Если заметная часть вашей аудитории пользуется мессенджером MAX, имеет смысл добавить бота и там. У MAX есть платформа для ботов и мини-приложений с HTTP API: бот авторизуется токеном и получает события через вебхук или long polling. Детали — ограничения, требования к оформлению, порядок публикации — уточняются по документации платформы.
В архитектуре с общим backend подключение MAX выглядит как ещё один канал. Сценарии и правила обработки заявок переиспользуются, меняется только слой, который общается с API мессенджера. Заявки из MAX попадают в ту же базу, проходят ту же дедупликацию и уходят в ту же CRM.
Сигналы, что пора добавить MAX: клиенты спрашивают о нём сами, ваша аудитория — та, которая активно им пользуется, или вам важно не зависеть от одного мессенджера. Как перенести логику существующего бота, рассказано в статье о работе в двух мессенджерах.
Порядок внедрения
Если всё делать сразу, проект растягивается. Мы обычно внедряем систему поэтапно, чтобы каждый шаг давал результат:
- Общий сервер и база: перевести форму сайта на отправку заявок через API.
- Уведомления в рабочий чат в едином формате.
- Бот, который создаёт заявки через тот же сервер.
- Передача меток с сайта в бота и отдельные ссылки для каждого источника.
- Правила дедупликации и история клиента.
- Интеграция с CRM, затем — двусторонние статусы.
- Подключение MAX или других каналов, если они нужны.
Уже после второго-третьего шага менеджеры работают в одном месте, а после четвёртого маркетолог видит, какие каналы действительно приводят клиентов.
Частые вопросы
Можно ли связать с ботом уже существующий сайт?
Да. Обычно достаточно изменить отправку формы и добавить кнопку перехода в бота с параметром источника. Сам сайт переделывать не нужно.
Что если у нас сайт на конструкторе?
Многие конструкторы умеют отправлять данные формы на внешний адрес. Если такая возможность есть, сайт подключается к общей системе так же, как самописный.
Нужна ли CRM, чтобы это работало?
Нет. Для старта хватает общей базы и уведомлений в рабочий чат. CRM подключают, когда заявок становится много и нужен учёт сделок.
Сколько времени занимает такая связка?
Перевод формы сайта на общий сервер и уведомления в чат — небольшая задача. Бот, передача меток и интеграция с CRM добавляют этапы, поэтому срок считают после брифа, исходя из того, что уже есть у компании.
Где хранятся данные клиентов?
На сервере, который принадлежит компании или арендован на неё. Доступ к базе ограничивают, а согласие на обработку персональных данных собирают и на сайте, и в боте.
Обсудим проект
Нужна похожая разработка?
Расскажите о задаче — уточним детали, предложим формат запуска и подготовим предварительную оценку. Это бесплатно.
Источники
Опубликовано · Обновлено