Клиент пишет в поддержку: “Где заказ? Сегодня крайний срок, дальше он мне не нужен”.
Бот отвечает сразу. Без очереди, без раздражения, в хорошем тоне. Присылает ссылку на правила доставки, предлагает проверить статус в личном кабинете и в конце заботливо спрашивает, помог ли ответ.
Формально все красиво. Время первого ответа — секунды. Оператор не подключался. Тикет можно закрывать.
Только клиент пришел не за ссылкой на правила. Ему нужен живой статус: товар выехал или лежит на складе, кто отвечает за задержку, можно ли перенести доставку, вернуть деньги или заменить позицию. Если бот этого не видит и не может запустить действие, он просто ставит красивую ширму между клиентом и решением.
В отчете у бизнеса зеленая строчка. В голове у клиента — “они меня не слышат”.
Где ломается магия
Многие внедрения AI в поддержку начинаются с нормального желания: снять рутину с операторов, отвечать быстрее, не держать клиента в очереди, снизить стоимость обращения.
Проблема появляется позже, когда удобная метрика становится главной. Сколько обращений бот удержал? Сколько тикетов не дошли до оператора? На сколько секунд быстрее стал первый ответ?
Эти цифры нужны. Но они легко подменяют смысл. Поддержка существует не для того, чтобы тикет красиво исчез из очереди. Она нужна, чтобы клиент дошел до решения и не возвращался с тем же вопросом через другой канал.
В исследовании Ada и NewtonX по AI в клиентском сервисе участвовали 2 000 потребителей и 500 руководителей CX/AI. Один из самых неприятных выводов: только 24% потребителей сказали, что AI полностью решил их вопрос без человека. Еще 11% просто бросили обращение без жалобы и follow-up. Для отчета такие молчаливые уходы могут выглядеть тихо. Для бизнеса это потерянный спрос, плохой отзыв или клиент, который в следующий раз не вернется.
Sinch в мае 2026 года показал похожую проблему уже со стороны компаний. 62% enterprise-компаний в исследовании уже держат AI-агентов в production, но 74% откатывали или отключали live AI customer communications agent после запуска из-за governance failures.
Значит, сложность не только в пилоте. На демо бот бодро отвечает на подготовленные вопросы. В реальной поддержке появляются персональные данные, спорные ситуации, несколько каналов, старые тикеты, CRM, доставка, платежи и клиент, который пишет не по сценарию.
Клиент не оценивает “автоматизацию”
Покупатель не знает, что вы снизили нагрузку первой линии на 30%. Ему все равно, сколько интентов обучено в вашем боте. Он не радуется тому, что обращение не попало к оператору.
Он оценивает проще: ответили ли ему по делу, увидели ли конкретный заказ, не заставили ли повторять одно и то же, передали ли человеку вовремя, может ли кто-то принять решение.
Metrigy в исследовании потребителей по customer experience пишет, что 84,9% предпочитают human agent AI-агенту. В том же исследовании 45,5% говорят, что используют AI в отдельных ситуациях. Люди готовы пользоваться автоматом, когда он удобен. Раздражение начинается в тупике.
На этой разнице и ломается много проектов. Руководитель видит экономию и скорость. Клиент видит, что его вопрос не двигается.
Где AI в поддержке работает
Из этой темы легко сделать бытовой вывод: “уберите ботов”. Я бы так не ставил вопрос. Боты нужны, когда не превращаются в стену между клиентом и компанией.
Российские кейсы это хорошо показывают. Ростелеком в марте 2026 года сообщил, что автоматизировал до 50% обращений в клиентскую поддержку в чатах с помощью “Омнибота” и базы знаний “ProЗнания”. В сообщении есть важные детали: до 300 000 запросов в сутки, больше 500 сценариев, свыше 400 интентов, интеграция с корпоративными платформами через сервисную шину. Один виджет на сайте такого эффекта не даст; тут важны интенты, знания, каналы и внутренние системы.
Другой полезный пример — кейс Медиалогии IM для B2B SaaS-платформы. У клиента обращения за год выросли с 12 000 до 36 000 в месяц, 35-40% запросов были типовыми, очередь доходила до 150-200 обращений, время ответа выросло до 8-12 часов. После объединения каналов, автоклассификации, SLA и автоматической обработки типовых запросов через месяц автоматически закрывалось 30-32% обращений. Время обработки типового запроса сократилось с 8 до 3,5 минуты, производительность команды выросла в 1,7 раза, NPS поднялся с 28 до 41.
Обратите внимание, что сработало. Команда аккуратно разобрала поток: типовые вопросы отдельно, негатив и инциденты отдельно, дубли из разных каналов склеиваются, у тикета есть история и статус, SLA контролируется, оператор видит контекст.
Intercom в кейсе с Claude описывает похожую механику с другой стороны. Их Fin показывает средний resolution rate 51% out of the box, в отдельных сценариях до 86%, а время ответа сокращается с десятков минут до секунд. Но важнее не сама цифра, а четыре блока, на которых держится качество: знания, поведение, действия и аналитика. Бот должен знать продукт, соблюдать правила компании, уметь делать действия, а не только говорить, и давать видимость того, где поддержка ломается.
Четыре уровня проверки
Перед внедрением или ревизией AI-поддержки полезно пройти не по функциям сервиса, а по лестнице решения.
Первый уровень — ответ. Бот может объяснить правило, найти статью базы знаний, подсказать, где лежит документ, как оформить возврат, какие сроки по регламенту. Это самый безопасный слой, но он же самый обманчивый: здесь легко получить много “успешных” диалогов, которые ничего не решили.
Второй уровень — статус. Бот видит заказ, платеж, остаток, доставку, гарантию, прошлые обращения. Если клиент спрашивает “где мой счет” или “почему не пришел товар”, бот не пересказывает инструкцию, а смотрит конкретный объект.
Третий уровень — исключение. У клиента сломался сценарий: доставка сорвалась, счет завис, в заказе пересорт, договор ушел на второе согласование, возврат требует решения. Здесь бот должен не изображать уверенность, а понять, кому и с каким контекстом передать вопрос.
Четвертый уровень — решение. У процесса есть владелец и полномочия: компенсировать, заменить, ускорить, согласовать, отдать скидку, создать задачу, предупредить менеджера. Если таких полномочий нет, AI будет красиво говорить вокруг проблемы.
Я бы проверял поддержку пятью вопросами:
- Какие 20 тем дают больше всего повторных обращений?
- Где бот отвечает, но клиент потом пишет в другой канал?
- Какие вопросы требуют доступа к CRM, 1C, складу, биллингу или трекеру доставки?
- Где бот обязан передать человекам не просто “клиент недоволен”, а краткую историю, статус, риск и следующий шаг?
- Какие метрики показывают решение: repeat contact rate, first contact resolution, reopened tickets, CSAT по AI-диалогам, время до фактического действия?
Если эти вопросы не заданы, проект почти неизбежно начнет оптимизировать тишину. Очередь меньше, ответ быстрее, операторов трогают реже. А клиенты продолжают искать живой вход.
Как бы я ставил задачу
Я бы не начинал с фразы “нам нужен AI-бот в поддержку”.
Начал бы с карты обращений за последние 30-60 дней. Какие темы повторяются. Где вопрос закрывается одним ответом. Где нужна проверка данных. Где нужен человек с правом принять решение. Где клиент возвращается второй раз. Где обращение уходит из чата в звонок, из звонка в письмо, из письма в претензию.
После этого поток можно разделить на четыре корзины: справка и навигация, статус по объекту, спорная ситуация, решение с деньгами или сроками.
Такой подход менее эффектен на презентации, чем “автоматизируем 80% поддержки”. Зато он ближе к деньгам. Потому что деньги в поддержке теряются не только на зарплате операторов. Они теряются в повторных контактах, возвратах, плохих отзывах, срывах сделок и клиентах, которые ушли молча.
Что должно быть в отчете
Если в отчете по AI-поддержке есть только automation rate, containment и first response time, я бы считал его неполным.
Нужны еще несколько строк: сколько обращений решено без повторного контакта, сколько AI-диалогов открылось повторно в течение 24-72 часов, где клиент после бота ушел в звонок или письмо, сколько раз оператору пришлось заново спрашивать то, что клиент уже писал боту, какие темы бот обязан передавать человеку без попытки “дожать” диалог.
Тогда разговор меняется. Поддержка перестает доказывать, что “бот работает”. Она начинает показывать, где клиент доходит до результата, а где процесс только притворяется автоматизированным.
Хорошему AI в поддержке не надо имитировать человека. Его работа — довести вопрос до места, где есть данные, действие и ответственность.
Иногда это значит ответить без оператора. Иногда — открыть нужный статус. Иногда — сразу передать человекам короткую выжимку: кто клиент, что случилось, какой риск, что уже проверено, какой следующий шаг.
Бот, который быстро отвечает, но не двигает вопрос, экономит секунды и сжигает доверие. Бот, который убирает повторы и ведет клиента по маршруту, действительно снижает нагрузку.
А у вас бот в поддержке решает вопрос или просто красиво отвечает?
Больше разборов про AI-автоматизацию без витринной магии: t.me/woghan_dev