Первая линия поддержки почти везде устроена одинаково: большая часть обращений типовая, ответы на них где-то записаны, но операторы отвечают по-разному. Один помнит новый регламент возвратов, другой — старый. Клиент получает два разных ответа на один вопрос и пишет третий раз.
Отсюда желание поставить ИИ-агента для поддержки клиентов. Но у такой затеи есть очевидный риск: языковая модель умеет писать убедительно и тогда, когда не знает ответа. Для компании это хуже, чем промолчать: неверное обещание клиенту потом приходится выполнять или оспаривать.
Чем ИИ-агент отличается от чат-бота по сценариям
Классический чат-бот устроен как дерево кнопок и заготовленных фраз. Он предсказуем, но ломается на первом вопросе, которого нет в дереве, и клиент быстро учится писать «оператор».
Языковая модель понимает вопрос, заданный своими словами. Но сама по себе она отвечает «из общих знаний», и в этом главный риск. Сроки возврата, условия тарифа и список документов должны браться из регламентов компании, а без них модель выдаст правдоподобную догадку.
Поэтому цифровой сотрудник отвечает только по подтверждённым источникам компании и показывает, на какой из них опирается. Если источника нет, он не отвечает сам и передаёт обращение человеку.
Как устроен чат-бот по базе знаний с источником
Путь одного обращения выглядит так:
- Обращение приходит из канала: чат на сайте, мессенджер, почта или форма в личном кабинете. Канал остаётся вашим.
- Сотрудник ищет ответ в подтверждённых источниках, то есть в тех разделах базы знаний, которые открыты для ответов клиентам.
- Если источник найден, клиент получает ответ со ссылкой на него.
- Если источника нет, обращение сразу уходит оператору.
- Если клиент не подтвердил ответ, например переспросил или пожаловался, обращение тоже уходит оператору.
Подтверждёнными источниками считаются выбранные разделы базы знаний. Индексация идёт по расписанию, у каждого источника есть отметка об актуальности. Править базу знаний могут только сотрудники компании, поэтому цифровой сотрудник не может подогнать регламент под свой ответ.
Условный пример. Клиент пишет: «Можно вернуть товар без чека?» Сотрудник находит пункт регламента возвратов, отвечает своими словами и прикладывает ссылку на этот пункт. Если в регламенте про чек ничего не сказано, он ничего не додумывает и передаёт обращение оператору.
Зачем ответу ссылка на источник
Клиент по ссылке видит, на чём основан ответ. Оператор, получив обращение, за секунды проверяет, на что опирался сотрудник. Компания может проверить любой ответ задним числом: в журнале решений записано, по какому источнику ответили и что именно.
Когда приходит жалоба, журнал показывает, где ошибка: неверно понят вопрос или устарел сам источник. Второе случается чаще, чем кажется, и без ссылок его не видно. Ответственность разделена так: за содержание базы знаний отвечает компания, а платформа отвечает за то, что сотрудник пользуется только ею и показывает основание.
Когда обращение уходит к человеку
Передача оператору входит в обычную работу системы. Её правила записываются заранее и видны в полномочиях сотрудника. Обращение уходит к человеку в таких случаях:
- Подтверждённого источника нет.
- Клиент не подтвердил ответ, переспросил или пожаловался.
- Обращение спорное, это жалоба или клиенту нужно что-то пообещать вне регламента. Такие обращения ведёт только человек.
- Нужно действие во внутренних системах: возврат, смена тарифа, изменение данных клиента. Сотрудник готовит его, а выполняет только после подтверждения оператора.
Оператор получает обращение вместе с историей, найденными источниками и черновиком ответа. Переспрашивать клиента «уточните, пожалуйста, ваш вопрос» не нужно, вся переписка уже на экране.
Что считать обращением, закрытым без оператора
Это главный показатель, и правило его подсчёта согласуют до запуска. Обращение считается закрытым без оператора, только если клиент подтвердил ответ. Если клиент переспросил, пожаловался или ушёл к оператору, обращение не засчитывается.
Строгое правило кажется невыгодным, но без него показатель растёт за счёт клиентов, которые просто бросили диалог. Такая цифра хорошо выглядит в отчёте, но о качестве поддержки ничего не говорит.
Когда база знаний не готова
ИИ-агент не исправляет базу знаний, но быстро показывает, где в ней пробелы. Признаки того, что начинать стоит с источников:
- Два регламента противоречат друг другу, и операторы знают, какой «на самом деле» действует.
- Ответы на частые вопросы живут в головах старших операторов и в личной переписке.
- У раздела базы знаний нет владельца, который отвечает за его актуальность.
Откладывать запуск из-за этого не нужно. За первые недели передачи оператору с причиной «нет источника» складываются в список пробелов базы знаний с темами и примерами обращений. Руководителю поддержки такой список полезен сам по себе.
Типичные ошибки при запуске ИИ-агента в поддержке
- Открыть для ответов всю базу знаний сразу, включая черновики и внутренние инструкции для сотрудников.
- Считать успех по отчёту самой системы о «закрытых диалогах», а не по подтверждению клиента.
- Не назначить человека, который разбирает передачи оператору и правит источники по их итогам.
- Подключить все каналы и все тематики одновременно — тогда непонятно, что именно сработало, а что нет.
Все четыре ошибки лечатся одинаково: начать с одной тематики в одном-двух каналах, назначить владельца источников и договориться о правиле подсчёта до запуска.
Что понадобится от компании
- Регламенты ответов и правила эскалации.
- Примеры обращений за месяц с разметкой тем.
- Объём обращений по каналам за месяц.
- Перечень источников знаний, по которым разрешено отвечать.
- Подключение к вашему helpdesk или CRM: чтение карточки и истории, запись ответа и статуса в согласованных очередях.
Обращения, база знаний и журнал хранятся в вашем контуре. Поставщик заходит в контур только по регламенту компании и с её ведома. Постоянного доступа у него нет.
Как проверить на своих обращениях
Beseda AI работает как пилотное решение. Каналы, границы полномочий и схема обращения описаны на странице продукта в разделе «Направления». Публичной цены нет: она зависит от каналов, объёма и источников знаний и считается после аудита сценария.
Проверяют решение на платном пилоте по одной тематике обращений. Срок пилота и недели замеров записываем в план после аудита сценария: сначала базовый замер, в конце повторный, разницу записываем в акт сравнения. Показатели пилота: доля обращений, закрытых без оператора, время первого ответа, стоимость обращения и доля корректных передач оператору.
Людей сотрудник не заменяет: решения принимает и подписывает человек. Он отвечает на типовые обращения, а спорные и нетиповые передаёт оператору вместе с историей и черновиком. Как менять работу первой линии по итогам пилота, решаете вы.