Чат на сайте, в котором отвечает ассистент

Посетитель смотрит страницу с тарифами, открывает чат и пишет: «А если мне нужен счёт на юрлицо, что делать?» Он не хочет заполнять форму, ждать письма и вспоминать завтра, на каком сайте оставил вопрос.

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

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

В чате цена молчания и цена ошибки разные

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

Поэтому в чате ассистент может отвечать сам. Не готовить текст оператору, не ждать подтверждения, а писать клиенту напрямую — если уверен в ответе.

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

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

Хороший чат работает иначе: ассистент берёт только те вопросы, где у него есть опора в базе знаний и достаточно уверенности. Остальное уходит человеку.

Ассистент отвечает не из головы, а по базе знаний

Когда клиент задаёт вопрос, ассистент не должен «знать продукт» как сотрудник после трёх месяцев работы. Он должен найти подходящие материалы в базе знаний и собрать ответ из них.

Это важная разница. Если в базе есть статья «Как получить счёт на юрлицо», ассистент может коротко объяснить клиенту, какие данные нужны и куда их отправить. Если статьи нет, ему не из чего честно собрать ответ.

Поэтому качество автоответа начинается не с модели, а с текстов. Регламент для сотрудников, где написано «передать в бухгалтерию после проверки реквизитов», плохо подходит для клиента. Клиенту нужен ответ: какие реквизиты прислать, когда ждать счёт, что делать, если компания уже есть в личном кабинете.

Мы уже писали, чем кормить ИИ-ассистента, чтобы он отвечал по делу. Для чата это особенно заметно: там нет времени на длинные уточнения и перевод внутреннего языка на человеческий.

У источников есть ещё одна польза. Команда видит, откуда взялся ответ. Если ассистент ответил не так, как хотелось, можно не спорить с «магией ИИ», а открыть конкретную статью и исправить её.

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

Порог уверенности решает, где бот остановится

Самое опасное место в автоответе — середина между «точно знаю» и «примерно понимаю». Человеку в такой ситуации легко написать: «Уточню и вернусь». Бот без ограничений может начать додумывать.

Для этого нужен порог уверенности. Если ассистент проходит его, он отвечает клиенту. Если нет — не пытается выкрутиться, а пишет, что зовёт человека, и передаёт разговор команде.

Снаружи это выглядит спокойно. Клиент не видит технической кухни, не получает странный полуаппаратный ответ и не остаётся в тишине. Он понимает: сейчас подключится оператор.

Внутри у порога есть цена.

Если поставить его слишком высоко, ассистент будет часто молчать. Команда получит меньше автоматизации, а операторы продолжат отвечать на часть простых вопросов вручную.

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

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

Важно не путать остановку с поломкой. Если ассистент передал разговор человеку, это не провал. Это нормальный исход для вопроса, где лучше не рисковать.

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

Другой пример: «Где скачать закрывающие документы?» Если в базе есть точная инструкция, ассистент может ответить сам. Клиент получит путь по шагам и не будет ждать человека ради навигации.

После входа оператора бот не спорит за место у руля

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

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

Представьте переписку:

Клиент: «Мне нужно изменить дату доставки».
Ассистент: «Я позову специалиста».
Оператор: «Здравствуйте, напишите номер заказа».
Ассистент: «Дату доставки можно изменить в личном кабинете».

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

Поэтому после входа оператора ассистент не продолжает подсказывать клиенту. Его работа на этом обращении закончилась.

Команде при этом важно видеть, что уже произошло. Ответ ИИ помечен и в переписке, и в ленте обращений. Это снимает часть путаницы: оператор понимает, какие реплики ушли автоматически, а какие написал человек.

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

Автоответ ломается там, где нет владельца канала

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

Без этого канал быстро стареет.

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

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

Это не делает канал бесполезным. Наоборот, он снимает то, что можно снять без риска, и оставляет людям то, где нужен доступ, ответственность или контекст.

Плохая цель звучит так: «Пусть бот разгрузит поддержку». Слишком расплывчато.

Лучше формулировать уже: «Пусть ассистент сам отвечает на вопросы, где есть точная статья и не нужно проверять данные клиента». Тогда понятно, какие темы готовить, какие диалоги смотреть и где ассистент должен молчать.

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