ИИ-бот может разгрузить службу поддержки, но количество закрытых диалогов еще не показывает результат. Разбираем интеграции с CRM и helpdesk, метрики deflection, FCR и CSAT, передачу обращений оператору и полную стоимость внедрения для компаний.

Оксана Иванова

25 октября 2026 г.

12 мин.

Корпоративный ИИ-бот обрабатывает типовые обращения, получает сведения из разрешённых систем и передаёт сложные случаи оператору. Его пользу оценивают по подтверждённым решениям без человека (deflection), FCR, CSAT, качеству эскалаций и полной стоимости владения (TCO). В Mad Brains начинаем с анализа тикетов и проверяем результат на пилоте.

Клиент спрашивает, почему задержалась поставка. Бот за секунду отвечает: «Ваш запрос принят», закрывает чат — и улучшает отчёт по скорости. Через час клиент звонит менеджеру: местонахождение груза ему никто не объяснил. Для компании это не автоматизация поддержки, а перенос проблемы на другой канал.

В B2B-сервисе вопрос связан с договором, оборудованием или SLA. Недостоверный ответ задерживает работу. Поэтому мы оцениваем результат, а не красоту диалога.

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

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

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

Разделяем обращения по сложности и риску. Автоматизируем вопросы о статусе тикета, оформлении документов, инструкциях, графике обслуживания. Через разрешённый API бот проверяет статус, собирает сведения и регистрирует запрос.

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

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

ИИ-бот для поддержки должен работать внутри сервисного контура, а не становиться ещё одним разрозненным чатом.

Helpdesk/ITSM: создание и обновление тикетов, приоритеты, маршрутизация, SLA, история и защита от дублей. При сбое API обращение не теряется: предусмотрена очередь повторов или передача человеку.

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

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

Каналы связи: сайт, личный кабинет, почта и мессенджеры. Связываем контакты одного клиента по разрешённым идентификаторам, иначе повторный запрос по почте не попадёт в историю чат-бота.

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

Deflection rate — доля обращений, которые сервис самообслуживания завершил без участия человека. У платформ встречаются разные правила подсчёта, поэтому в начале проекта утверждаем единую методику.

Для общей картины используем формулу: подтверждённо решённые ботом обращения / все входящие обращения поддержки × 100%. Отдельно считаем долю решений среди запросов, которые вообще обрабатывал бот: так различаем охват и качество.

Допустим, за месяц поступило 10 000 обращений. Боту передали 4 000, из них 2 200 действительно решены без оператора. Общая доля составит 22%, результат внутри охваченного потока — 55%. Обе цифры полезны; показывать только вторую означало бы преувеличить вклад в общую службу.

Тайм-аут, уход с сайта и отсутствие ответа не считаем подтверждённым решением. Предполагаемые решения выделяем отдельно и проверяем повторные контакты по тому же вопросу, например за 72 часа. Иначе показатель можно поднять, просто затруднив вызов оператора.

First Contact Resolution показывает долю вопросов, завершённых при первом обращении без повторного контакта по той же причине. Формула: решённые с первого контакта обращения / обращения в согласованной выборке × 100%. Для сопоставимости заранее задаём окно повторного контакта и правила идентификации одной проблемы.

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

Не сравниваем напрямую категории, где первое обращение по определению не может устранить инцидент, и простые справочные вопросы. Иначе метрика будет отражать состав тикетов, а не качество команды.

Customer Satisfaction Score измеряет удовлетворённость после обращения. Например, при пятибалльной шкале оценки 4 и 5 считаются положительными. CSAT = положительные оценки / все полученные оценки × 100%. Если 420 из 500 ответивших довольны, результат — 84%.

Однако важна доля ответивших. Если опрос прошли 500 из 5 000 клиентов, выводы нельзя безоговорочно переносить на всех. Поэтому анализируем отклик, комментарии, категории запросов и отдельные оценки бота, операторов и совместных сценариев. Рост deflection при ухудшении CSAT — повод пересмотреть автоматизацию.

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

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

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

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

Проверяем точность темы, опору на источник, корректность API-действий, защиту данных, эскалации и повторы. Отдельно тестируем устаревшую инструкцию, недоступную CRM и попытку изменить правила через текст сообщения.
Критерии приёмки утверждаем до пилота: это могут быть правильность статуса заказа или соблюдение SLA. Универсальной нормы нет.

TCO (Total Cost of Ownership) — все расходы на решение за выбранный период, например один или три года. Цена разработки не равна стоимости владения.

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

Для чат-бота с несложной кастомизацией возможен ориентир 300 тыс.–1,5 млн ₽. Это не фиксированная стоимость проекта Mad Brains. Корпоративный сервис с несколькими интеграциями, повышенной нагрузкой и особыми требованиями безопасности оцениваем индивидуально. Его эксплуатация может стоить дороже прототипа.

Предположим, B2B-служба получает 20 000 обращений ежемесячно. Пилот подтвердил 4 000 решений без человека, а полная избегаемая стоимость обработки такого обращения составляет 200 ₽. Потенциально освобождается ресурс на 800 000 ₽ в месяц.

В условном расчёте разработка и запуск стоят 3 млн ₽, эксплуатация — 350 тыс. ₽ ежемесячно. TCO первого года: 3 млн + 350 тыс. × 12 = 7,2 млн ₽. Потенциальный годовой эффект при неизменном потоке — 9,6 млн ₽. Разница — 2,4 млн ₽ лишь при условии, что весь освобождённый ресурс удалось финансово реализовать.

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

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

Затем подключаем helpdesk и CRM в тестовом контуре, настраиваем полномочия, эскалации и аналитику. На пилоте сравниваем deflection, FCR, CSAT, ошибки и TCO с исходными показателями. Расширяем охват только после проверки; изменение инструкций и прав требует повторных испытаний.

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

Поможем выделить сценарии для автоматизации, спроектировать интеграции и установить проверяемые показатели результата. Расскажите об объёме тикетов, используемых CRM и helpdesk, базе знаний и требованиях SLA. Подготовим границы пилота, критерии приёмки и предварительную оценку TCO — до решения о масштабировании.

Оксана Иванова

25 октября 2026 г.

12 мин.