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