Автоматизация
Где ИИ полезен в обработке обращений, а где нужен человек
Какие вопросы можно доверить помощнику, что должен решать человек и как проверять передачу обращения.
Редакция
ИИ в обработке обращений имеет смысл там, где он помогает клиенту быстрее перейти к полезному действию. Не там, где чат просто дольше разговаривает. Я смотрю на задачу после диалога: какие сведения собраны, кто их получил и может ли сотрудник продолжить работу без повторного опроса.
Начинать стоит с ограниченного сценария. Например, объяснить состав услуги, уточнить город и параметры задачи, сохранить подтвержденные факты и предложить передачу человеку. Цена нестандартного проекта, обязательства по договору и окончательное решение о допустимости работ не должны появляться из свободной генерации.
Четыре полезные роли
| Роль ИИ | Что он может подготовить | Где нужна граница |
|---|---|---|
| Навигация | Подходящий раздел или формат обсуждения | Не выдавать неподходящую услугу за решение любой проблемы |
| Уточнение | Недостающие сведения для следующего шага | Не заставлять отвечать заново на уже сообщенное |
| Структурирование | Карточку с фактами и открытыми вопросами | Не превращать предположение в слова клиента |
| Передача | Контекст и предложение действия | Не объявлять встречу или заказ подтвержденными без ответа системы |
Качество нельзя оценивать только по вежливости и длине ответа. В профиле NIST для генеративного ИИ отдельно рассматриваются уверенные ошибочные ответы и контроль взаимодействия человека с системой. Это добровольная рамка управления рисками, не сертификат качества конкретного чата. Для проекта нужен собственный набор проверок.
Условный диалог: желание не равно текущему ресурсу
Посетитель пишет: «Хотим сайт, рекламу и CRM для нового направления». Если карточка сообщает, что сайт и CRM уже есть, система исказила исходную ситуацию. Слова взяты из сообщения, но смысл изменен. Дословная цитата сама по себе не гарантирует правильного вывода.
В этом условном примере помощнику нужно сохранить цель и уточнить, что уже работает. Если человек вместо продолжения анкеты просит консультацию, он должен получить прямой путь к записи. Если спрашивает о цене, нужен состав соответствующего предложения, а не очередной общий вопрос.
Такой сценарий хорошо показывает разницу между эффектным разговором и полезной обработкой. Проверять нужно не только текст на экране, но и фактическое содержимое карточки, которое увидит ответственный.
В карточке я разделяю три вещи: сообщенный клиентом факт, предложенный помощником вариант и вопрос без ответа. «Рассматриваем выход в регионы» нельзя сохранять как «работает федеральная сеть». Когда посетитель исправляет город или состав задачи, актуальная версия должна попасть и в карточку, и в передачу. Иначе менеджер начнет разговор с ошибки, которую клиент уже исправил.
Что я проверяю перед допуском
Нужны обычные и неудобные диалоги: неполная информация, смена задачи, вопрос о скидке, несуществующая услуга, длинное сообщение, отказ оставлять контакт. Отдельно проверяется попытка заставить систему придумать результат, цену или обещание. Ответ должен оставаться в пределах подтвержденной базы знаний.
Затем проверяется техническое поведение: потерянный ответ сервера, повтор отправки, недоступность CRM и отсутствие свободного времени. Надпись «отправлено» должна соответствовать реальному состоянию передачи. Сохраненная заявка и доставленное уведомление являются разными событиями.
Для передачи нужны проверяемые состояния: запрос сохранен, доставка ожидается, получатель принял запрос либо возникла ошибка. При повторе после сетевого сбоя система должна найти ту же заявку, а не создать еще одну. Если календарь недоступен, помощник предлагает запросить время, но не придумывает свободный слот. Это требования к внедрению, а не заявление, что любой существующий виджет уже так работает.
После запуска нужны просмотр ошибок и обновление знаний. Изменившийся состав услуги не должен оставаться старой ценой в чате. Для этого страницы и помощник должны получать коммерческие сведения из общего источника, а не из нескольких вручную написанных инструкций.
Коммерческие ограничения проверяются не только инструкцией для модели. Допустимые услуги, цена из реестра, право на запись и фактический результат передачи проверяются приложением. Сообщение посетителя не должно давать помощнику новые полномочия. Если подтвержденного ответа нет, полезнее явно передать вопрос человеку, чем закончить разговор уверенным предположением.
Как оценивать пользу
Я сравниваю не количество реплик, а путь до следующего действия: какие сведения удалось собрать, сколько исправлений внес менеджер, сколько передач завершились и где люди отказались продолжать. В оценку входят и неудачные диалоги. Длинная беседа без пригодной карточки не становится успехом только потому, что посетитель много отвечал. Для сравнения с обычной формой нужны сопоставимые источники и задачи; изменение качества трафика нельзя приписывать чату.
Когда чат пока не нужен
Если предложение не сформулировано, сотрудники спорят о правилах работы, а обращениям некому отвечать, ИИ не устранит эти причины. Иногда полезнее сначала исправить страницу, форму и маршрут передачи. Сложный диалог не должен становиться препятствием между клиентом и человеком.
CHAT.LVUP представлен как пилот с отдельными границами доступных и развиваемых возможностей. Его наличие не означает, что любой бизнес можно подключить без подготовки и проверки конкретного сценария.
Начальный состав включает один сценарий квалификации, базу знаний, виджет, карточку и проверку передачи. Новые сценарии, лицензии и расходы на модель рассчитываются отдельно. Круглосуточное присутствие оператора не входит в сам факт установки чата.