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