ИИ-агент в поддержке: как он разбирает входящие обращения
Большая доля обращений в поддержку — это статус заказа, оплата, сроки: вопросы, где нужен не разговор по душам, а доступ к данным. Этот слой ИИ-агент закрывает первым.
Классификация происходит до того, как клиент дописал сообщение
Первое, что делает агент с входящим текстом, — определяет тему обращения, а не отвечает на него. «Где мой заказ» и «когда вернёте деньги» для человека звучат как разные проблемы, для модели — как два разных запроса к данным: один тянет статус доставки, второй — статус платежа. Агент классифицирует тему обращения по смыслу, а не по вхождению слов, и дальше выбирает источник: карточку сделки в amoCRM или Bitrix24, статус заказа в учётной системе, историю переписки с этим же клиентом за последние недели.
Если ответ есть в данных — заказ действительно в пути, платёж действительно прошёл, счёт действительно выставлен — агент формулирует ответ сам и отправляет его без участия человека. Это не шаблон с подстановкой имени, а короткий ответ, собранный из актуального статуса. Клиент получает результат за секунды, а не через полчаса ожидания оператора, у которого в очереди ещё пятнадцать таких же вопросов.
Здесь и решается основная часть нагрузки поддержки. Вопрос про статус — это вопрос с одним правильным ответом, который уже лежит в базе данных. Задача агента — найти этот ответ и не наврать.
Нетиповое обращение уходит человеку вместе с готовым разбором
Там, где однозначного ответа в данных нет — спор о качестве, просьба об исключении из правил, эмоциональная жалоба, — агент не пытается изобразить эмпатию по скрипту. Он эскалирует диалог человеку. Разница с обычной переадресацией в том, что оператор получает не сырой чат, а готовое резюме: суть проблемы, что уже проверено агентом (статус заказа, платежа, предыдущие обращения этого клиента), что осталось решить. Клиенту не нужно писать вопрос заново — вся история пришла оператору вместе с обращением.
Это снимает главный источник раздражения в поддержке: клиент трижды пересказывает одну и ту же проблему разным людям. Агент выступает первым слоем разбора, а не барьером перед оператором.
Технически это устроено как связка ИИ-агента с CRM: агент читает статусы сделки и историю коммуникаций напрямую через API amoCRM или Bitrix24, а не через отдельную базу знаний, которую нужно синхронизировать вручную. Подробнее о том, как я собираю такие связки, — на странице услуги по внедрению ИИ-агентов.
Почему бот по ключевым словам — не то же самое
Дело в интерфейсе только на первый взгляд. Бот по ключевым словам ловит триггер-слово и на этом останавливается: «возврат» сработает одинаково для «хочу вернуть товар» и «когда вернёте деньги за отменённый заказ», хотя это два разных процесса с разными данными. Клиент получает один и тот же типовой ответ на оба вопроса, переспрашивает или сразу уходит к оператору — и смысл автоматизации теряется на первом же контакте.
Агент оценивает намерение обращения целиком: к какому объекту в CRM оно относится — заказу, платежу, договору — и есть ли в данных сам ответ. Ключевые слова были рабочим протоколом распознавания текста лет пятнадцать назад, когда языковые модели ещё стоили дороже, чем ручная разметка сценариев для бота. Сейчас это соотношение цены обратное.
Данные остаются в контуре, совместимом с 152-ФЗ
В переписке с поддержкой почти всегда есть персональные данные: имя, номер заказа, иногда телефон или адрес. Это значит, что весь разбор обращений должен идти на модели, с которой я могу гарантировать, где физически хранятся данные. Я собираю такие агенты на моделях, совместимых с российским законодательством, — YandexGPT, GigaChat или self-hosted модель на своей инфраструктуре, — а не на зарубежном API, где данные клиента уходят за периметр РФ без возможности проконтролировать это.
Для агента поддержки это не формальность, а часть архитектуры: если модель и хранилище диалогов физически в России, разбор обращений можно встраивать в тот же контур, где уже живёт CRM и сквозная аналитика, без риска, что персональные данные клиента окажутся там, где их быть не должно.
Итог для тех, кто уже разбирает обращения руками
Если поддержка сейчас — это очередь операторов, читающих одни и те же вопросы про статус заказа, слой автоматической классификации и ответа на типовые обращения снимает не всю нагрузку, а её предсказуемую часть — обычно самую большую. Нетиповое по-прежнему решает человек, но с разбором на руках, а не с чистого листа.

Никита Бердников
Официальный партнёр amoCRM (ID 28602378), Roistat и SIPUNI. 5+ лет настраиваю CRM, сквозную аналитику и телефонию под выручку — лично, без агентских посредников. 25+ проектов, ₽100M+ выручки клиентов.
Похожие статьи
Бот в MAX для записи и напоминаний клиентам
Запись и напоминания — самая недооценённая автоматизация: клиент, которому вовремя напомнили, доходит; забытая запись — потерянная выручка. В MAX это закрывается ботом, связанным с CRM.
MAX или Telegram для бизнеса: что меняет 152-ФЗ
Telegram удобен и привычен, но когда через бота проходят данные клиентов — заявки, телефоны, переписка, — включается 152-ФЗ. И вот здесь MAX как российский мессенджер даёт бизнесу то, чего Telegram не даёт.
Внутриканальные боты в MAX: уведомления и процессы для команды
Клиентский бот в MAX на виду, но не меньше пользы во внутреннем слое: уведомления команде и боты, которые ведут внутренние процессы, — там, где раньше был чат, где всё тонет.