Проблема и что мы сделали
Клиенты писали на сайт и в мессенджеры быстрее, чем операторы успевали отвечать. Половина обращений — одни и те же вопросы из документации, статус заказа и «создайте тикет».
Мы разработали омниканального ИИ-бота, обучили его на инструкциях и базе знаний компании и связали с CRM и helpdesk. Бот закрывает типовое сам, а сложное отдаёт человеку вместе с историей диалога — плюс собирает аналитику причин обращений.
Первая линия тонула в повторах: статус заказа искали в CRM вручную, тикеты заводили после переписки, при эскалации терялся контекст. Мы связали омниканального бота с базой знаний, CRM и helpdesk — типовое закрывается в диалоге, сложное уходит оператору уже с историей. Отдельно заложили правило: нет надёжного ответа — передача человеку, без попытки закрыть любой ценой.
„
Максим, Руководитель проектов NeuroB2B
Почему захлёбывалась первая линия
Компания принимает обращения с сайта и из мессенджеров. Внутри — helpdesk для тикетов, CRM для заказов, пачка документации и внутренних инструкций. На бумаге контур был собран. На практике первая линия жила в разрыве между каналами и системами.
Оператор открывал чат, узнавал вопрос, лез в базу знаний или в CRM за статусом заказа, потом вручную заводил тикет, если нужно было передать дальше. Типовые темы занимали очередь наравне со сложными. Когда обращение всё-таки уходило человеку «выше», часть контекста терялась: клиент повторял историю, оператор догонял по обрывкам переписки.
Нужна была полноценная первая линия: один бот на каналах клиента, ответы по знаниям компании, проверка заказа, создание тикетов и аккуратная эскалация — а не виджет «напишите нам».
Что разработали
- Омниканальный бот для сайта и мессенджеров. Собрали единого агента поддержки, который встречает клиента там, где тот уже пишет — в чате на сайте и в мессенджерах. Логика одна, каналы разные: не два разных бота с разным поведением.
- Обучение на документации, инструкциях и базе знаний. Бот отвечает по материалам компании, а не «из общих соображений». Типовые вопросы закрываются формулировками и фактами из внутренних источников — так же, как это делал бы обученный оператор первой линии, только без очереди и без ночной дыры в покрытии.
- Ответы на типовые обращения. Сценарии первой линии заточены на повторяющиеся темы: как оформить, как работает услуга, что делать в стандартной ситуации. Если ответ находится в базе — бот закрывает диалог сам и не занимает человека.
- Проверка статуса заказа в CRM. Для запросов «где мой заказ» бот не отправляет клиента «подождите оператора». Он обращается к CRM, достаёт актуальный статус и отдаёт его в переписке. Связка «вопрос клиента → данные заказа» больше не требует ручного поиска в соседней вкладке.
- Создание тикетов в helpdesk. Если обращение нужно зафиксировать и провести через процесс поддержки, бот сам создаёт тикет: не копирует текст руками и не просит оператора «заведите, пожалуйста, заявку». Диалог на сайте или в мессенджере становится точкой входа в helpdesk, а не параллельной веткой, которую потом кто-то догоняет.
- Передача сложных обращений оператору с историей диалога. Когда бот не должен закрывать кейс сам — нетиповой запрос, спорная ситуация, то, чего нет в базе, — он эскалирует. Оператору уходит не голое «клиент что-то хочет», а история переписки: что уже спросили, что ответили, какой статус заказа смотрели. Клиенту не нужно рассказывать всё с нуля.
- Аналитика причин обращений. Поверх диалогов собирается слой аналитики: какие темы приходят чаще, что закрывается ботом, что уходит на людей. Это уже не только «ответили в чате», а материал для доработки базы знаний и процессов поддержки.
Как это стыкуется в работе
Клиент пишет на сайте или в мессенджере. Бот принимает обращение, определяет тему и ищет ответ в обученной базе. Типовой вопрос закрывается на месте. Запрос про заказ — уходит проверка в CRM и ответ со статусом. Нужен процессный follow-up — создаётся тикет в helpdesk.
Если кейс сложный, подключается оператор. Он видит историю диалога и не тратит первые минуты на раскопки. Параллельно накапливается аналитика причин: видно, чем реально забита первая линия и какие куски документации стоит усилить.
Где была тонкая грань
База знаний покрывает не всё. Ранний риск — бот, который слишком уверенно договаривает там, где в инструкциях дыра. Мы заложили правило эскалации: нет надёжного ответа или запрос явно вне типовых сценариев — передача человеку с полной историей, без попытки «закрыть любой ценой».
Вторая сложность — не разорвать каналы и бэк-офис. Ответ в мессенджере без тикета и тикет без контекста чата снова собирают поддержку из кусков. Поэтому создание тикета и эскалация завязаны на тот же диалог: helpdesk получает след разговора, а не пустую карточку.
Как изменилась первая линия
| Было | Стало |
| Типовые вопросы занимали очередь наравне со сложными | ИИ-бот закрывает типовое на сайте и в мессенджерах |
| Статус заказа искали вручную в CRM | Бот сам проверяет статус и отвечает клиенту |
| Тикеты заводили руками после переписки | Тикет в helpdesk создаётся из диалога |
| При эскалации часть контекста терялась | Оператор получает историю диалога целиком |
| Причины обращений почти не собирали | Есть аналитика тем и причин |
Итог
Компания получила ИИ-рекрутера во входном контуре найма — от сбора отклика до заключения для руководителя. Агент забирает hh.ru и почту, нормализует и разбирает резюме по требованиям вакансии, строит рейтинг, проводит первичное интервью в чате или по видео и сам отдаёт результаты в ATS.rnrnКоманда подбора больше не живёт на входном фильтре. В системе — не гора сырых откликов, а ранжированные кандидаты с первичкой и кратким заключением. Дальше контур можно расширять новыми источниками, сценариями под разные роли и уточнением критериев ранжирования по обратной связи руководителей.
