Автоматизация клиентской поддержки с ИИ: что внедрять и как считать результат

ИИ закрывает 40–70% типовых обращений в поддержку, если перед ним есть база знаний и понятные сценарии эскалации. Ниже — разбор задач, стоимости, метрик и типичных ошибок внедрения для бизнеса без своего отдела разработки.

Сергей Езепенко · 12.11.2026 · время чтения 16 мин

Какие обращения закрывает ИИ, а какие остаются людям

Первый шаг в автоматизации поддержки — не выбор инструмента, а разбор текущего потока обращений. Выгрузите из CRM или helpdesk 300–500 последних тикетов и разметьте их по темам и по тому, чем закончилось дело: ответили шаблоном, вернули деньги, передали в другой отдел, закрыли после переписки. Такая выборка за пару часов показывает, где ИИ даст эффект, а где создаст риск. Без этой разметки внедрение превращается в угадывание.

Практика показывает устойчивую картину: типовые вопросы по заказу, оплате и доставке — это от 50 до 60% всего потока. «Где мой заказ», «как оплатить картой», «можно ли изменить адрес», «почему списали дважды» — на такие запросы есть однозначный ответ в заказе или в базе знаний. Их ИИ закрывает полностью: находит номер заказа в CRM, сверяет статус, отправляет ссылку на трекинг или инструкцию. Оператор к такому обращению не прикасается. При потоке в 2 000 обращений в месяц это порядка 1 000–1 200 диалогов, которые не доходят до людей.

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

Промежуточный вариант, который даёт больше всего экономии на сложных темах: ИИ готовит черновик ответа, оператор проверяет и отправляет. Модель формулирует текст по базе знаний и данным заказа, оператор правит формулировки и жмёт «отправить». Время на ответ падает с 6–8 минут до 1–2 минут, при этом ответственность за содержание остаётся на человеке. Это особенно полезно в первые месяцы, пока вы не набрали статистику качества.

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

Пример из практики интернет-магазина товаров для дома: после разметки 400 тикетов выяснилось, что 57% обращений — статус заказа и оплата, ещё 12% — вопросы по гарантии, которые решаются шаблоном. ИИ отдали первую группу, гарантию оставили людям из-за разнообразия условий по брендам. Через два месяца доля автоматических ответов стабилизировалась на 54%, а среднее время первого ответа упало с 40 минут до 3. Дальше расширять не стали — упёрлись в темы, где нужна ответственность.

Три технологии под разные задачи поддержки

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

Чат-бот по сценариям. Дерево диалога, где каждый шаг прописан: приветствие, выбор темы, уточняющие вопросы, ответ из базы. Работает предсказуемо — бот не скажет лишнего, потому что не генерирует текст, а подставляет заранее согласованные формулировки. Стоимость разработки и поддержки самая низкая: простой бот на 20–30 сценариев делается за 2–4 недели, сопровождение — правка веток по мере появления новых вопросов. Ограничение — узкий охват: если клиент сформулировал вопрос не так, как в сценарии, бот не поймёт и предложит оператора. По опыту, сценарный бот закрывает 20–35% потока, редко больше. Хорошо работает там, где вопросы однотипны: статус заказа, часы работы, условия доставки, запись на услугу.

LLM-ассистент по базе знаний. Модель отвечает свободным текстом, опираясь на ваши документы: статьи базы знаний, регламенты, карточки товаров, историю переписки. Гибкость выше на порядок — клиент может написать «а если я не успел забрать посылку, что будет с деньгами», и ассистент найдёт ответ в правилах возврата. Цена гибкости — контроль качества. Модель может уверенно выдать неточность, перепутать сроки или условия для разных тарифов. Поэтому обязательны три вещи: ответы только по базе знаний без «фантазий» (retrieval-augmented generation), регулярная выборочная проверка диалогов — хотя бы 50 в неделю, — и кнопка «позвать оператора» в каждом ответе. Первые 4–6 недель стоит держать режим черновика с проверкой человеком. Про то, как ассистент отличается от сценарного бота по логике работы, есть отдельный разбор: Чем ИИ-агент отличается от чат-бота и что выбрать бизнесу.

Классификатор обращений. Не отвечает клиенту вообще — читает входящий текст и раскладывает его по категориям: тема, срочность, тональность, язык, нужный отдел. Задача — маршрутизация и приоритеты. Классификатор ставят первым, до всяких ботов: он сразу снижает время до попадания в нужную очередь. Обучение — на тех же 300–500 размеченных тикетах, точность на типовых категориях достигает 85–92%, на редких темах ниже, и это нормально: сомнительные обращения уходят на ручную сортировку. Отдельная польза — аналитика: вы видите реальную структуру потока и можете обосновать, какой из двух предыдущих инструментов окупится.

Порядок внедрения, который редко подводит:

1. Классификатор — 2–3 недели, даёт данные и разгружает очередь.
2. Сценарный бот на самые частые и однозначные темы — 3–4 недели.
3. LLM-ассистент в режиме черновика на остаток простых тем — 4–8 недель с контролем выборки.

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

Что нужно подготовить до запуска бота

Автоматизация поддержки начинается не с выбора платформы, а с данных. Без реальных диалогов бот будет отвечать по общим формулировкам из инструкций вендора, и на третьем-четвёртом вопросе клиент попадёт на оператора. Поэтому первый шаг — выгрузка переписки и звонков за 3–6 месяцев. Меньше трёх месяцев брать смысла нет: не наберётся статистика по редким, но дорогим сценариям — возвратам, претензиям, отказам от услуги. Больше полугода тоже не нужно: часть регламентов устаревает, и вы получите шум.

Выгрузка делается в текстовом виде. Из чатов и мессенджеров — в JSON или CSV с полями: дата, канал, идентификатор клиента, текст сообщения, автор, время ответа оператора. Из звонков — расшифровка в txt или srt с разделением по репликам. Автоматический ASR даёт ошибки порядка 10–15% на именах, адресах и артикулах, поэтому записи, где речь идёт о деньгах и сроках, стоит выборочно прослушать и поправить вручную. Обычно хватает 50–100 диалогов на канал.

Из этой выборки собирается база знаний. Это не только регламенты и скрипты, но и то, что операторы знают, но нигде не записали: условия возврата по категориям товара, сроки гарантии, порядок работы с браком, правила замены, что делать при сбое оплаты. Формат — таблицы и короткие статьи по 150–300 слов на тему, с явными формулировками «если — то». Условия возврата и гарантии лучше вынести отдельным документом с версией и датой: их меняют чаще всего, и бот должен подтягивать актуальную редакцию, а не ту, что была при запуске.

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

Пример из практики: интернет-магазин косметики выгрузил 4 месяца переписки и обнаружил, что 28% обращений — не про товар, а про статус доставки. База знаний по доставке состояла из одной строки «уточняйте у оператора». После того как в неё добавили таблицу сроков по регионам и подключили API перевозчика, доля таких обращений, закрываемых ботом, выросла примерно до 70%.

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

Стоимость и сроки: от пилота до продакшена

Пилот на одном канале — минимальный вход. Один канал (веб-чат или один мессенджер), 30–50 типовых сценариев, база знаний из подготовленных документов, ручная передача оператору по правилам эскалации. Срок — 2–4 недели, из них первая уходит на сборку базы знаний и настройку, вторая-третья на тестовые диалоги и правки. Стоимость от 150 тыс. рублей: настройка платформы, разметка сценариев, интеграция с одной системой — обычно с CRM или helpdesk. Верхняя граница зависит от объёма базы знаний и числа интеграций; при 200+ сценариях и двух-трёх системах пилот легко доходит до 300–400 тыс.

Готовые SaaS-платформы — второй вариант. Подписка 30–80 тыс. рублей в месяц за средний тариф, включающий несколько каналов, конструктор сценариев и базовую аналитику. В эту сумму не входят: работа по наполнению базы знаний (её делают либо ваши сотрудники, либо подрядчик отдельно), интеграции с самописными системами, доработки под нестандартные процессы. На практике первые три месяца подписка почти всегда сопровождается разовыми работами на 100–200 тыс. рублей. Плюс SaaS — запуск за недели и низкий риск: если не подошло, отключаете подписку. Минус — ограничения по логике диалога и привязка к вендору: перенос базы знаний на другую платформу потребует переделки.

Своя разработка с интеграциями — третий вариант. От 1,5 млн рублей и от 3 месяцев до первого продакшена. В эту сумму входят: проектирование диалоговой логики, разработка или дообучение модели, интеграции с CRM, биллингом, складом, телефонией, панель аналитики, тестирование. Срок 3 месяца реалистичен, если у вас есть готовые API и человек, который принимает решения по продукту. Если интеграции идут через legacy-системы без документации, срок удваивается, а бюджет растёт на 40–60%. Отдельная строка расходов — поддержка: 15–25% от стоимости разработки в год на обновление базы знаний, мониторинг качества и доработки.

Что выбрать, зависит от объёма обращений. До 3–5 тыс. диалогов в месяц SaaS почти всегда выгоднее: разработка не окупится. От 10 тыс. и выше, особенно при нестандартных процессах, своя разработка может выйти дешевле за два-три года. Промежуточный вариант — SaaS с кастомными интеграциями через API.

Расклад по бюджетам с учётом скрытых статей — в статье Сколько стоит внедрить ИИ-агента в бизнес в 2026 году. Практическое правило: начинайте с пилота на одном канале, фиксируйте метрики, и только потом решайте, масштабировать SaaS или заказывать разработку. Пилот за 150–200 тыс. рублей дешевле ошибки в выборе платформы на год вперёд.

Интеграции: без них бот бесполезен

Бот, который умеет только отвечать на вопросы из заранее заготовленного списка, разгружает операторов примерно на 10–15% обращений. Всё остальное упирается в данные: клиент спрашивает «где мой заказ», а бот не видит ни номера отправления, ни статуса оплаты. Поэтому объём автоматизации определяется не качеством модели, а количеством систем, к которым она подключена. На практике интеграции делают в три слоя, и каждый решает свою задачу.

CRM. Здесь бот берёт историю клиента: сколько раз обращался, какие продукты покупает, есть ли открытые сделки, к какому сегменту относится и какой у него LTV. Без этого невозможно ни вежливое обращение по имени, ни правильная развилка сценария. Клиент с LTV в 400 тысяч рублей и тремя действующими договорами не должен получать шаблонный ответ уровня «оставьте заявку, мы перезвоним в течение дня» — его обращение уходит на приоритетную линию. Технически это обычно REST-запрос к CRM по номеру телефона или email с кэшированием ответа на 5–15 минут, чтобы не дёргать систему на каждой реплике. Отдельный вопрос — права доступа: бот должен видеть только те поля, которые нужны для ответа, а факт обращения фиксируется в карточке клиента как активность.

Биллинг и склад. Самый частый запрос в поддержку интернет-магазина — «когда придёт», второй — «почему списали дважды». Обе задачи закрываются интеграцией с биллингом (статус платежа, наличие подписки, история списаний) и учётной системой (остатки по конкретному SKU, сроки поставки, статус возврата и номер обратного отправления). Если этих данных нет, бот вынужден переводить на оператора любой вопрос про деньги и доставку — а это, по разным оценкам, от 40 до 60% всего потока. Интеграция здесь сложнее, чем с CRM: у биллинга и склада часто нет удобного API, а статусы в них хранятся в справочниках, которые надо маппить на человеческий язык. «Статус 7» в учётной системе должен превратиться в «посылка на сортировочном центре в Казани, доставка 12–14 марта».

Helpdesk. Третий слой отвечает за то, что происходит после диалога. Бот создаёт тикет, прикладывает к нему транскрипт разговора, прикрепляет собранные данные (номер заказа, описание проблемы, приложенные фото) и ставит нужную очередь и приоритет. Если клиент вернулся через день с той же проблемой, оператор видит всю историю, а не начинает с нуля. Передача контекста при эскалации — самый недооценённый элемент: без неё клиент повторяет проблему дважды, и весь выигрыш от автоматизации съедается раздражением.

Пример из практики: у магазина товаров для дома бот отвечал на 18% обращений, пока не подключили склад. После интеграции со справочником остатков и сроками поставки доля выросла до 46% — почти весь прирост дали запросы «есть ли в наличии» и «когда доставите». Модель не менялась, менялся доступ к данным. Порядок подключения обычно такой: сначала CRM (даёт персонализацию и маршрутизацию), затем helpdesk (снимает ручную рутину с операторов), потом биллинг и склад (самые дорогие и самые ценные). Если бюджет ограничен, начинать стоит с CRM — общий план первого запуска разобран в материале ИИ-агент для малого бизнеса: практический план первого запуска.

Метрики: что считать до и после внедрения

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

Доля обращений, закрытых без оператора (containment rate). Формула простая: число диалогов, где бот дал финальный ответ и клиент не запросил человека, делить на общее число диалогов, попавших к боту. Считать надо именно завершённые диалоги, а не сообщения. Тонкость в том, что клиент может уйти из чата молча — и это не значит, что проблема решена. Поэтому containment считают вместе с повторными обращениями: если через сутки тот же клиент пишет снова по той же теме, первый диалог считается незакрытым. По опыту проектов, реалистичный containment для первого месяца работы — 25–35%, для зрелого бота с подключёнными системами — 50–65%. Цифры выше 80% обычно означают, что в знаменатель не попали сложные обращения, которые бот сразу переводит на людей.

Первый ответ и полное решение. Здесь важна медиана, а не среднее. Среднее время ответа ломается от одного-двух аномальных тикетов: клиент написал в пятницу вечером, оператор ответил в понедельник — и среднее улетело. Медиана показывает типичный опыт. Первый ответ для бота измеряется в секундах (обычно 2–10 секунд до первой осмысленной реплики), для оператора — в минутах или часах, и эти два показателя нельзя складывать в одну цифру. Полное решение (time to resolution) считается от первого сообщения клиента до момента, когда вопрос действительно закрыт, включая время на эскалацию. Отдельно стоит смотреть распределение: если 80% диалогов закрываются за 5 минут, а 5% висят по три дня, проблема не в среднем, а в конкретном сценарии эскалации.

CSAT по диалогам с ботом — отдельно от диалогов с людьми. Смешанная оценка бесполезна: она не показывает ни качество бота, ни качество операторов. Оценку собирают после закрытия диалога, и в идеале — с привязкой к тому, кто именно закрыл обращение. Разрыв между CSAT бота и CSAT людей в норме составляет 0,3–0,7 балла по пятибалльной шкале не в пользу бота; если разрыв больше, стоит пересмотреть сценарии, где бот упирается в тупик вместо эскалации. Ещё одна метрика, которую редко считают, но которая многое объясняет, — доля диалогов, где клиент после ответа бота сразу попросил оператора. Это прямой индикатор неудачных сценариев, и работать с ним проще, чем с общим CSAT: видно конкретные темы, где бот не справляется. Стоимость владения этими метриками тоже стоит держать в голове — она зависит от объёма интеграций и разобрана в статье Сколько стоит внедрить ИИ-агента в бизнес в 2026 году.

Где ИИ ошибается и как это ограничить

Первая категория ошибок — выдуманные факты. Модель уверенно называет срок возврата 14 дней, хотя в регламенте 10, или обещает бесплатную доставку при заказе от 3000 рублей, которой в тарифах нет. Причина не в «глупости» модели, а в том, что она достраивает ответ по вероятности, а не по документу. Лечится это ограничением пространства ответов: в системный промпт явно выносится список тем, по которым ассистент отвечает только цитатой из базы знаний, и правило «если в базе нет пункта — передай оператору». Отдельно прописывается запрет на любые числа, которых нет в источнике: сроки, проценты, суммы, номера статей. Хорошая практика — хранить версию регламента рядом с промптом и поднимать её при каждом изменении условий, иначе ассистент месяц будет отвечать по старой редакции.

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

Третья ошибка — молчаливый сбой. Ассистент формально работает, отвечает, но качество упало: после обновления базы знаний он перестал находить раздел про гарантии и начал отправлять всех к оператору. Без метрик это замечают через две недели по жалобам. Нужны алерты на три величины: доля эскалаций на оператора (рост на 10–15% за сутки — сигнал), доля ответов с низкой оценкой клиента, доля диалогов, где ассистент дважды переспросил одно и то же. Порог задаётся по вашей базовой линии за первую неделю, а не по отраслевым цифрам из отчётов.

Пример из практики: у интернет-магазина техники ассистент после подключения нового раздела про рассрочку начал обещать «0% на 12 месяцев» всем подряд, включая клиентов с уже просроченной оплатой. Поймали не по жалобе, а по алерту: конверсия в заявку выросла вдвое за день, что для этого канала нетипично. Проверили выборку из 50 диалогов — 31 ответ содержал неверные условия. Откатили версию базы знаний, добавили правило сверки с CRM перед любым ответом про финансовые условия.

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

План внедрения на 8 недель

Сроки реальны для компании с одним-двумя каналами поддержки и командой из 3–10 операторов. Если каналов больше или база знаний разрознена по пяти системам, добавляйте неделю на аудит — это честнее, чем сдвигать пилот.

Недели 1–2. Аудит обращений и выбор сценариев. Выгружаете историю за 3–6 месяцев из всех каналов: чат на сайте, мессенджеры, почта, телефония. Считаете распределение по темам и по доле обращений, которые оператор закрывает без привлечения других отделов. Задача — выбрать топ-20 сценариев, которые вместе дают порядка 60–70% объёма. Обычно это статус заказа, условия возврата и обмена, график работы и адреса, инструкции по использованию, типовые проблемы с оплатой. По каждому сценарию фиксируете: источник истины (какая система или документ), граничные случаи, куда эскалировать. На выходе — таблица сценариев с ответственными и список того, что в пилот не берём. Роли: руководитель поддержки ведёт аудит, аналитик считает распределение, владельцы процессов подтверждают источники данных.

Недели 3–5. Пилот на одном канале с ручной проверкой. Выбираете канал с наименьшей ценой ошибки — обычно веб-чат, не почта и не телефон. Ассистент отвечает в теневом режиме или на ограниченной доле трафика, 20–30%. Каждый ответ первые дни просматривает оператор: не отправляет клиенту, а сверяет с регламентом и ставит метку «верно / неверно / неполно». Достаточно 100–150 диалогов, чтобы увидеть системные провалы. Правки в промпт и базу знаний вносятся раз в день, не в реальном времени — иначе не поймёте, что именно помогло. К концу третьей недели доля верных ответов по выбранным сценариям обычно доходит до 80–85%, и можно включать прямую отправку клиенту с кнопкой «позвать оператора». Стоимость такого пилота зависит от объёма и модели — ориентиры есть в разборе сколько стоит внедрить ИИ-агента в бизнес.

Недели 6–8. Расширение, обучение операторов, регламент правок. Подключаете остальные каналы по одному, с интервалом в 3–4 дня, чтобы видеть эффект каждого. Операторов учите не «следить за ботом», а работать с эскалациями: как читать контекст диалога, что проверять перед ответом, как помечать ошибки. Роль меняется — часть времени уходит на разметку и правки, это нужно заложить в нагрузку. Одновременно пишете регламент правок: кто может менять промпт, кто утверждает новую версию базы знаний, как быстро откатывается изменение, где хранится история версий. Минимальный набор — журнал изменений, ответственный за базу знаний, правило «правка в продакшене только после проверки на 20 тестовых диалогах».

Контрольная точка на конец восьмой недели: доля обращений, закрытых без оператора, по пилотным сценариям; доля ошибочных ответов по выборке; среднее время ответа; число эскалаций на 100 диалогов. Если ошибочных больше 5%, расширение останавливают и возвращаются к доработке базы знаний — это нормальный сценарий, а не провал проекта.

Автор: Сергей Езепенко, основатель «Системы Поток». Работаю с клиентами с 2018 года, 20 запущенных проектов: стройка, медицина, юруслуги, недвижимость, онлайн-школы.