«Как изменить адрес доставки?»
Бот объясняет, где находится нужный раздел, и присылает ссылку на инструкцию.
«В моём заказе уже нельзя изменить адрес».
Бот снова предлагает открыть настройки заказа.
«Позовите человека».
К моменту подключения оператора клиент уже потратил время, но его задача осталась нерешённой. Теперь нужно повторить вопрос, назвать номер заказа и ещё раз объяснить, почему инструкция не помогла.
Формально бот ответил быстро. Но поддержке всё равно предстоит обработать обращение, а клиенту пришлось пройти несколько лишних шагов.
Чтобы автоматизация разгружала поддержку, нужно оценивать, помогла ли она решить вопрос и сколько усилий потребовала от клиента.
Разберём, почему диалоги застревают, какие действия можно передать ИИ и как проверить пользу на одном сценарии до расширения проекта.
Клиенту нужен результат, а бот выдаёт инструкцию
Часть обращений действительно решается справочной информацией.
Человек спрашивает о времени работы, способах оплаты или условиях доставки. Если ответ актуален и понятен, диалог может закончиться на этом.
Но в других случаях клиент обращается за изменением конкретной ситуации:
- выяснить, где находится его заказ;
- перенести доставку;
- исправить контактные данные;
- зарегистрировать возврат;
- восстановить доступ;
- разобраться с повторным списанием.
Здесь общей инструкции может оказаться недостаточно.
Чтобы помочь, системе нужны данные о конкретном заказе или аккаунте, доступные действия и правила их выполнения. Если у бота есть только база ответов, он может объяснить процедуру, но не обязательно сможет провести клиента по ней.
Проблема возникает, когда это ограничение скрыто. Клиент ожидает решения, а бот продолжает предлагать похожие статьи.
Перед автоматизацией каждого сценария стоит закончить фразу: «После этого диалога у клиента должно…»
Например:
После этого диалога у клиента должно появиться подтверждение нового адреса доставки или зарегистрированное обращение к сотруднику, который проверит возможность изменения.
Такую цель уже можно проверить.
Почему просьба позвать человека сама по себе не означает провал
Иногда подключение сотрудника является правильным результатом.
Клиент может оспаривать операцию, столкнуться с нестандартной ситуацией или просто захотеть обсудить вопрос с человеком. Не нужно заставлять его доказывать, что бот не справился.
Важно различать два сценария.
В первом бот понял запрос, собрал необходимые данные и передал обращение ответственному. Сотрудник продолжил работу с того места, где остановился диалог.
Во втором клиент несколько раз переформулировал вопрос, получил одинаковые ответы и только после этого добился подключения оператора.
В обоих случаях состоялась передача человеку. Но затраты времени и впечатление клиента будут разными.
Поэтому цель «как можно реже подключать оператора» может привести к неудобному процессу. Полезнее определить, какие вопросы система должна решать самостоятельно и в каких случаях обязана быстро передавать работу сотруднику.
Найдите место, где разговор перестаёт помогать
Начните с обращений, в которых клиенты просили оператора после общения с ботом.
Для первого разбора можно взять небольшую выборку за обычный рабочий период. Включите разные темы и исходы. Такая проверка поможет найти повторяющиеся проблемы, но не заменит оценку всего потока.
Для каждого диалога заполните таблицу:
Аудит диалогов, в которых клиент просит оператора| Что проверить | Что записать |
|---|
| Задача клиента | Какой результат он хотел получить |
|---|
| Ответ бота | Какую информацию или действие предложила система |
|---|
| Где возникло препятствие | Почему клиент не смог продолжить |
|---|
| Доступные данные | Видел ли бот нужный заказ, статус или историю |
|---|
| Возможность действия | Мог ли бот выполнить операцию или создать обращение |
|---|
| Причина передачи | Ограничение системы, ошибка, исключение или просьба клиента |
|---|
| Повторение информации | Пришлось ли клиенту заново объяснять ситуацию |
|---|
| Итог | Вопрос решён, передан в работу или остался открытым |
|---|
Ищите конкретную причину.
«Клиенты не любят бота» мало помогает выбрать доработку. А формулировка «бот предлагает изменить адрес самостоятельно, хотя заказ уже передан в доставку» указывает на определённую проблему: система не учитывает статус заказа.
Четыре причины, из-за которых клиент застревает
1. Бот не видит данные конкретного обращения
Он знает общие сроки доставки, но не знает, что происходит с заказом клиента.
В таком случае требуется подключение к источнику актуальных данных. При этом система должна проверить, имеет ли пользователь право получить информацию о заказе. Одного знания номера заказа может быть недостаточно.
Если источник временно недоступен, бот должен сообщить об этом и предложить рабочий следующий шаг. Выдуманный статус только усложнит разбор.
2. Бот может рассказать о действии, но не выполнить его
Он объясняет, как оформить возврат, однако клиенту всё равно нужно искать форму, повторно вводить данные и прикладывать фотографии.
Часть этого пути можно сократить: собрать нужную информацию в диалоге и создать черновик обращения или само обращение, если это разрешено правилами компании.
Важно различать результат. Сообщения «заявка на возврат зарегистрирована» и «возврат одобрен» означают разные вещи. Система должна точно сообщать, что произошло.
3. Бот не замечает, что предыдущий ответ не помог
Клиент пишет: «Я уже пробовал». Система повторяет ту же инструкцию другими словами.
Для такого случая нужен отдельный переход: уточнить конкретное препятствие, предложить другой допустимый способ или подключить сотрудника.
Бесконечное повторение справки не делает обращение решённым.
4. Передача человеку обнуляет диалог
Оператор видит только последнее сообщение или короткую фразу «нужна помощь».
Клиент повторяет номер заказа, описание проблемы и уже выполненные действия. Часть информации может потеряться или измениться при пересказе.
Сотруднику полезно передавать исходный диалог вместе с кратким резюме: задача клиента, проверенные данные, выполненные действия и нерешённый вопрос. Резюме ИИ не должно подменять доступ к оригинальной переписке.
Какие действия можно передать ИИ
Не обязательно сразу создавать помощника, который самостоятельно решает любые обращения.
Выберите повторяющийся сценарий и определите границы.
Действия ИИ-ассистента и условия передачи сотруднику| Сценарий | Что может делать помощник | Когда нужен сотрудник |
|---|
| Проверка статуса заказа | Получить актуальный статус после проверки доступа и объяснить следующий шаг | Данные противоречат друг другу или статус требует разбирательства |
|---|
| Изменение адреса | Проверить возможность изменения, показать новый адрес для подтверждения и выполнить разрешённую операцию | Заказ уже на этапе, где требуется ручное согласование |
|---|
| Обращение на возврат | Собрать обязательные сведения и зарегистрировать запрос | Решение требует проверки товара или нестандартных условий |
|---|
| Восстановление доступа | Провести по утверждённой процедуре восстановления | Стандартная проверка не пройдена или есть признаки спорного доступа |
|---|
| Жалоба на оплату | Собрать сведения и передать обращение нужному специалисту | Требуется финансовое решение или расследование |
|---|
Возможности зависят от ваших систем и правил. Таблица служит основой для проектирования, а не универсальным разрешением на перечисленные действия.
ИИ может помогать понимать свободно сформулированный запрос и вести диалог. Проверки доступа, допустимости операции и обязательного подтверждения должны обеспечиваться программными правилами.
Например, изменение адреса не должно выполняться только потому, что модель решила: «Похоже, это разрешено».
Как выглядит полезная передача оператору
Вернёмся к изменению адреса.
Клиент сообщает, что в личном кабинете редактирование недоступно. Помощник проверяет статус и выясняет, что заказ уже передан в доставку.
Дальше он может объяснить ограничение и, если такая процедура предусмотрена, собрать новый адрес и создать обращение специалисту.
Клиент получает:
- подтверждение, что обращение зарегистрировано;
- номер обращения;
- информацию о следующем шаге;
- срок ответа, если компания действительно может его соблюдать.
Оператор получает:
- идентифицированный заказ;
- текущий статус;
- новый адрес, указанный клиентом;
- сведения о выполненных проверках;
- вопрос, требующий решения;
- исходную переписку.
Адрес пока не изменён. Но работа продвинулась, а клиенту не нужно начинать сначала.
Такая передача может быть ценнее для бизнеса, чем длинный диалог, который закончился без оператора и без решения.
Что измерять вместо количества ответов бота
Количество сообщений и скорость первой реакции показывают активность системы. Для оценки пользы нужны показатели, связанные с результатом.
Показатели качества автоматизации поддержки| Показатель | На какой вопрос отвечает |
|---|
| Доля подтверждённо решённых обращений | Сколько задач действительно завершено |
|---|
| Повторные обращения по той же проблеме | Возвращаются ли клиенты, потому что решение не помогло |
|---|
| Время до решения | Стал ли клиент получать результат быстрее |
|---|
| Время сотрудника на обращение | Сократилась ли ручная работа |
|---|
| Качество передачи оператору | Получает ли сотрудник данные для продолжения |
|---|
| Ошибочные ответы и действия | Не создаёт ли автоматизация новые проблемы |
|---|
| Усилия клиента | Приходится ли повторять сведения и проходить лишние шаги |
|---|
Заранее определите, что означает «решено» для каждого сценария.
Для изменения адреса подтверждением может служить успешная операция в системе и уведомление клиента. Для справочного вопроса потребуется другой способ оценки, например выборочная проверка диалогов и обратная связь.
Не считайте молчание клиента доказательством успеха. Он мог получить ответ, устать от разговора или уйти искать помощь в другом месте.
Повторные обращения тоже анализируйте с учётом содержания. Новый вопрос по тому же заказу не всегда означает, что предыдущий остался нерешённым.
Как проверить экономику на одном сценарии
Предположим, в компанию поступает 300 обращений определённого типа в месяц. Раньше сотрудник тратил на каждое в среднем шесть минут.
После пилота выяснилось:
- 180 обращений помощник корректно завершил без участия оператора;
- 120 обращений передал сотруднику;
- обработка переданного обращения занимает в среднем четыре минуты благодаря собранным данным.
До автоматизации на эту группу обращений уходило:
300 × 6 = 1 800 минут, или 30 часов.
После автоматизации работа операторов по переданным обращениям занимает:
120 × 4 = 480 минут, или 8 часов.
Предварительная разница составляет 22 часа в месяц. Из неё нужно вычесть время на контроль качества, исправления и поддержку сценария. Повторные обращения из-за ошибок также необходимо включить в расчёт.
Это условный пример, а не обещание результата. Освободившееся время само по себе не уменьшает фонд оплаты труда.
Практическая польза может состоять в сокращении очереди, обработке большего числа обращений или уменьшении переработок. Денежный эффект следует оценивать по изменениям, которые действительно произошли, с учётом стоимости внедрения и эксплуатации.
С чего начать, если бот уже работает
Не обязательно переделывать его целиком.
Выберите одну частую причину подключения оператора. Найдите шаг, который бот не может выполнить, и определите, что нужно добавить: актуальные данные, разрешённое действие, другое уточнение или передачу контекста.
До изменений зафиксируйте текущие показатели. После доработки проверьте обычные обращения, исключения, недоступность внешней системы и повторную отправку запроса. Последняя не должна приводить к повторному выполнению одной и той же операции.
На первом этапе можно оставить спорные действия на подтверждение сотруднику. Расширять самостоятельность помощника стоит после проверки качества конкретного сценария.
В Futureinapps мы создаём ИИ-ассистентов для клиентов и подключаем их к рабочим системам компании. Начать обсуждение можно с нескольких обезличенных диалогов, в которых бот не помог, и описания результата, который должен был получить клиент.
На этой основе можно выбрать первый сценарий и определить, как проверить его пользу.
Хорошая автоматизация поддержки сокращает путь клиента к решению. Иногда для этого нужен точный ответ, иногда действие в системе, а иногда своевременное подключение человека.
