Как добавить ИИ-чат-бота на сайт: сценарий, база ответов и проверка заявок

Начните с маршрута клиента, а не с выбора модели

Откройте 30–50 последних обращений с сайта и разложите их на группы: вопрос о товаре или услуге, просьба рассчитать стоимость, статус заказа, жалоба, нестандартный запрос. Для каждой группы запишите ожидаемый результат. У вопроса «есть ли доставка завтра?» результатом может быть ответ с актуальным условием. У просьбы «посчитайте проект под наши процессы» результат иной: бот собирает исходные данные и передаёт запрос специалисту.

Так вы получите границы бота. Если у компании нет единого правила расчёта цены, нельзя просить модель «примерно сориентировать». Она может создать у покупателя ложное ожидание. Пока правило не утверждено, безопасный ответ — попросить параметры расчёта и предложить связь с менеджером.

Соберите источники ответов

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

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

Опишите сценарий разговора на одной странице

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

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

Подключите виджет и проверьте путь заявки

Технически цепочка выглядит так: сообщение в виджете → обработчик → поиск по разрешённым источникам → ответ или передача → запись в CRM. До публикации проверьте, кому принадлежат ключи доступа, где хранятся переписки, какие события попадают в аналитику и что произойдёт при недоступности модели. Сообщение «сервис временно недоступен» с рабочим контактом лучше бесконечного индикатора ожидания.

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

Десять вопросов для закрытого теста

• Прямой вопрос, ответ на который есть на сайте.
• Та же мысль с опечаткой и разговорной формулировкой.
• Два вопроса в одном сообщении.
• Вопрос о старой цене, которая сохранилась в архиве.
• Запрос без достаточных данных для расчёта.
• Просьба позвать человека сразу.
• Жалоба с эмоциональной формулировкой.
• Запрос по товару, которого нет в наличии.
• Повторный вопрос после уточнения.
• Сообщение после разрыва связи и возвращения в чат.

На каждом случае отметьте, был ли ответ верным, нашёлся ли источник, не сделал ли бот неподтверждённого обещания и дошёл ли разговор до нужного сотрудника. Показатель «бот ответил» ничего не говорит о качестве: неверный ответ тоже считается ответом.

Что измерять после запуска

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

Сравнивать результаты стоит с похожими обращениями до запуска. Если бот разгрузил оператора на простых вопросах, но ухудшил путь к покупке, проект требует переделки. Для технического проектирования полезно руководство OpenAI по агентам: оно разбирает инструменты, ограничения и передачу управления. На практике бизнесу нужен собственный список реальных вопросов и критерий, по которому человек примет результат.

Когда виджет пока не нужен

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

Как выбрать место для виджета

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

Самый важный тест интерфейса — отправить заявку с обычного телефона и затем открыть её у менеджера. Красивая анимация чата не компенсирует потерянный контакт.

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