Сценарии для чат-бота: Готовые идеи автоматизации поддержки, продаж и обучения

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

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

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

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

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

Повторное обращение — сигнал, а не приговор

В условном примере 2 100 из 8 400 диалогов без сотрудника завершились повторным обращением по тому же заказу в течение семи дней. Это 25%. Если считать все 8 400 диалогов решёнными, повторный контакт выглядит странным исключением. Если же признавать задачу завершённой только после подтверждённого результата, а затем проверять повторы, они становятся диагностическим сигналом.

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

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

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

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

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

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

Передача сотруднику

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

Сначала определите причины передачи. Операция может не поддерживаться автоматизацией, правила магазина могут требовать проверки специалистом, а в заказе или платеже может возникнуть исключение. Иногда сотрудника просит сам покупатель; иногда бот не понимает запрос или не уверен в распознавании. Бывает, что система не работает или не отдаёт нужные данные. Отдельная причина — повторный вопрос после неудачной попытки пройти сценарий.

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

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

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

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

Связать результат с затратами и клиентским опытом

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

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

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

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

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

Панель, которая показывает противоречия

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

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

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

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

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

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

В примере магазина панель могла бы показать: 84% диалогов завершились без сотрудника; для 56% всех запросов подтверждено, что покупатель увидел актуальный статус; в 25% диалогов без сотрудника в течение семи дней последовало повторное обращение по тому же заказу; по 700 из 8 400 таких диалогов результат установить не удалось. Время первого ответа составило три секунды, но времени до решения пока нет. Такой отчёт менее эффектен, чем три растущих графика. Зато он точно подсказывает, что проверить дальше: повторы, полноту данных и связь ответа с фактическим статусом заказа.

Не смешивайте разные сценарии в один средний показатель. Справочные вопросы, изменения заказа, возвраты и другие задачи нужно рассматривать отдельно, а затем объединять с понятными весами. Иначе простые массовые запросы могут скрыть провал в редких, но важных ситуациях. Полезно также смотреть показатели по каналу, версии сценария и наличию сбоев интеграции — не ради бесконечного множества графиков, а чтобы понять, где именно нарушается путь пользователя.

Измерение начинается до запуска

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

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

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

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

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

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