ИИ в поддержке клиентов: как отвечать быстрее и доводить обращения до решения

Что можно поручить ИИ в первую очередь

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

Кейс Lightspeed: самостоятельные ответы и помощь сотрудникам

В кейсе Intercom от 10 октября 2024 года Lightspeed Commerce описывает применение Fin AI Agent и Copilot. В разных рабочих пространствах заявлена доля разрешённых Fin обращений от 45% до 65%. Участие в диалогах оценивалось в 99%, а доля вопросов, на которые система могла ответить, — в 95%. Это разные показатели: высокий охват ещё не равен высокому разрешению.

Для Copilot в период тестирования сообщалось о росте числа закрываемых разговоров на сотрудника в день на 31%. Компания также описывает обучение команды, внутренние каналы обсуждения и поддержку запуска. Это кейс поставщика с результатами внедрения, без независимой контрольной группы. Практический вывод — проверять отдельно пользу для оператора и самостоятельную работу бота. Источник: Intercom / Lightspeed.

Кейс Synthesia: самообслуживание шире, чем чат с нейросетью

В материале Intercom от 10 октября 2024 года Synthesia рассказывает о росте месячного числа клиентов, ищущих помощь, с 40 тысяч до 316 тысяч между апрелем и августом 2024 года. Поддержку обеспечивали справочный центр, автоматизация и Fin.

Компания сообщала о 98,3% самообслуживания во всей этой системе, тогда как доля разрешения обращений Fin составляла 55%. Складывать или напрямую сопоставлять эти проценты нельзя: у них разные основания расчёта. В кейсе также приведено сокращение времени разрешения с пяти дней пяти часов до четырёх часов 37 минут. Это результат изменения процесса по данным компании, а не эксперимент, изолирующий эффект одной модели. Источник: Intercom / Synthesia.

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

Кейс Klarna: большой объём автоматизации и сохранение человеческого обслуживания

В годовом отчёте за 2025 год Klarna указывает, что ИИ-ассистент обрабатывал 80% чатов клиентского обслуживания за этот год по данным внутренних журналов. Слово «обрабатывал» не следует автоматически заменять словом «полностью решил».

В том же отчёте описан подход, сочетающий широкое применение ИИ и качественное обслуживание людьми. Это важнее истории о механической замене всего отдела: клиентские ситуации различаются, и у сложного вопроса должен оставаться путь к сотруднику. Отчёт компании — первичный источник её заявлений, однако показатели требуют собственного определения и проверки при сравнении с другой службой. Источник: Klarna, Form 20-F за 2025 год, опубликованный в 2026 году.

Шаг 1. Выберите тип обращений и определите результат

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

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

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

Шаг 2. Подготовьте базу знаний

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

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

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

Шаг 3. Разделите чтение данных и действия

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

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

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

Шаг 4. Сделайте передачу оператору частью сценария

Редакционная схема передачи. Повторно просить клиента описать всю историю обычно не требуется, если контекст уже доступен сотруднику.

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

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

На старте проверяйте все автоматически закрытые обращения или доступную обоснованную выборку. Отсутствие нового сообщения не всегда означает удовлетворение клиента: он мог уйти в другой канал или отказаться от покупки.

Как измерять качество без путаницы в процентах

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

Ниже — учебный пример, не результат реального клиента. Из 1 000 подходящих обращений бот ответил на 800. На проверке 500 оказались решены правильно; 100 из этих клиентов повторно обратились с той же проблемой в выбранном окне наблюдения. Если бизнес считает устойчивым решением отсутствие такого повтора, подтверждённых решений будет 400: 40% от всех подходящих обращений и 50% от отвеченных ботом. Формулировка «80% автоматизации» скрыла бы существенную часть картины.

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

Как посчитать экономику пилота

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

Условный расчёт: 400 подтверждённых решений экономят по пять минут работы — около 33,3 часа. При внутренней стоимости часа 900 ₽ это примерно 30 000 ₽ высвобождённого времени. Если ежемесячная система обходится в 18 000 ₽, а проверка требует ещё шесть часов, остаток составляет около 6 600 ₽. Разовая интеграция в этот расчёт ещё не включена. Часы становятся денежной экономией только если меняются реальные расходы или полезный объём работы.

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

План запуска на одном сценарии

1. Соберите и обезличьте примеры, определите правильный ответ и исключения.
2. Проверьте базу знаний и поиск, включите вопросы без ответа.
3. Запустите помощника оператору и измерьте время после проверки черновика.
4. Подключите самостоятельные ответы для ограниченного сценария.
5. Еженедельно разбирайте повторы, неверные ответы и передачи.
6. Расширяйте охват только после устойчивых результатов на новых обращениях.

Частые вопросы

Источники и дата проверки

Материал проверен 25 октября 2026 года. Кейс Lightspeed и кейс Synthesia опубликованы Intercom в октябре 2024 года; годовой отчёт Klarna относится к 2025 году. Внедрения, показатели и ограничения датированы по первичным публикациям. Учебные расчёты не относятся к этим компаниям.