Разработка

AI в поддержке клиентов: где помогает, где мешает

Языковая модель отвечает уверенно даже когда ошибается. Разбираем, где AI в поддержке полезен, что нужно подготовить заранее и что ему нельзя доверять.

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

Два способа применения, и они не равнозначны

AI как первая линия. Модель отвечает клиенту напрямую. Быстро, круглосуточно, снимает поток однотипных вопросов. Здесь же и весь риск: каждый ответ уходит наружу, и никто его не проверял.

AI как подсказка оператору. Модель читает обращение, находит подходящие куски из базы знаний, предлагает черновик ответа. Оператор правит и отправляет. Экономия времени меньше, чем в первом варианте, но ошибка не покидает компанию.

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

Главный риск: уверенно и неправильно

Языковая модель порождает правдоподобный текст. Правдоподобие и правда совпадают часто, но не всегда, и по форме ответа различить их невозможно: неверный ответ выглядит ровно так же, как верный — так же спокойно и тем же тоном.

Для поддержки это означает конкретные вещи:

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

Обещание, выданное ботом, клиент воспринимает как обещание компании. Спорить с этим бесполезно, и по-человечески он прав.

Практический вывод: снижать риск нужно не уговорами модели быть аккуратнее, а устройством системы. Ответ строится только на найденных фрагментах вашей базы; если ничего подходящего не нашлось — ответа нет, есть переход к человеку. Это заметно скучнее, чем свободный диалог, и заметно безопаснее.

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

Качество ответов определяется не выбором модели, а тем, из чего она отвечает. Подготовка базы знаний — основная работа проекта, и заказчик её обычно недооценивает.

  1. Соберите источники. Регламенты, ответы поддержки за прошлый период, описания продуктов, условия, инструкции. Всё, что реально используется, а не то, что когда-то написали.
  2. Вычистите противоречия. Если в двух документах разные условия возврата, модель выберет одно, и не обязательно верное. Противоречия нужно снять до, а не после.
  3. Разбейте на самостоятельные куски. Фрагмент должен быть понятен без остального документа. Ссылки вида «см. раздел выше» при поиске по кускам не работают.
  4. Назначьте владельца. У каждого раздела базы есть человек, который обновляет его при изменениях. База знаний без владельца устаревает за несколько месяцев и начинает вредить.
  5. Отделите публичное от внутреннего. Внутренние комментарии, закупочные цены, инструкции по исключениям для VIP-клиентов не должны попадать в тот набор, из которого формируется ответ клиенту.
  6. Подключите живые данные отдельно. Статус заказа, остаток на счету, дата записи — это не база знаний, это запрос в систему. Модель не должна угадывать такие вещи, она должна вызывать функцию и пересказывать результат.

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

Переход на человека — обязательная часть

Это не запасной выход, а штатный элемент сценария. Проектируется он заранее и по правилам.

Передавать диалог человеку нужно:

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

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

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

Что нельзя доверять модели

Есть решения, которые не отдаются автоматике, даже если технически это возможно.

  • Финансовые операции. Возвраты, скидки, списания, изменение тарифа. Модель может подготовить заявку, решение принимает человек.
  • Юридически значимые формулировки. Ответы по договору, гарантийным обязательствам, персональным данным. Здесь нужен готовый утверждённый текст, а не пересказ.
  • Медицинские и правовые рекомендации. Ответ должен быть маршрутом к специалисту, а не советом.
  • Индивидуальные исключения. «Вам, так и быть, сделаем» — это управленческое решение.
  • Работу с персональными данными без проверки личности. Прежде чем сказать что-либо о заказе, система должна знать, что говорит с его владельцем. Это отдельная механика, а не догадка по имени в чате.

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

Как измерять, работает ли это

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

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

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

Практический порядок действий

  1. Начните с подсказки оператору, а не с автономных ответов клиентам.
  2. Соберите и вычистите базу знаний. Это основная часть работы; заложите на неё время людей из компании, а не только разработчиков.
  3. Настройте ответы строго по найденным фрагментам, с отказом отвечать при отсутствии источника.
  4. Подключите живые данные через вызовы к вашим системам, а не через пересказ.
  5. Опишите правила передачи оператору и проверьте, что диалог передаётся целиком.
  6. Составьте список тем, запрещённых для автоматического ответа, и проверьте его на реальных обращениях.
  7. Через несколько недель работы переведите в автономный режим только те темы, где черновики уходили без правок.

Такой порядок медленнее, чем «подключить модель к чату за неделю», но он не создаёт обязательств, которые потом придётся выполнять. Если нужно разобрать вашу ситуацию предметно — напишите нам.