Одна из типичных проблем сервисного бота возникает в точке неопределённости: сценарий закончился, запрос сформулирован нестандартно или клиент просит оператора. Самый безопасный вариант для классического бота — передать диалог человеку.
Для бизнеса это означает, что значительная часть обращений всё равно попадает в контакт-центр, даже когда вопрос потенциально можно решить автоматически. Поэтому одной из задач проекта стало изменение самой логики работы с такими обращениями: не переводить клиента на оператора там, где бот ещё способен помочь.
Мы переработали механику перевода на оператора и сбора обратной связи. Вместо механического завершения сценария бот получил возможность точнее определять, можно ли продолжить обслуживание автоматически — это заложило основу для дальнейшего роста автоматизации.
Дальше мы перешли от чисто сценарного бота к гибридной модели. Запрос пользователя сначала может быть распознан как одна из заранее известных тематик — для типовых задач работают сценарии и интеграции с системами ПЭК: статус груза, адресная доставка, расчёт стоимости, поиск филиала. А для свободных вопросов, которые сложно уложить в одну кнопку или заранее подготовленную реплику — правила перевозки, документы, оплата, хранение, упаковка, международные перевозки, — подключили базу знаний в формате Q&A.
Сценарии отвечают там, где важны точность и предсказуемость, а база знаний закрывает всё, что раньше упиралось в конец сценария и уходило оператору.
Эффект дала именно совокупность двух этапов: новая логика перевода на оператора сама по себе подготовила почву, а гибридная архитектура закрыла оставшиеся точки неопределённости. Вместе это подняло автоматизацию с 69% до 74%.
Расширение автоматизации не означает, что оператора нужно убрать из процесса — наоборот, одна из важных частей проекта — правильно определить границу автоматизации. Если пользователь впервые просит человека, бот сначала предлагает решить вопрос прямо в диалоге и уточняет проблему; если клиент продолжает настаивать, обращение передаётся оператору. А вопросы, где участие сотрудника действительно необходимо — например, повреждение или утрата груза, претензия или спорная финансовая ситуация, — сразу маршрутизируются человеку.
Таким образом, перевод на оператора перестаёт быть универсальным fallback-сценарием и становится осознанным решением внутри общей логики обслуживания.
Классический бот хорошо отвечает на вопрос «какой статус моего груза?». Но реальные обращения звучат иначе: «Почему он до сих пор едет?», «Почему груз поехал через другой город?», «Вы обещали раньше, что происходит?». Формального ответа вроде «груз находится в пути» здесь недостаточно.
Сейчас мы прорабатываем LLM-агента, который сможет соединять официальный статус и данные по конкретному грузу с информацией из базы знаний и формулировать понятный ответ на такие вопросы — например, объяснять роль транзитных терминалов или возможную причину движения груза по конкретному маршруту, не придумывая при этом новых сроков или фактов. Сценарий пока в разработке и не запущен на проде, но именно в эту сторону расширяется применение LLM в боте ПЭК.
Проект ПЭК показывает, как может развиваться зрелая автоматизация клиентского сервиса: сначала — изменение логики перевода на оператора, затем — переход к гибридной архитектуре со сценариями и базой знаний. Вместе эти два этапа подняли автоматизацию с 69% до 74%.
Для клиента это выглядит просто: ему не приходится разбираться, какой именно сценарий сейчас работает — он задаёт вопрос о своём грузе и получает понятный ответ. А оператор подключается тогда, когда он действительно нужен.
Мы свяжемся с вами в рабочее время (с 9.00 по 18.00 МСК), чтобы ответить на ваши вопросы, собрать информацию для рассчета коммерческого предложения, а также договориться об удобном для вас времени для онлайн-встречи для демонстрации возможностей наших ИИ-агентов.
