ИИ в поддержке клиентов: что работает, а что вредит

Короткий ответ: в поддержке есть три разных режима, и путать их дорого.

• Подсказка оператору. Модель находит ответ в базе, оператор видит его рядом с обращением и решает сам.
• Черновик ответа. Модель пишет текст, оператор правит и отправляет.
• Автоответ. Модель отвечает клиенту сама.

Начинать надо с первого. Автоответ — последний по порядку и первый по цене ошибки, а внедряют его обычно первым, потому что он эффектнее всех выглядит на демонстрации.

Почему подсказка первая

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

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

Она вскрывает главное. Через две недели становится ясно, что половина промахов — не про модель: ответа просто нет в базе, или он есть в трёх местах и версии противоречат друг другу.

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

Что обязательно в любом режиме

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

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

Нарезка базы по структуре. Я измерял на своём корпусе: при фиксированной нарезке 95% смысловых разделов разрезаны между кусками — и ответ собирается из половины правила. Числа здесь.

Набор из реальных обращений. Двадцати хватает, если сравнивать парно — те же обращения до и после правки. Почему именно так.

Признак готовности к автоответу

Не «модель хорошо отвечает», а три измеримых условия одновременно.

Есть класс обращений, где ответ однозначен. Статус заказа, часы работы, условия возврата. Не «простые вопросы вообще», а перечисленный список тем.

Модель уверенно отличает свой класс от чужого. Проверяется на обращениях, которые в класс не входят: она должна передавать их человеку, а не отвечать похоже.

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

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

Про персональные данные

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

Практическая граница: обезличивать до отправки. Сущности заменяются метками, после ответа подставляются обратно. Модели для разбора текста конкретное имя почти никогда не нужно — подробнее об этом.

Решение принимается на этапе постановки. То же решение после запуска — это переделка контура.

Условие несогласия

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

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

Чего я делать не стал бы

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

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

Не стал бы прятать, что отвечает машина. Клиент почти всегда понимает, а обнаружив обман, перестаёт верить и живому оператору тоже.

Открытый вопрос

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

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