"ИИ в поддержке: что можно отдать боту и что должен дочитывать человек"

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

Крупные платформы описывают это по-разному, но каркас один. Zendesk пишет, что его ИИ-агенты работают в мессенджерах, почте, веб-формах и голосовом канале и могут выполнять действия в разрешённых системах. Чем агент отличается от обычного чат-бота, объясняет статья что такое ИИ-агент. Fin в Intercom опирается на базу знаний: публичные статьи, внутренние заметки, документы и импортированные источники. Salesforce в Agentforce для сервиса сочетает автономного агента для типовых обращений с передачей диалога оператору вместе с контекстом.

Что это значит на практике, если убрать догадки. В маленькой команде бот снимает ночные вопросы «где посылка» и «как войти». В регулируемых отраслях бот не должен обещать срок лечения или одобрение кредита. В технической поддержке он годится для первого фильтра по дереву симптомов, если дерево актуально и коротко.

Список один и тот же на конференциях и в коммерческих презентациях.

• Полная замена первой линии. На деле получается фильтр: часть обращений закрывается статьёй, часть всё равно попадает в очередь. Zendesk даже считает работу агента только по тем диалогам, которые решены без передачи человеку.
• Понимание любого текста. Модель правда удерживает разговор и задаёт уточняющие вопросы. Однако без настроенных сценариев агент Zendesk отвечает лишь по подключённым источникам знаний, без процедур и диалоговых веток.
• Мгновенное обновление знаний. У Intercom собственные статьи подхватываются почти сразу, а материалы с внешних сайтов обновляются раз в неделю. Неделя со старым ответом на линии — это много.

Общего «процента автоматизации для всех отраслей» здесь не будет. Цифры из маркетинговых материалов без независимого замера в этот текст не попали.

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

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

Плохая идея — отдать боту без доработки базы то, что клиенты спрашивают иначе, чем написано в заголовках статей. Intercom советует писать заголовки языком клиента: «Как сбросить пароль?», а не «Процедура восстановления доступа».

Схема автора, ноябрь 2026. Цифр эффективности на рисунке нет.

Техническая линия: где бот полезен

Чат-бот технической поддержки чаще всего живёт как дерево симптомов плюс ссылки на статьи. «Не включается» → уточнение модели → проверка индикатора → шаги из базы. Здесь бот экономит время, если статьи короткие, с нумерованными шагами и без устаревших снимков экрана. Когда сбой новый и статьи ещё нет, бот начинает импровизировать. Почему модель уверенно сочиняет детали, которых нигде нет, подробно разобрано в статье про выдумки нейросетей.

Оператор нужен там, где ошибка стоит денег, репутации или прав клиента.

• Деньги и компенсации. Полный или частичный возврат, продление подписки вручную, спор по списанию. Бот может собрать данные, но решение и формулировка обещания — за человеком.
• Личные и чувствительные данные. Паспорт, медицинские сведения, детали договора. Какой канал подходит и где хранятся журналы переписки, решаете вы, а не генератор текста.
• Конфликт. Клиент пишет заглавными буквами, грозит оспорить платёж, обещает жалобу в надзорный орган. Здесь нужен живой человек с полномочиями.
• Нестандартный случай. Два аккаунта, странная ошибка после обновления, сбой, которого нет в базе. Microsoft описывает своего помощника для операторов как поиск по базе знаний и SharePoint, а расследование остаётся за человеком.
• Юридически значимые формулировки. «Мы гарантируем», «мы обязаны», «срок по закону». Бот не знает вашей оферты, если вы не вложили её в разрешённые источники и не проверили ответ.

Самый известный пример того, почему обещания нельзя отдавать боту без присмотра, — дело Moffatt против Air Canada. Решение вынес Гражданский трибунал по разрешению споров Британской Колумбии 14 февраля 2024 года.

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

Авиакомпания в споре пыталась сказать, что не отвечает за слова чат-бота. Трибунал назвал этот довод удивительным и указал, что бот — такая же часть сайта, как любая другая страница, и компания отвечает за всю информацию на нём. Ещё одна деталь из решения: авиакомпания не объяснила, почему клиент должен был доверять странице правил больше, чем боту. Air Canada обязали выплатить разницу в цене вместе с процентами и сборами, всего чуть больше 800 канадских долларов.

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

В гайде для бизнеса разобраны шаги для письма и готового ответа: как сформулировать задачу модели и что проверить в тексте. На линии поддержки поверх этого лежит смена — кто в какой момент отвечает за диалог.

Типовой поток выглядит так. На каждом шаге у обращения один владелец: либо бот, либо оператор, без «висящих» диалогов.

1. Клиент пишет в виджет на сайте, мессенджер или почту.
2. Канал решает, идёт ли обращение к боту или сразу в очередь. Ночью и в пик чаще включают бота первым.
3. Бот отвечает из базы знаний или по сценарию. Если срабатывает правило передачи — тема, тон, ключевые слова, неудачная попытка — диалог уходит оператору с историей.
4. Оператор видит, что уже спросили и что предложил бот. Повторять вопросы клиенту не нужно, если система передала контекст. Salesforce отдельно подчёркивает передачу оператору вместе с контекстом разговора.
5. Старший смены или специалист по качеству выборочно читает закрытые ботом диалоги и правит базу, а не только переписку.

Получается распределение внимания, а не волшебная кнопка. Бот снимает однотипные вопросы, оператор держит сложные хвосты, база знаний получает правки после каждого заметного промаха. У Microsoft есть отдельный агент, который из закрытых обращений предлагает черновики статей. В обычном режиме он срабатывает при закрытии обращения или переписки, а исторический прогон обрабатывает до 100 000 записей за раз. Это про наполнение базы, смену он не заменяет.

Приоритеты и нормативы

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

Контроль качества

Раз в неделю достаточно выборки: десять закрытых ботом диалогов и пять переданных. Вопросы простые. Совпал ли ответ со статьёй? Не обещал ли бот лишнего? Вовремя ли отдал диалог человеку? Если ответ неверный, правят статью, а не только «учат бота заново».

Чтобы чек-листы не висели в воздухе, разложу условный пример: клиент пишет «деньги списались дважды, верните». Такие сообщения не закрывают одной статьёй про оплату, даже если статья написана идеально.

Что понадобится до ответа:

• выписка или снимок из личного кабинета банка клиента;
• правила возврата из вашей базы, а не пересказ модели;
• очередь «оплата» с оператором, у которого есть доступ к транзакциям.

Сценарий смены:

1. Бот здоровается и просит номер заказа. Если клиент отказывается, диалог сразу уходит человеку, спорить в боте бессмысленно.
2. Бот проверяет статус заказа, если интеграция есть. Двойное списание бот не подтверждает и не опровергает: он передаёт диалог оператору с пометкой «нужна сверка платежей».
3. Оператор сверяет транзакции и формулирует исход: возврат, отказ со ссылкой на оферту или запрос документов. Срок называет только из регламента, не из головы.
4. После закрытия статья в базе дополняется, если вопрос повторился три раза за неделю.

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

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

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

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

Ответ «модель сама разберётся» на вопрос про возвраты я бы считала красным флагом. Хороший поставщик называет границы, а не процент на слайде. Если в договоре фигурирует «автоматическое решение», попросите расшифровку на одном примере из вашей тематики. Так быстрее видно, входит ли туда возврат или только статус доставки по трек-номеру.

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

Рабочая схема снова скучная:

• Утром десять минут: посмотрите причины передачи за вчера и допишите одну статью под самую частую.
• Черновик статьи можно попросить у модели, но дайте ей только факты от продукта, без сроков «на глаз».
• Раз в неделю делайте выборку для контроля качества.
• Раз в месяц прогоняйте сценарий «клиент просит человека» во всех каналах.

Если команда одна на три канала — сайт, почта, Telegram, — сценарии могут отличаться. Почте нужен номер обращения в теме письма, мессенджеру — короткие реплики, сайту — кнопка «позвать оператора» без лабиринта.

Любой бот поддержки упирается в качество документов. Fin в Intercom различает публичные статьи, внутренние заметки, документы и материалы, импортированные из других систем. У Salesforce база знаний для агента индексируется по технологии поиска с дополнением ответа: модель сначала находит подходящий фрагмент статьи или вложения и только потом пишет ответ. Это снижает риск догадки, но не отменяет его.

Правила, которые реально работают:

• Заголовок — как клиент спрашивает, не как продукт называет раздел.
• Внутри — нумерованные шаги, один сценарий на статью, дата последней проверки в заметке для команды.
• Боту открывайте только те статьи, которые не стыдно показать клиенту без редактора.
• После обновления продукта меняйте снимки экрана и пути в меню, иначе бот уверенно ведёт в старый интерфейс.

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

После крупного обновления продукта имеет смысл неделю держать на линии дополнительного оператора именно на хвостах от бота. Свежие вопросы быстро показывают, какой заголовок в базе устарел, ещё до того как это увидит статистика.

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

Что понадобится:

• два-три абзаца из базы с фактами: срок рассмотрения заявки, список данных для возврата, ограничения;
• текст обращения без лишних личных данных клиента;
• прямой запрет придумывать статус заказа и сроки.

Пример запроса: «Ты помощник оператора поддержки. Используй факты только из текста базы ниже. Если данных не хватает, напиши, что уточнишь у клиента, и ничего не выдумывай. Не называй сроков, которых нет в тексте. Ответ на русском, спокойным тоном, до 120 слов. Текст базы: … Сообщение клиента: …»

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

Для такой работы подойдут, например, Claude Sonnet 5 или Gemini 3.8 Flash — обе модели уже доступны в чате GPThub. Первая обычно аккуратнее с длинными инструкциями, вторая быстрее на коротких ответах. Сравните их на трёх своих типовых обращениях, прежде чем выбрать одну для смены.

Что проверять в черновике:

1. Каждое обещание есть во вложенной базе или учётной системе.
2. Нет новых сроков, сумм и исключений «от себя».
3. Тон совпадает с правилами компании.
4. Есть следующий шаг для клиента: что прислать, куда нажать.
5. Нет личных данных из чужих обращений, если вы вставляли примеры.

Перед отправкой прочитайте ответ вслух. Фраза, на которой спотыкаетесь, часто означает, что клиент тоже споткнётся, а модель такую неловкость прячет за уверенным тоном.

Как формулировать задачу модели подробнее — в гайде по запросам. Как выбрать модель под длинный контекст и аккуратность — в гайде по выбору модели.

Запрос «чат поддержки телеграмм бот» обычно про канал, а не про другой тип бота. Telegram-бот — оболочка: сообщение уходит в ту же платформу, что и виджет на сайте, если интеграция настроена. Риски те же: без базы бот импровизирует, без передачи человеку клиент застревает в цикле «нажмите 1».

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

Отличия канала:

• В Telegram чаще присылают фото и пересланные сообщения. Бот должен уметь принять вложение или сразу передать диалог оператору.
• Переписка в личном чате ощущается личной, жёсткий шаблон раздражает сильнее, чем в почте.
• Быстрого ответа в мессенджере ждут и ночью. Бот снимает пик, но утром очередь оператора всё равно нужна.

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

Если вы давно не открывали настройки, часть старых модулей уже помечена как устаревшая. Zendesk с 11 мая 2026 года считает устаревшим уровень ИИ-агентов Essential, с 31 августа прекратил его развитие и на странице о ИИ-агентах называет датой удаления 10 декабря 2026 года. Старый конструктор ботов и автоответы со ссылками на статьи идут по тому же графику. Переход на новую версию шёл с 11 мая по 12 июня 2026 года: разницу между уровнями Essential и Advanced убрали, более автономные возможности открыли всем.

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

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

• Запуск без передачи человеку. Клиент просит оператора, бот повторяет статью из базы. Итог предсказуем.
• База ради галочки. Длинные PDF без заголовков на языке клиента. Бот хуже находит нужную статью, оператор всё равно чинит вручную.
• Обещание статуса без интеграции. Бот называет дату доставки, которой нет в учётной системе.
• Отправка без сверки. Оператор отправляет черновик модели, не сверив его с правилами возврата.
• Один показатель «автоматизация». Давление на процент закрытий ботом приводит к отказам в передаче там, где она нужна.

Уберёт ли этот список все провалы, честно, пока не знаю. Он ловит то, что чаще всего всплывает на первой линии.