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