Разработка AI-бота Viber: где теряются заявки и обращения
Обращения в Viber приходят одним потоком, но живут по разным сценариям. Один клиент спрашивает про цену и наличие, второй — про статус заказа, третий просит записать на консультацию. Все они попадают в общий чат, и дальше всё зависит от того, успел ли оператор освободиться в ту же минуту.
Первое узкое место — первый ответ клиенту. Если между сообщением и реакцией проходит несколько минут, часть людей просто закрывает чат и уходит туда, где ответили быстрее. Такие потерянные обращения в мессенджере почти не видны в отчётах: заявка не оформлена, диалог не начат, а клиент уже был.
Второе — нагрузка на операторов. Типовые вопросы про условия, сроки и статус занимают основную долю переписки, при этом человек держит несколько диалогов одновременно и теряет нить. На сложных клиентов времени не остаётся, а вечерние и ночные сообщения ждут до утра.
Разработка AI-бота Viber закрывает обе точки потерь. Бот отвечает первым в любое время, уточняет запрос по шагам, подтягивает данные о клиенте из учётной системы и передаёт оператору диалог с уже собранным контекстом. Автоматизация переписки в Viber берёт на себя типовые сценарии, а человек подключается там, где он действительно нужен — на нестандартных вопросах и сделках.
Дальше разбираем, из чего складывается такой бот и как он встраивается в поток обращений, который уже есть.
Что меняется после запуска ассистента в переписке
Первый ответ перестаёт зависеть от того, свободен ли оператор. Ассистент в Viber подхватывает сообщение в момент отправки и отвечает за секунды — включая ночь и выходные, когда раньше заявка ждала утра. Очередь на входе перестаёт быть узким местом: время первого ответа становится одинаковым и в спокойный вторник, и в час пиковой рассылки.
Доля обращений, закрытых без человека, определяется не «умом» модели, а тем, как собраны сценарии. Подтверждение заказа, статус доставки, повторная покупка, типовые вопросы по гарантии — это ветки с известным исходом, и они уходят в автоматику. Всё, где модель не уверена или клиент прямо зовёт оператора, передаётся вместе с историей диалога: человек не переспрашивает заново то, что уже прозвучало.
Пиковая нагрузка перестаёт быть проблемой штата. Ассистент ведёт одновременные диалоги без просадки качества и не «устаёт» к вечеру — операторы занимаются сложными случаями, а не потоком однотипных. Трудозатраты на одно обращение падают за счёт того, что рутинная часть отсекается до входа в линию.
Сдвиги видно в цифрах: время первого ответа, доля диалогов без участия оператора, распределение обращений по часам, среднее число реплик до решения. На них и строится приёмка — иначе автоматизация остаётся вопросом веры.
Варианты реализации: сценарии, гибрид, языковая модель
Логика диалога определяет, что бот может, а что нет. Жёсткий сценарий, гибридная схема и языковая модель решают одну задачу разными средствами, и выбор между ними — это выбор между предсказуемостью и гибкостью ответа.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Сценарный бот | Типовые воронки: заявка, запись, статус заказа. Ветвление описано заранее, ответы фиксированы | Формулировка вне сценария ведёт в тупик; новую ветку нужно перепроверять целиком |
| Гибридная схема | Продажи и поддержка, где есть и типовые действия, и свободные вопросы | Нужна разметка намерений и правила маршрутизации — модель не решает сама, что показать |
| Языковая модель | Свободные вопросы по базе знаний, уточнения по контексту, пересказ переписки | Ответы не повторяются дословно: нужен слой проверки фактов и ограничение тем |
Что работает в мессенджере
На практике ставим гибрид: распознавание намерений классифицирует сообщение, типовые запросы уходят в сценарий, свободные — модели с базой знаний. Когда уверенность распознавания низкая или клиент просит человека, срабатывает передача оператору — с историей диалога и контекстом заявки, чтобы разговор не начинался с нуля.
Схему подбираем по вашим обращениям: смотрим, какая доля сообщений укладывается в сценарий, и под неё строим маршрутизацию.
Как мы ведём проект: этапы инженерной работы
Разработка AI-бота для Viber начинается не с кода, а с разбора живых обращений: откуда приходят вопросы, какие повторяются чаще всего и на каком шаге теряются заявки. Такой порядок снижает риск, что ассистент уверенно отвечает на удобные нам вопросы, а не на те, что приносят продажи.
- Аудит диалогов. Выгружаем историю переписки, считаем долю типовых обращений, время первого ответа и потери на переходах — получаем список тем, которые действительно стоит автоматизировать.
- Проектирование сценариев. Строим карту тем и веток: что ассистент закрывает сам, где уточняет, а в какой момент передаёт диалог оператору. Правила эскалации описываем заранее — по ключевым словам и числу неудачных попыток.
- Разметка примеров. Собираем корпус реальных фраз и размечаем типы обращений и сущности: товар, город, номер заказа. Отдельно добираем опечатки, жаргон и сообщения, где вопросов сразу несколько.
- Сборка и связка с системами. Подключаем каталог, остатки, статусы заказов и историю клиента, чтобы ответы строились на живых данных, а не на статичной подсказке.
- Тестирование ассистента. Прогоняем сценарные наборы и смотрим долю корректных ответов по каждому типу обращения отдельно, а не среднюю цифру. Ловим зацикливание, молчание и подмену темы.
- Запуск и передача. Сначала включаем бота на части трафика и сравниваем с операторами по времени ответа и доле решённых вопросов, затем выводим на весь поток. Команда заказчика получает доступы, инструкции и регламент правок в сценариях — дообучение идёт без нас.
Что остаётся у вас на руках: сценарии, разметка, документация
Передаём не закрытый сервис, а работающую систему, которую ваша команда ведёт дальше сама. Артефакты оформлены так, чтобы новый инженер или руководитель поддержки разобрался в логике без наших пояснений: описания шагов, условия переходов, комментарии к спорным веткам.
- Сценарии диалогов — дерево веток с условиями переходов и обработкой нераспознанных фраз: видно, где ассистент уточняет, а где передаёт диалог дальше.
- База знаний — ответы, привязанные к сценариям, с указанием источника каждого факта; правки вносятся без пересборки бота.
- Правила эскалации — повторный вопрос, негативная формулировка, тема вне базы знаний; пороги меняются настройкой.
- Инструкция для операторов — как читать историю диалога и подхватывать разговор без потери контекста.
- Регламент дообучения — разметка новых формулировок из накопленных диалогов, проверка на тестовой выборке, выкат с возможностью отката.
- Схема интеграций и доступы — куда уходят заявки и откуда берутся данные о заказах, какие роли для этого нужны.
- Чек-лист приёмки — набор тестовых диалогов, по которым видно, что после правок ничего не сломалось.
Дальше вы развиваете ассистента в своём темпе: доля обращений, закрытых без оператора, растёт по мере расширения базы знаний, а мы подключаемся на сложные доработки.
Кейс: бот снял с операторов рутинные обращения
Клиент — сеть сервисных центров с потоком однотипных обращений в мессенджере Viber: статус заказа, сроки, запись, гарантия. До внедрения всё держалось на операторах: пик приходился на вечер, ночные сообщения ждали до утра, к понедельнику копилась очередь. По выгрузке из истории диалогов за две недели наблюдений первый ответ в часы пик уходил за 40 минут, а каждая пятая заявка оставалась без ответа в тот же день.
Точка отсчёта
- Доля автоответов — около нуля: любое обращение открывало карточку оператора.
- Первый ответ — 15–40 минут в пик, ночью пауза до утра.
- Пропущенные обращения — 18–22% за неделю, плюс повторные вопросы тех же клиентов.
Разметили историю переписок по намерениям, собрали набор сценарных веток и вынесли в бота всё, что решается без человека. Неуверенные разборы и спорные случаи бот передаёт оператору вместе с распознанной темой и контекстом диалога — сотрудник не начинает разговор с нуля. Отдельная ветка закрывает ночь и выходные, поэтому очередь больше не копится к утру.
Результат
Доля автоответов вышла на 62–68% в месяц, время первого ответа — секунды в любое время суток, пропущенные обращения — единичные случаи на пике. Операторы переключились на сложные обращения и допродажи: нагрузка на смену упала примерно вдвое при том же объёме входящих.
Сценарная логика или языковая модель: что выбрать?
Сценарная логика ведёт диалог по заданному дереву: реплика распознаётся как одна из известных веток, ответ берётся из шаблона. Это даёт предсказуемость — на вопрос о статусе заказа бот отвечает одинаково и не придумает условие, которого нет в правилах.
| Архитектура диалога | Когда подходит | Ограничения |
|---|---|---|
| Только сценарий | Короткий перечень тем, где важна точность: заявки, статусы, запись | Не понимает перефразировок и опечаток, под каждый новый вопрос нужна ветка |
| Только языковая модель | Свободные консультации, разбор длинных описаний задачи | Ответы не повторяются от раза к разу, нужны проверка фактов и запрет части тем |
| Смешанная схема | Продажи и поддержка с типовыми шагами и живыми формулировками | Сложнее настройка: нужна разметка намерений и тесты на ложные срабатывания |
Выбор определяют два числа: доля обращений, не попавших в сценарий, и цена неверного ответа. Языковая модель разбирает формулировки, которых в дереве не было, но её ответы нужно проверять — без ограничений она пообещает клиенту лишнее.
Рабочая схема чаще смешанная: модель определяет намерение и формулирует ответ, а данные о заказе, тарифах и условиях бот берёт из справочника по сценарию. Так гибкость формулировок не ломает предсказуемость там, где ошибка стоит дорого.
В Viber логика та же, что и в других каналах: на входе текст, на выходе — ответ либо передача диалога оператору, если уверенность распознавания ниже порога.
Сомнения перед запуском: данные, надёжность, эскалация
До старта работ технические вопросы обычно одни и те же — отвечаем по порядку. Историю диалогов храним в отдельной базе, а не в переписке мессенджера: задаём срок хранения, маскируем телефоны и адреса до записи, по запросу удаляем ветку вместе с производными данными. В обучающую выборку персональные данные не попадают — настройка идёт на обезличенных фрагментах.
Интеграцию с учётной системой делаем через обмен событиями: бот создаёт заявку и читает статус клиента, но не правит учётные записи напрямую. Если система недоступна, диалог не теряется — он уходит в очередь, а клиент получает ответ по запасному сценарию.
Эскалация на оператора срабатывает по просьбе клиента, повторному вопросу, низкой уверенности модели и спорной теме. Оператор получает полный контекст диалога, а не обрывок — переспрашивать клиента не приходится.
Качество ответов проверяем эталонным набором вопросов: прогоняем его после каждой правки сценария. Разметка неудачных диалогов показывает, где модель уверенно ошибается, а где ей не хватает данных.
Что будет, если бот ответит неверно?
Спорный ответ фиксируется в журнале, сценарий правится, контрольный набор перезапускается — ошибка не повторяется. На темах вне регламента бот уступает диалог оператору.
Можно ли поменять модель, не переписывая бота?
Да. Логика диалога, интеграции и правила эскалации отделены от модели, поэтому её обновление до актуальной ветки не требует пересборки сценариев.
Кто видит переписку?
Доступ ролевой: оператор — только свои диалоги, выгрузка и удаление — по журналу действий.
Обсудим задачу: что подготовить к разговору
Чтобы оценка была предметной, а не «на глаз», достаточно нескольких вводных: по ним видно объём сценариев, состояние данных и число интеграций. Ниже — что подготовить к разговору; если чего-то нет, это тоже вводная, подскажем, чем заменить.
- Цели и границы: какие обращения бот закрывает сам, а какие обязан передать оператору, и по какому признаку принимает это решение.
- Примеры диалогов — несколько десятков реальных переписок или выгрузка обращений за период: по ним считаем типовые сценарии и находим места, где клиенты бросали разговор.
- Исходные данные проекта: откуда берутся товары, цены и статусы заказов, где хранится история клиента, насколько она полная и актуальная.
- Точки интеграций: каталог и склад, приём платежей, служба доставки, CRM или система заявок, график работы операторов.
- Тон и обязательные формулировки: что бот не имеет права обещать, какие ответы требуют согласования и кто их утверждает.
- Доступы: владелец публичного аккаунта Viber, отдельный тестовый номер под песочницу, права на интеграции с вашими системами.
- Метрики приёмки: доля диалогов, закрытых без оператора, время первого ответа, точность определения намерения на ваших формулировках.
С этим набором вернёмся с оценкой и планом работ: состав команды, этапы, порядок запуска на тестовом номере, условия приёмки и порядок дообучения на новых диалогах.
