Готовые хелпдески с ИИ закрывают обращения, ответ на которые уже написан у вас в документах: условия доставки, режим работы, порядок возврата, инструкция по настройке. Всё, где ответ зависит от данных в ваших системах - статус конкретного заказа, остаток по счёту, срок по конкретному договору, - остаётся за пределами коробки. Она работает с текстом, а не с вашими данными.
Поэтому доля обращений, которые уйдут без человека, определяется не качеством модели, а тем, как устроены обращения именно у вас. Дальше - способ посчитать эту долю по своей выгрузке за месяц, разбор того, что делать с остатком, и правила, без которых автоматизация первой линии портит отношения с клиентами быстрее, чем экономит деньги.
Что уже умеет готовое решение
Класс решений устроен примерно одинаково, разница между платформами меньше, чем кажется из их лендингов. Четыре функции есть почти у всех.
Ответ из базы знаний. Система ищет по загруженным документам и отвечает своими словами со ссылкой на источник. Основная работа разговорного искусственного интеллекта в поддержке и та часть, ради которой коробку покупают.
Классификация и маршрутизация. Обращение размечается по теме, тональности и срочности и уходит нужной группе. Работает независимо от того, отвечает бот клиенту или нет: даже при полностью человеческой первой линии разбор потока экономит время.
Подсказки оператору. Человек ведёт диалог, система ищет по документам и предлагает вариант ответа, оператор правит и отправляет. Самый недооценённый режим: обещаний меньше, риска почти нет.
Сводка по обращению. Диалог сворачивается в короткую запись для тикета, чтобы следующий человек не перечитывал переписку.
Имена, которые вы увидите в поиске по теме: AutoFAQ, HelpDeskEddy, SimpleOne, Naumen, Jivo. Сравнивать их здесь я не буду - чтобы честно сравнивать платформы, надо каждую внедрить, а внедрял я не их. Экзотикой это давно не выглядит: по данным Intercom, приведённым в блоге Yandex Cloud в 2025 году, нейросети используют 45% служб поддержки.
Чат-бот с ИИ - инструмент, и про него у меня написано отдельно, где хватит чат-бота с ИИ для бизнеса. Здесь речь про сценарий, про первую линию как процесс.
Где готового решения не хватает
Ответ зависит от данных, а не от текста
«Где мой заказ», «сколько осталось по договору», «когда спишется платёж» - ответа на них нет ни в одном документе. Он лежит в CRM, в учётной системе, в биллинге. Модель здесь почти не нужна: нужен доступ к системе-источнику и аккуратный запрос к ней, модель только оформляет результат в человеческую фразу.
Языковые модели хорошо угадывают по названию и плохо знают то, что известно только вам: какая из двух одинаковых записей относится к этому клиенту, из текста не выводится никогда. Без доступа к данным система выдаёт правдоподобную догадку, и это худший исход из возможных.
Источников несколько, и они спорят между собой
CRM говорит, что заказ отгружен, склад - что лежит на полке, письмо клиента - что пришло не то. Пока источник один, всё просто. Когда их три, кто-то должен решить, чьи данные главные. Это решение принимается на уровне архитектуры, а не подбором формулировок в промпте, и в коробке его нет.
Обращение требует действия, а не ответа
Отменить, вернуть, продлить, выставить счёт, перенести дату. Тут заканчивается разговор и начинается работа с вашими системами. Правило одно: опасные действия недоступны модели по архитектуре, а не по инструкции в промпте. Возврат денег виртуальный ассистент не делает - он готовит его и ставит в очередь на подтверждение. Первый месяц подтверждается каждое действие, дальше подтверждение снимается с операций, где ошибок не осталось.
Каналов больше, чем один
Почта, мессенджеры, форма на сайте, телефон. Один клиент пишет во все четыре и ждёт, что его помнят. Это задача обвязки: единая карточка обращения, история, дедупликация. К качеству модели она отношения не имеет, но именно она решает, выглядит ли система работающей.
Как посчитать свою долю до покупки
Цифра «до 80-90% типовых вопросов без участия человека» ходит по вендорским блогам и попадает в ИИ-обзор Google по запросу «ии для поддержки клиентов» (снимок 2026-08-04). Она не врёт, но считает долю от типовых вопросов, а не от всех обращений. Сколько обращений типовые у вас, не знает ни один вендор - это свойство вашего бизнеса, а не его платформы.
Счёт занимает вечер. Выгрузите обращения за месяц, все каналы разом. Возьмите случайные сто штук и разложите по категориям: ответ есть в документе, ответ в системе, нужно действие, спорят источники, нестандарт. Доля первой категории и есть то, что закроет готовое решение, остальное - объём работы, которая коробкой не закрывается.
| Тип обращения | Пример | Чем закрывается | Что для этого нужно |
|---|---|---|---|
| Ответ есть в документе | «Какие сроки доставки в регионы» | Готовым хелпдеском с ИИ | Актуальная база знаний и её владелец |
| Ответ в системе-источнике | «Где мой заказ №1841» | Ассистентом с доступом к данным | Интеграция с CRM или учётной системой, права на чтение |
| Нужно действие в системе | «Отмените заказ и верните деньги» | Ассистентом с очередью подтверждения | Человек в контуре, лимиты и запреты в коде |
| Несколько источников спорят | «В счёте одна сумма, в письме другая» | Не закрывается автоматикой | Правило приоритета источников, решение человека |
| Нестандарт и конфликт | «Второй раз одно и то же, дайте руководителя» | Только человеком | Быстрый выход на живого сотрудника |
| Обращение с персональными данными | «Приложил паспорт и договор» | Отдельным контуром | Согласия, хранение, обезличивание |
Последняя строка выносится отдельно: обращения с документами клиента попадают под требования 152-ФЗ, и решать этот вопрос надо до запуска, а не после первой жалобы.
У счёта есть побочный результат. Обычно выясняется, что заметная часть потока - это пять вопросов, на которые в компании нет нормально написанного ответа. Половина из них закрывается страницей в базе знаний без всякого ИИ, и это самая дешёвая автоматизация из существующих.
Что делать с обращениями, которые остались
Остаток делится на три части, и работать с ними надо по-разному.
Первая закрывается регламентом и текстом. Вопрос повторяется, ответ есть, но он живёт в голове старшего оператора. Его надо записать - и обращение переезжает в первую категорию.
Вторая требует доступа к вашим системам. Это уже разработка ассистента на заказ: нужны интеграции, права, правила приоритета источников и очередь подтверждения. Коробка сюда не дотягивается по устройству, а не по цене.
Третья остаётся людям навсегда. Конфликт, нестандартная договорённость, клиент на грани ухода - здесь человек единственный правильный ответ, а не временная мера до следующей версии системы. Автоматика в первой линии нужна ровно для того, чтобы такие разговоры доходили до людей быстрее, а не тонули в потоке вопросов про режим работы.
Как не испортить отношения с клиентами
Репутацию категории испортили не нейросети, а голосовые меню предыдущего поколения: они гоняли человека по кругу, пока он не бросал трубку. Память об этом переносится на любого бота. В обсуждениях владельцев малого бизнеса это звучит буквально так: услышал робота - бросил трубку и позвонил другим, а каждая брошенная трубка это потерянный заказ. Из той же серии история про десять часов переписки с ботом поставщика ради письма от живого человека.
Три правила снимают почти весь риск.
Выход на человека виден всегда и работает с первого раза. Не после трёх уточняющих вопросов и не в будни с девяти до шести. Кнопка или фраза «оператор» - и обращение уходит человеку вместе со всей перепиской.
Система говорит «не знаю» вместо правдоподобного ответа. Право промолчать закладывается раньше, чем вопрос «что ответит модель»: сначала обращение классифицируется, и только потом решается, отвечать ли автоматом вообще.
Очередь к человеку принимает отказ, а не роняет обращение. Не ответила интеграция с трёх попыток - обращение уходит в человеческую очередь, а не исчезает с формулировкой «что-то пошло не так».
Как это измерять
Общая доля автоответов - плохая метрика: она растёт, когда система начинает отвечать на всё подряд, в том числе неправильно.
| Метрика | Как считать | Что она скрывает |
|---|---|---|
| Доля закрытых без человека | По каждой категории из разбора отдельно, а не в целом | Общая цифра растёт за счёт лёгкой категории и маскирует провал на сложной |
| Повторные обращения по тому же вопросу | Сколько клиентов вернулись с тем же вопросом за неделю | Формально закрытый диалог, после которого клиент пошёл писать снова |
| Шагов до человека | Медиана числа реплик до передачи оператору | Среднее прячет хвост из тех, кто не дошёл никогда |
| Стоимость решённого обращения | Расходы на канал делить на число решённых, а не обработанных | Обработанных всегда больше; считать надо стоимость результата, а не стоимость запроса |
| Доля обращений, где бот ответил неверно | Ручная выборка полусотни диалогов в неделю | Автоматических метрик качества ответа не существует, выборку читает человек |
Мерить надо исход, а не активность. Система обрабатывает вдвое больше диалогов и при этом не решает ни одной задачи клиента - такое бывает и выглядит в отчёте прекрасно.
Клиентская поддержка и внутренняя техподдержка - разные задачи
Их считают одним и тем же, потому что механика похожа: классификация, маршрутизация, ответ из базы знаний. Отличается всё остальное.
Заявка приходит от сотрудника, а не от клиента. Сотрудник никуда не уйдёт, но и терпит меньше: у него горит работа. Цена ошибки другая - неверный ответ клиенту стоит репутации, неверный ответ по внутренней системе может остановить отдел.
Главное отличие в том, чем заканчивается заявка. Внутренняя поддержка закрывает большую часть обращений действием в инфраструктуре: выдать права, сбросить пароль, поднять сервис. Это операция с правами доступа, а не разговор, и требования к контуру здесь жёстче.
Видно это и по тому, кто отвечает на запрос «автоматизация техподдержки с помощью ИИ»: разборы маршрутизации обращений в ИТ-службе крупного производства, ITSM-платформы, RPA-подрядчики. Другая аудитория и другой бюджет. Метод разбора обращений работает и там, меняются категории и стоимость ошибки.
Что ломается со временем
Ответы первой линии берутся из ваших документов - механика называется генерацией с дополненной выборкой, и её качество равно качеству документов. База знаний зарастает мусором, если её никто не чистит: старые инструкции, отменённые условия, три версии одного регламента. Через полгода система начинает уверенно отвечать по прошлогодним правилам, и это хуже отсутствия системы, потому что ей верят. У базы знаний нужен владелец, а не общая ответственность отдела; как это устроить, разобрано в материале про корпоративную базу знаний.
Вторыми портятся правила, написанные против ошибок модели. Их накапливают в первые месяцы и потом не пересматривают, хотя половина уже не нужна: изменились данные, изменилась модель. Раз в полгода набор стоит перечитывать и выбрасывать мёртвое.
Третьим уезжает процесс. Первая линия - часть общей автоматизации бизнес-процессов с ИИ, а там появляются новые тарифы, отдел переезжает в другую систему, переписывается порядок возврата. Система при этом работает без ошибок и просто отвечает невпопад.
Частые вопросы
Сколько обращений реально закроется без человека?
Заранее этого не знает никто, включая вендоров: у них своя средняя по клиентам, а не ваша. Цифра «до 80-90%» относится к типовым вопросам, а не ко всем обращениям, и вопрос ровно в том, какая доля ваших обращений типовая. Считается по выгрузке за месяц: сто случайных обращений, пять категорий, доля первой и есть то, что закроет готовое решение.
Что будет, если бот ответит клиенту неправильно?
Зависит от того, что ему разрешено. При правильном устройстве ответ идёт со ссылкой на документ, из которого взят, система отказывается отвечать вместо того, чтобы догадываться, а действия с деньгами и заказами проходят через подтверждение человека. Тогда цена ошибки - одно уточнение в диалоге. Если модели дали право действовать самой, цена ошибки равна стоимости действия.
Клиенты не разозлятся, что с ними говорит робот?
Злит не робот, а невозможность дойти до человека. Люди спокойно пишут в чат, если знают, что за две реплики попадут к сотруднику. Правило одно: выход на оператора виден всегда и срабатывает с первого раза, вместе со всей историей переписки. Нарушьте его - и получите репутацию голосовых меню, из-за которых клиенты бросают трубку и звонят конкурентам.
Чем это отличается от чат-бота, который нам уже предлагали?
Разница не в технологии, а в том, откуда берётся ответ. Сценарный бот идёт по дереву вопросов, которое кто-то нарисовал заранее. Решение с ИИ отвечает по вашим документам, а ассистент с доступом к системам - ещё и по вашим данным. Где какого инструмента хватает, разобрано на отдельной странице про чат-бота с ИИ для бизнеса.
У нас внутренняя техподдержка, а не клиентская. Это то же самое?
Наполовину. Классификация, маршрутизация и ответ из базы знаний работают одинаково. Дальше расходится: заявка приходит от сотрудника, часть заявок закрывается не ответом, а действием в инфраструктуре, и требования к правам доступа жёстче. Метод разбора обращений применим целиком, категории и стоимость ошибки - свои.
Нужно ли это, если у нас двадцать обращений в неделю?
Скорее нет, и порог не в количестве. Двадцать обращений, которые сводятся к двум вопросам, - повод написать нормальную страницу с ответами, а не покупать платформу. Двадцать разных обращений автоматика не закроет: учиться ей не на чем, каждый случай всё равно разбирает человек. Смысл появляется там, где поток повторяется изо дня в день.
Что дальше
Разбор ста обращений можно сделать самому: метод выше полный, скрытого в нём ничего нет. Если хотите проверить свою раскладку и понять, где проходит граница между «настроить готовое» и «делать под себя», приходите на бесплатный разбор: тридцать минут, смотрим ваш поток обращений, называю, где ИИ даст результат, а где не нужен.
Написать можно в Telegram или на почту hi@za-ai.ru.