Когда клиент пишет в чат на сайте, сообщение не отправляется напрямую «в нейросеть». Сначала площадка должна передать его серверу, сервер — понять, к какому диалогу оно относится, затем подключить данные и правила бизнеса, получить ответ и вернуть его в тот же канал. Если нужен менеджер, разговор должен перейти человеку без потери контекста.
Поэтому вопрос как подключить ИИ-бота к сайту и мессенджерам состоит не из одной кнопки. Нужно связать канал, сервер, модель, историю переписки, источники данных и рабочий процесс компании. CRM может быть частью этой схемы, но не является обязательным «мозгом» бота.
Что происходит с сообщением после отправки
Упрощённая цепочка выглядит так:
- клиент пишет на сайте, в мессенджере или другой площадке;
- канал передаёт сообщение и служебные данные серверу бота;
- система находит нужный диалог и восстанавливает контекст;
- подключает знания, каталог и бизнес-правила;
- при необходимости запрашивает внешние данные;
- языковая модель помогает понять запрос и сформулировать ответ;
- система проверяет разрешённое действие;
- ответ возвращается клиенту;
- история, статус и возможная передача менеджеру сохраняются.
Конкретная архитектура может быть другой, но роли остаются. Канал доставляет сообщения. Сервер управляет логикой. Модель работает с текстом. CRM ведёт обращение. Смешивать эти функции опасно: например, считать, что подключение CRM автоматически даёт боту знания о товарах.
API и вебхук простыми словами
API — согласованный способ, по которому программы обмениваются запросами и ответами. Через него бот может получить карточку товара, передать контакт в CRM или отправить сообщение на площадку.
Вебхук — уведомление о событии. Вместо постоянного вопроса «не появилось ли новое сообщение?» площадка сама сообщает серверу: клиент написал, менеджер подключился, статус изменился.
Для подключения важно не название технологии, а наличие официального и разрешённого способа обмена. У разных площадок отличаются доступные события, форматы сообщений, ограничения, тарифы и правила работы. Если канал не предоставляет нужного доступа, одной настройкой модели это не исправить.
Сайт и мессенджер дают разный контекст
На сайте компания лучше контролирует интерфейс. Чат можно связать с текущей страницей, карточкой товара, рекламной кампанией или заполненной формой. Клиент, открывший страницу конкретной модели, может не писать её название: сайт уже передаст идентификатор.
Но у сайта есть свои сложности. Нужно разместить виджет, проверить мобильную версию, обработать закрытие страницы, защититься от спама и решить, как узнавать вернувшегося посетителя. Без авторизации один человек на двух устройствах может выглядеть как два разных клиента.
В мессенджере идентификацию обычно обеспечивает платформа. Человек может вернуться к истории позже, не оставляя страницу открытой. Зато внешний сервис диктует формат кнопок, вложений, шаблонов и передачи оператору.
| Параметр | Сайт | Мессенджер |
|---|---|---|
| Интерфейс | В большей степени контролирует компания | Ограничен возможностями платформы |
| Связь с товаром | Можно передать страницу и ID позиции | Нужны название, ссылка, артикул или уточнение |
| Идентификация | Сессия, cookie, форма или вход | Аккаунт пользователя в канале |
| История | Зависит от реализации сайта | Обычно связана с аккаунтом платформы |
| Правила | Определяются сайтом и подключёнными сервисами | Дополнительно действуют правила площадки |
| Передача менеджеру | Через операторскую, CRM или другой интерфейс | Внутри канала или через связанную систему |
Общие знания и правила бота могут использоваться в обоих местах. Но подключение каждого канала всё равно настраивается и тестируется отдельно.
Один бот в нескольких каналах
Технически одна логика может обслуживать сайт, мессенджер, площадку объявлений и приложение. Это удобно: цены и правила обновляются централизованно. Однако «один бот» не означает одинаковое поведение везде.
В разных каналах приходится отдельно решать:
- длину сообщений;
- приветствие;
- кнопки и вложения;
- передачу контакта;
- связь с товаром;
- идентификацию клиента;
- ограничения площадки;
- работу менеджера;
- ошибки доставки и повторы событий.
На сайте допустим развёрнутый ответ с таблицей, а в мессенджере лучше разбить его на короткие сообщения. В одном канале менеджер подключается прямо к чату, в другом получает задачу на обратный звонок.
Подключать сразу все площадки рискованно. Если логика диалога ещё не проверена, каждая новая интеграция умножает число неизвестных. Практичнее начать с одного канала, где уже есть целевые обращения и понятная работа сотрудников.
Зачем нужна CRM и когда можно обойтись без неё
CRM связывает переписку с процессом продаж. Она может создать обращение, сохранить источник и контакт, назначить ответственного, передать резюме и зафиксировать результат.
При небольшом потоке или тестировании гипотезы CRM не всегда обязательна. Бот способен отвечать на сайте и передавать контакт другим способом. Но по мере роста ручная маршрутизация становится слабым местом: обращения теряются, менеджеры не видят историю, один клиент получает несколько карточек.
В CRM обычно передают только полезные сведения:
- подтверждённый контакт;
- источник и канал;
- интересующий товар или услугу;
- ключевые параметры;
- краткое резюме;
- полный диалог при необходимости;
- причину передачи;
- ожидаемый следующий шаг.
CRM не должна получать всё подряд. Служебный контекст модели, секретные ключи и данные других клиентов к обращению не относятся.
Полный диалог и резюме решают разные задачи
Полная история нужна, чтобы проверить детали и увидеть точные слова клиента. Но менеджеру неудобно читать длинную переписку, особенно если условия несколько раз менялись.
Поэтому разумно хранить и лог, и короткое структурированное резюме. В нём указываются актуальный выбор, подтверждённые параметры, открытый вопрос и причина передачи. Резюме не должно выдавать предположение системы за слова клиента.
Например:
Клиент интересуется услугой A. Регион — город N. Нужен расчёт для нестандартного размера. Бюджет не указан. Контакт подтверждён. Цена не называлась.
Последняя фраза особенно важна, если менеджер должен начать расчёт без риска опереться на выдуманную сумму.
Как сохраняется контекст и не смешиваются клиенты
Каждое сообщение связывают с идентификатором канала, пользователя и диалога. Система хранит историю или её компактное состояние: текущую тему, выбранный товар, параметры, этап и статус передачи.
Если идентификация устроена плохо, возникают опасные ошибки: ответ одного клиента попадает другому, параметры старого разговора используются в новом, менеджер получает неверный контакт.
Один человек может написать через сайт, затем через мессенджер. Автоматически объединять такие обращения без надёжного признака нельзя. Для сопоставления нужен подтверждённый контакт и правила защиты от ложного совпадения.
Хранить бесконечную историю тоже необязательно. Важно сохранить достаточно контекста для задачи, не передавая модели всю CRM и архив прошлых разговоров.
Актуальные цены и наличие подключаются отдельно
Стабильные сведения можно хранить в каталоге бота. Часто меняющиеся значения — цену, остаток, свободное время, статус заказа — безопаснее получать из действующего источника, если он доступен.
Таким источником может быть утверждённая таблица, CRM, складская система, API сайта или внутренний сервис. Подключение требует прав, формата обмена и обработки ошибок.
Если внешний источник не отвечает, бот не должен использовать старое значение как текущее или писать «товар в наличии». Допустимый ответ:
Сейчас не удалось проверить остаток. Могу сохранить запрос и передать его сотруднику.
Та же дисциплина нужна для действий. «Заявка создана» сообщается только после подтверждения CRM. Если операция завершилась ошибкой, клиент получает честное уведомление и другой путь связи.
Повторы, задержки и недоставленные сообщения
Интеграции работают в реальной сети, где события могут приходить повторно или не по порядку. Клиент нажал кнопку дважды, площадка повторила вебхук, сервер ответил с задержкой — и CRM получила три одинаковых лида.
Нужно предусмотреть:
- защиту от дублей;
- безопасный повтор операции;
- очередь при временном сбое;
- отметку доставленного ответа;
- журнал ошибок;
- понятное поведение при тайм-ауте;
- запрет подтверждать невыполненное действие.
Скорость ответа зависит не только от модели. На неё влияют канал, сервер, поиск по данным и внешние системы. Иногда лучше сначала подтвердить приём запроса, а затем вернуть результат проверки. Но такое двухэтапное поведение тоже должно быть предусмотрено, иначе клиент получит два несвязанных сообщения.
Где работает бот и что хранится на сервере
Бот может размещаться на сервере компании, арендованной машине, облачной платформе или инфраструктуре интегратора. Выбор влияет на контроль, стоимость, администрирование и переносимость.
На сервере могут находиться настройки, инструкции, каталог, история, журналы, статусы и ключи доступа к внешним сервисам. Секреты нельзя помещать в публичные файлы или передавать модели без необходимости.
Языковой модели обычно отправляют только рабочий контекст:
- сообщение клиента;
- релевантную часть истории;
- найденные сведения;
- правила текущей задачи;
- параметры, необходимые для ответа.
Передавать всю базу клиентов, внутренний диск и технические ключи не нужно. Чем меньше лишних данных проходит через систему, тем проще контролировать риски.
Доступы и конфиденциальность
До запуска нужно определить, какие данные собираются, где хранятся, кому передаются и кто имеет доступ. Конкретные правовые требования зависят от страны, отрасли и выбранных сервисов, поэтому они проверяются отдельно.
Технические права ограничивают минимумом. Если боту нужно создавать лиды, ему не обязательно давать возможность удалять сделки или читать весь архив CRM. Ключи должны быть отзывными, а доступ — не зависеть от одного уволившегося сотрудника.
Для разработки лучше использовать тестовые аккаунты, каналы и данные. Проверка на рабочей CRM опасна: один неудачный сценарий способен создать сотни дублей или изменить реальные карточки.
Передача менеджеру — часть интеграции
Нужно заранее решить, где сотрудник увидит разговор, как получит уведомление и что произойдёт после подключения. Варианты: операторская в том же канале, задача в CRM, уведомление или обратный звонок.
После перехода к человеку бот не должен продолжать самостоятельную консультацию. Состояния диалога — «бот отвечает», «передача запрошена», «менеджер подключён» — защищают от одновременных реплик.
Вне рабочего времени система может принять обращение, сохранить контекст и сообщить график. Обещать точное время ответа допустимо только по установленному правилу.
Какие расходы появляются при подключении
Сам канал может быть бесплатным, но интеграция всё равно использует инфраструктуру. Возможные статьи расходов:
- сервер и домен;
- использование внешней языковой модели;
- тариф площадки или провайдера;
- CRM;
- разработка и поддержка интеграции;
- мониторинг и резервное хранение;
- адаптация после изменений API;
- работа с безопасностью и доступами.
Набор зависит от проекта. Подключение одного виджета к сайту и обмен с несколькими учётными системами — задачи разного масштаба.
Как выбрать первый канал и провести запуск
Лучший первый канал — не самый модный, а тот, где есть понятный поток обращений, официальный способ подключения и сотрудник, готовый принимать передачи.
Перед запуском ответьте:
- откуда приходят целевые обращения;
- где уже работают менеджеры;
- можно ли подключиться официально;
- как идентифицируется диалог;
- какие данные сохраняются;
- как бот отключается;
- что происходит при сбое;
- кто контролирует первые разговоры.
В тестах нужны первое сообщение, продолжение, несколько быстрых реплик, вложение, событие без текста, повторный вебхук, создание обращения, передача менеджеру и недоступность внешней системы. Сообщения не должны теряться, смешиваться или создавать дубли.
После запуска отслеживают задержки, ошибки доставки, потерянные передачи, сбои CRM, расходы и изменения правил площадки. Интеграция — не разовая проводка, а работающая связь между несколькими независимыми системами.
Как подключение каналов организуется в LEVBOT
LEVBOT предоставляет готовую настроенную сборку персонального бота для конкретного бизнеса. Само подключение сайта, мессенджера, CRM или другой площадки является отдельной технической задачей и зависит от возможностей выбранного канала.
До подключения рабочих каналов поведение бота можно бесплатно проверять и исправлять в тестовых диалогах. За LEVBOT платят только при скачивании завершённой настроенной сборки — 6 000 ₽. Обязательной подписки LEVBOT, внутреннего баланса и оплаты токенов через LEVBOT нет.
Отдельными статьями остаются сервер, домен и использование внешней языковой модели. CRM, провайдеры, каналы и прочие сторонние сервисы также оплачиваются отдельно; автоматического набора интеграций в сборке нет.
Готовая сборка передаётся покупателю. Новая отдельно настроенная сборка является отдельной покупкой. Перед рабочим запуском всё равно требуется отдельно проверить канал, передачу менеджеру, внешние действия и поведение при сбоях.