Ваш бот відповідає правильно на 80% запитів? Звідки ви знаєте?

Якщо відповідь «ну, скарг немає», то у вас немає даних про якість бота — у вас є відсутність видимих проблем. Це різні речі. Клієнт, якому бот дав розмиту відповідь, частіше просто закриває чат, ніж скаржиться. Власник не бачить цих втрат.

Бот без метрик — чорний ящик. Він може добре виглядати в дашборді і погано конвертувати. Або навпаки: мати багато handoff-ів, але кожен з них — навмисний і правильний. Метрики дозволяють відрізнити одне від одного.

Навіщо вимірювати якість бота

Три практичні причини:

Перша: KB деградує. Ваші послуги змінюються, прайс оновлюється, умови роботи корегуються. Бот продовжує відповідати по-старому. Без метрик ви не знаєте де і коли це почалось.

Друга: різні відповіді дають різну конверсію. Два варіанти тексту відповіді на питання про ціну можуть давати суттєво різний відсоток переходу до бронювання. Метрики дозволяють це помітити і виправити.

Третя: бот — не вічна машина. Якість роботи AI-бота залежить від якості KB і налаштувань промпту. Без регулярного моніторингу ви не знаєте чи бот покращується або погіршується після кожного оновлення.

Чотири рівні метрик: від технічних до бізнесових

Перш ніж до конкретних KPI — структура. Метрики для бота можна розкласти на чотири рівні:

Технічні. Uptime (доступність бота), latency (час відповіді). Бот має відповідати за менш ніж 2 секунди в 95% випадків. Якщо latency стабільно більше 3 секунд — це вже помітно в UX. Uptime для Telegram-бота на хмарній інфраструктурі має бути 99%+.

Якість відповідей. Відсоток розмов де бот дав точну, корисну відповідь без помилок. Важкий для автоматичного вимірювання, але критичний для розуміння стану KB.

Взаємодія. Як клієнти поводяться в розмові: чи завершують її, чи запитують ще, чи запитують людину.

Бізнес-вплив. Скільки розмов закінчились бронюванням, як змінився no-show rate, чи повертаються клієнти.

П'ять KPI нижче охоплюють усі чотири рівні — і при цьому їх можна відстежувати без складної аналітичної інфраструктури.

П'ять KPI що варто відстежувати щотижня

1. Resolution Rate (% вирішених запитів)

Що вимірюємо: відсоток розмов, які бот завершив без передачі людині.

Як рахувати: (кількість розмов без handoff / загальна кількість розмов) × 100%.

Метрики яких варто уникати (vanity metrics)

Кілька показників, що виглядають переконливо але не говорять нічого корисного:

Кількість повідомлень. «Бот обробив 3000 повідомлень за місяць» — це може означати 300 якісних розмов або 1000 коротких взаємодій де клієнт не отримав відповіді.

Кількість унікальних користувачів. Мало що говорить без контексту — важливіше conversion rate з цих користувачів.

«Відсоток автоматизації» без контексту. Якщо бот «автоматизував» 90% запитів, але 30% з них вирішено погано — це не автоматизація, це шум.

Швидкість зростання бази. Більше клієнтів у боті не рівно більше бронювань — залежить від якості розмов.

Ці метрики — не погані, але не вирішальні. Звертайте на них увагу лише в контексті основних п'яти.

Як зібрати ці дані практично

Що дає Leadmlyn dashboard:

Загальна кількість розмов і динаміка по тижнях
Розбивка по темах розмов
Кількість handoff-ів і причини
Середня тривалість і кількість повідомлень у розмові
Статистика wallet і токени (як proxy для обсягу)

Що рахувати вручну або окремо:

Booking conversion: порівняйте кількість бронювань з CRM з кількістю розмов на тему бронювання в боті. Проста таблиця в Google Sheets.
No-show rate: ваша CRM або власна таблиця бронювань. Зафіксуйте baseline до запуску бота.

Мінімальний ритм відстеження: 15 хвилин на тиждень. Відкрийте dashboard у понеділок, перегляньте 5 KPI, запишіть у таблицю. Через 4-6 тижнів буде видно тренди.

Коли метрики сигналізують проблему і що робити

Resolution rate падає 3 тижні поспіль. Перший крок — список причин handoff за останні 2 тижні. Які питання бот не зміг вирішити? Більшість з них — кандидати для нових KB-записів або оновлення існуючих.

Escalation rate різко виріс після оновлення KB. Оновлення KB або промпту могло зламати щось, що раніше працювало. Порівняйте теми handoff до і після оновлення.

Conversation completion rate падає. Аналізуйте де клієнти «зникають» у розмові. Якщо більшість — після питання про ціну, перевірте KB-запис з ціною: можливо він неповний або бот дає відповідь, яка не веде до наступного кроку.

Booking conversion низький при нормальному completion rate. Проблема не в тому, що клієнт не отримав відповідь — він отримав, але не пішов бронювати. Це питання CTA у відповіді бота або pricing. Спробуйте додати чіткий заклик до дії в KB-запис про ціну.

Більше про те як налаштувати бота щоб ці метрики росли — у матеріалах про сценарії AI для leisure-бізнесу і про те, як зібрати якісну базу питань для KB. Метрики показують де проблема, але вирішення — завжди в KB і промпті.

KPI для AI-бота: п'ять метрик що реально показують якість роботи

Навіщо вимірювати якість бота

Чотири рівні метрик: від технічних до бізнесових

П'ять KPI що варто відстежувати щотижня

1. Resolution Rate (% вирішених запитів)

Схожі статті

А/Б тести для бот-відповідей: метод без складної інфраструктури

Мова бота для UA-бізнесу: Ukrainian-first і розумний підхід до інших мов

2. Escalation Rate (% ескалацій)

3. Conversation Completion Rate

4. Booking Conversion Rate

5. No-show Rate до і після

Метрики яких варто уникати (vanity metrics)

Як зібрати ці дані практично

Коли метрики сигналізують проблему і що робити

Збір лідів через Telegram-бота: підхід "наступний крок" замість продажу