AI-чат-бот WhatsApp: де ламається прийом звернень
Звернення в месенджер надходять цілодобово, а підтримка працює за графіком. Повідомлення, надіслане пізно ввечері, залишається без відповіді до ранку — і на цей момент клієнт або пішов до конкурента, або оформив замовлення там, де відповіли швидше.
Такі втрачені звернення майже не видно у звітності: діалог не відбувся, отже, і в статистиці його немає.
Пікове навантаження добиває те, що не добили години роботи. Після розсилки або в день розпродажу вхідний потік зростає в рази, черга звернень розтягується, а час першої відповіді виходить за десятки хвилин.
Оператори в ці години витрачають сили на одні й ті самі типові питання — про терміни доставки, наявність, оплату, повернення, — і на складні випадки в них не залишається ресурсу.
Окремий біль — пам'ять про діалог. Новий співробітник відкриває листування й не бачить, що клієнту вже обіцяли, яке замовлення обговорювали, що вирішили минулого разу. Він ставить ті самі питання знову, клієнт повторює історію третій раз і йде роздратованим.
Усі три вузькі місця — прийом поза годинами, розвантаження піків і єдина історія звернення — закриваються надбудовою над WhatsApp Business API з базою знань і мовною моделлю. Розбираємо, як це влаштовано і що дає бізнесу.
Що змінюється після запуску: швидкість, точність, розвантаження
Запуск бота не скасовує зміну підтримки — він змінює те, які звернення до неї доходять. Показники ми знімаємо до старту й через два тижні після, щоб ефект читався в цифрах, а не у відчуттях. Нижче — п'ять величин, які зрушуються першими і за якими видно, що рішення працює.
Час першої відповіді та частка діалогів без оператора
У звичайному режимі клієнт чекає стільки, скільки оператор витрачає на попередній діалог: у пік це хвилини, вночі — до ранку. Бот відповідає за секунди й тримає цей темп цілодобово, включно з вихідними. Час першої відповіді перестає залежати від завантаження зміни та часового поясу клієнта.
Частка діалогів без оператора — друга контрольна величина. Вважаємо її як відношення звернень, закритих повністю в чаті, до загального потоку.
На типових темах — статус замовлення, умови, наявність, запис — вона тримається високою, а все, що потребує рішення людини, переходить до оператора з уже зібраною історією листування.
Зняті класи відмов і навантаження на зміну
Окремо фіксуємо зняті відмови: покинуті діалоги в неробочі години, втрачені заявки всередині листування, відповіді не за темою через застарілу інформацію. Раніше кожен такий випадок означав втраченого клієнта; тепер він закривається в момент звернення.
Розвантаження підтримки видно за структурою зміни: нічний потік перестає вимагати чергового, вдень оператори беруть складні питання замість однотипних.
Цілодобовий прийом з'являється без розширення штату — рутина переходить боту, а люди займаються тим, де справді потрібні рішення.
Варіанти збирання чат-бота: сценарії, пошук по базі, гібрид
Три підходи відрізняються не «розумом» моделі, а тим, хто визначає наступний крок діалогу: заздалегідь написаний сценарій, пошук по базі знань або їх комбінація.
Вибір диктує передбачуваність питань і ціна помилки — там, де неправильна відповідь дорого коштує, свобода формулювань шкодить.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Сценарії діалогу | Типові операції: запис, статус заявки, коротка анкета | Не розуміє формулювань поза гілками, кожна нова тема — ручне доопрацювання |
| Пошук по базі знань | Велика різнорідна документація, питання вільним текстом | Відповідає за знайденими фрагментами: застаріла база дає впевнені помилки |
| Гібридна схема | Частина кроків строга, частина — консультація | Складніша в підтримці: потрібні правила маршрутизації між сценарієм і пошуком |
Чим відрізняються сценарій і пошук по базі знань
Сценарій — це граф станів: бот знає допустимі відповіді на кожному кроці й завжди доводить діалог до результату. Пошук по базі знань працює інакше: питання шукає близькі фрагменти в документації, і модель формулює відповідь за ними.
Перший дає передбачуваність без вигадок, але ламається на нестандартному формулюванні; другий тримає живу мову, але залежить від свіжості бази.
Гібридна схема знімає цей компроміс: ключові дії йдуть за сценарієм, решта переходить у пошук, а за низької впевненості — оператору.
Обмеження каналу та зовнішніх сервісів
WhatsApp Business API задає рамки: поза вікном вільної відповіді писати можна лише затвердженим шаблоном, у кнопок і медіа є ліміти, розсилки потребують згоди отримувача. Тому повідомлення планують заздалегідь, а не за фактом.
Передавання оператору проєктується як частина логіки — діалог переходить у чергу разом з історією та чернеткою відповіді, щоб клієнт не починав розмову заново.
Етапи впровадження: від аудиту листувань до передавання
Аудит діалогів і карта маршрутів
Починаємо з вивантаження історії листувань з WhatsApp Business API і розбору її вручну: скільки звернень, які теми, де відповідь оператора запізнюється. Так видно реальний обсяг автоматизації, а не передбачуваний.
- Аудит діалогів. Розмічаємо вивантаження за кілька місяців за темами й типовими формулюваннями — отримуємо частку звернень, які бот закриє сам без втрати якості.
- Карта маршрутів. Фіксуємо гілки сценарію та правила ескалації: за якою ознакою підключається людина, що бачить оператор у момент передавання.
Налаштування, перевірки, передавання
Після погодження карти маршрутів переходимо до збирання та перевірок — на цьому етапі змінюється вміст, але не логіка сценарію.
- Збирання бази знань. Регламенти, каталог і типові відповіді ріжемо на фрагменти й пов'язуємо з пошуком: модель відповідає за джерелами, а не з пам'яті, і кожну репліку можна перевірити.
- Підключення каналу. Реєструємо номер, налаштовуємо шаблони повідомлень і повідомлення про нові звернення, перевіряємо доставку та статуси на тестовому акаунті.
- Приймальні перевірки. Проганяємо набір контрольних діалогів, включно з неповними та провокаційними питаннями, фіксуємо неточні відповіді й правимо базу до здавання.
- Передавання в експлуатацію. Віддаємо доступи, схему маршрутів та інструкцію оператора, показуємо, як оновлювати базу знань і дивитися статистику своїми силами.
Що залишається в команди: конфігурації, схеми, регламенти
Рішення залишається в замовника не як «чорний ящик», а як набір документів і налаштувань, за якими бота можна розвивати без нас. Ми фіксуємо кожне ухвалене рішення — від параметрів підключення до правил, за якими оператор забирає діалог у бота.
Технічні артефакти та права доступу
- Робоча конфігурація бота: параметри номера, шаблони повідомлень, правила повторів при недоставці та налаштування передавання діалогу людині.
- Карта маршрутів діалогів: які сценарії йдуть у базу знань, які одразу до оператора, де спрацьовують уточнювальні питання.
- Наповнена база знань: розмічені матеріали, правила розбиття на фрагменти та тестові питання, за якими перевірялася точність відповідей.
- Правила доступу та ролі: хто бачить листування, хто править сценарії, хто вивантажує історію — з журналом дій за кожною зміною.
- Схема інтеграцій: як бот отримує дані з облікової системи і що відбувається при недоступності зовнішнього сервісу.
Інструкції для операторів і власника
- Інструкція оператора: як прийняти діалог, що видно на екрані, як повернути бота в роботу і що робити при типових збоях.
- Регламент оновлень: порядок додавання матеріалів, перевірка відповідей перед публікацією та відкат до попередньої версії сценарію.
- Чек-ліст приймання: контрольні питання, за якими власник сам перевіряє бота після кожної правки.
Кейс: як потік звернень перестав губитися в пік
Що було до запуску
Пік приходив хвилею: сезонна акція давала до чотирьох тисяч вхідних на добу, і вся черга сідала на дев'ять операторів у дві зміни. Час першої відповіді в пікові години сягав 40 хвилин, вночі звернення чекало до ранку.
Кожне дванадцяте повідомлення залишалося без відповіді взагалі — діалог закривався за часом очікування, коли клієнт уже пішов до іншого продавця.
Ручна маршрутизація погіршувала картину: оператор шукав замовлення в обліковій системі та базі знань вручну, а типові питання про доставку, наявність і повернення з'їдали до третини зміни. Найм не допомагав — вихід нового оператора на потік займав тижні, і пік усе одно обганяв штат.
Що стало після і як це вимірювали
Зібрали AI-чат-бот на WhatsApp Business API: вхідний потік переходить в асинхронну чергу, відповідь модель формує з опорою на RAG за базою знань і залишками, а оператору діалог передається за правилами — модель не впевнена, клієнт просить людину, тема поза регламентом.
Заміри робили на порівнюваних періодах: два тижні до і після, ті самі сценарії та одна розмітка вивантаження діалогів. Час першої відповіді — 8 секунд, включно з ніччю; частка діалогів, закритих без оператора, — 63%; звернення без відповіді — 0,7%.
За даними Gartner, клієнт у месенджері чекає реакції хвилини й іде, якщо її немає, — тому першу метрику вивели в основний звіт.
Чим відрізняється пошук по базі знань від сценаріїв?
Сценарний бот — це дерево рішень: повідомлення зіставляється з наміром, намір прив'язаний до гілки, гілка повертає заготовлену відповідь або запускає дію. Формулювання фіксовані, перевіряти потрібно кінцеве число переходів, ризик вигаданої відповіді нульовий. Поки типових питань десятки і вони повторюються, це найпередбачуваніший варіант.
Відповіді за документами влаштовані інакше: запит перетворюється на вектор, з бази знань піднімаються релевантні фрагменти регламентів, інструкцій і договорів, і модель будує відповідь лише за ними.
Критичні не генерація, а розбиття документів на фрагменти, свіжість індексу та поріг впевненості: нижче порога бот передає діалог оператору, а не добудовує відповідь.
Вибір підходу задає тип питань. Запис, статус замовлення, оплата — сценарій: там важлива детермінованість і однакова відповідь на однаковий запит. Довідкові питання й довгий хвіст («а якщо я не в місті», «які умови для юросіб») — пошук за документами. Робоча схема — гібрид: маршрутизатор визначає тип питання й віддає його потрібному шару.
Якщо бот уже працює на сценаріях і впирається в нетипові питання, міграція йде без зупинки сервісу.
Спочатку вмикаємо логування нерозпізнаних звернень, з них збираємо розмічений набір для заміру точності відповідей, потім додаємо шар пошуку за документами й розкочуємо його на частку трафіку з відкатом на сценарій.
Для WhatsApp Business API це окрема робота: короткі репліки та кнопки обмежують формат відповіді, тому шар пошуку проєктується під них одразу — з розбиттям довгих витягів і посиланням на джерело.
Технічні сумніви: точність, дані, передавання, відкат
П'ять питань, які найчастіше порушують на технічному розборі: точність на нестандартних формулюваннях, доля листування, жива передача діалогу, оновлення бази знань, оборотність змін.
Наскільки точно бот відповідає, якщо клієнт пише не за шаблоном?
Відповідь будується на семантичному пошуку по базі знань, а не на збігу фраз. Бот відповідає лише за достатньої близькості знайденого фрагмента; нижче порога — не додумує, а уточнює або передає діалог оператору. Поріг калібруємо за логами перших тижнів.
Що відбувається з листуванням клієнтів?
Історія йде захищеним каналом і зберігається у вашому контурі — не переходить на навчання сторонніх моделей. Термін зберігання задається політикою, доступ розмежовано ролями.
Як працює передавання діалогу оператору?
Спрацьовує за запитом людини, повторним непорозумінням або ключовою темою. Оператор отримує історію, знайдені фрагменти бази знань і версію сценарію — клієнт продовжує розмову, а не починає заново.
Як оновлюється база знань?
Джерела — вивантаження, документи, таблиці, статті; переіндексація йде за розкладом або за фактом зміни. Нові матеріали входять окремим шаром, тому їх перевіряють на тестовому контурі до публікації.
Чи можна відкотити зміни?
Сценарій і база знань версіонуються: повернення до попередньої версії — одна операція, відновлення за хвилини. Уже розпочаті діалоги дограються на попередній версії й не рвуться.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб перша розмова була предметною і зайняла одну годину, а не три, достатньо надіслати ввідні — решту наші інженери з'ясують самі. Опишіть, які сценарії має закривати AI-чат-бот у WhatsApp і хто з боку замовника відповідає за базу знань і регламент підтримки.
- 8–10 реальних прикладів діалогів з оператором: за ними видно, де зараз губляться звернення і які відповіді повторюються найчастіше.
- Перелік каналів і точок входу: WhatsApp, веб-форма, телефон — важливо зрозуміти, що бот закриває сам, а що передає ланцюжком.
- Регламент ескалації: у яких випадках розмова переходить до живого оператора, за якою ознакою і з якою історією листування.
- Склад бази знань: документи, інструкції, таблиці — і як вони підтримуються в актуальному стані.
- Обмеження щодо даних і доступів: що можна віддавати в модель, а що залишається в закритому контурі.
- Вимоги до строків впровадження: до якої дати потрібен пілотний запуск і який обсяг звернень він має витримати.
За підсумками розбору ми повертаємося з оцінкою та планом: склад робіт, черговість етапів, точки контролю та межі пілота, після якого розширюємо сценарії. Обговоримо задачу — із цього починається будь-яке впровадження.
