Більшість ботів відповідають на питання, яких ніхто не ставив
Дивовижна кількість ботів будується тому, що хтось побачив запуск у конкурента. Результат зазвичай — меню функцій, що дублюють сайт: ті ж FAQ, той же каталог, повільніша навігація, склеєне командним синтаксисом, який ніхто не пам'ятає. Користувачі відкривають це один раз і ніколи не повертаються. Команда винить «залученість» і додає ще одну фічу. Цикл повторюється, поки бот тихо не архівують.
Боти провалюються з тієї ж причини, що й більшість продуктів: їх побудували навколо фічі, а не навколо задачі. Лік не в кращому AI чи плавнішій розмові. Лік — у виборі задачі, яку варто закінчити.
Корисний бот закриває задачу
Хороші боти замінюють багатоступеневий процес однією розмовою. Оплатити рахунок, переплануватии доставку, створити тікет підтримки, підтвердити зустріч. Метрика успіху не залученість — це завершення задачі за меншу кількість тапів, ніж у будь-якому іншому каналі. Бот, який збільшує час на поверхні, перевернув метрику догори дриґом.
Найясніший тест, який ми використовуємо з клієнтами: напишіть роботу бота одним реченням, що закінчується конкретним дієсловом. «Бот переплановує доставку.» «Бот продовжує підписку.» «Бот оплачує рахунок.» Якщо реченню потрібно більше одного дієслова, бот робить забагато.
Три патерни, які заробляють
Після достатньої кількості запусків стає очевидно, які патерни виживають. Ці три дають більшість ROI, який ми бачимо:
- Асинхронний диспетчер. Клієнт надсилає запит. Реальна людина його бере. Бот обробляє маршрутизацію, статуси й підтвердження — операційний шар. Корисний там, де сама робота потребує людського судження, але оркестрація навколо неї — ні.
- Перевіряльник статусу. Оновлення замовлення, трекінг доставки, зміни в акаунті — приходять у чат, не витягуються з порталу. Повністю замінює тікет «де моє замовлення». Окупається у відхиленні запитів, не в залученості.
- Легка комерційна флоу. Повторна покупка, мікроплатіж, продовження підписки — один тап, одне підтвердження, готово. Живе повністю всередині Telegram, ніколи не виходить у браузер.
У кожного з них чіткий кінець. Задача клієнта виконана. Бот зробив свою роботу й пішов геть.
Три патерни, які виснажують
Дзеркальне відображення таке ж передбачуване. Ці не виживають контакту з реальними користувачами:
- Клон довідки. Бот, який реалізує наявний FAQ у повільнішому вигляді. Сайт зробив це швидше, а пошуковик — краще.
- Бот, що вимагає туторіалу. Будь-який бот, якому потрібна команда «/help» у першому повідомленні, програв. Реальні користувачі тапнуть один раз, не побачать очевидного шляху і підуть.
- Допитувач. Бот, що питає те, що БД уже знає. Клієнт із вами два роки, а бот знову запитує його ім'я.
Коли ми аудитуємо проблемного бота, хоча б один із цих трьох зазвичай — корінева причина. Видалення провального патерну майже завжди повертає більше залученості, ніж додавання фічі.
Розмова як UI
Помилка, яку майже кожна команда робить на початку, — ставитись до бота як до чат-досвіду. Це не так. Це UI, відрендерений у вигляді повідомлень. Користувач не хоче розмови — він хоче результату.
Це змінює, як ви проєктуєте все:
- Кнопки замість команд. Inline-клавіатури роблять опції видимими. Slash-команди — ні.
- Затримка важливіша за особистість. Відповідь за 300 мс краща за відповідь із дотепним заходом.
- Передбачувані форми. Та сама задача завжди повертає той самий тип картки. Сюрприз — це тертя в UI; у боті це тертя, яке користувач не може скасувати.
Найкращі боти відчуваються менше як розмова з людиною і більше як тапання крізь дуже швидкий застосунок.
Що ми виводимо у перший тиждень
Коли ми будуємо нового бота для клієнта, перша версія навмисно мала:
- Одна робота. Найчастіший запит із інбоксу підтримки.
- Один щасливий шлях. П'ять повідомлень від старту до завершення, включно з підтвердженнями.
- Одна аварійна вихідна. Чіткий спосіб дотягтись до людини, з контекстом користувача додано, щоб він не повторювався.
Усе інше — аналітика, A/B-тестування, мультимовність — приходить після того, як перша версія тиждень у проді. Боти, що намагаються вивести повний набір фіч у v1, майже завжди потребують переписування у v2. Ті, що виводять найменшу корисну річ, ітерують з основи, яка вже заробляє.
Проблема передачі
Майже кожен бот зрештою має передати людині. Передача — місце, де більшість ботів тихо провалюються. Клієнт пише питання, яке бот не розуміє, бот зациклюється на «не зрозумів», клієнт здається.
Хороша передача має три частини:
- Виявлення. Бот знає, що він поза своїми можливостями. Зазвичай — поріг впевненості, іноді жорстке правило («все про повернення»).
- Передача. Розмова переходить до реальної людини з повним контекстом. Клієнт не повторює питання.
- Закриття. Людина вирішує проблему й передає розмову назад боту, якщо є наступний крок, або акуратно закриває.
Правильно зроблено — передача невидима. Неправильно — це момент, коли клієнт відмовляється.
Що міряти
Залученість — неправильна метрика. Ті, що дійсно корелюють зі здоров'ям бота:
- Рівень завершення задачі. З тих, хто почав флоу, скільки завершило?
- Час до результату. Від першого повідомлення до підсумку — нижче краще, не вище.
- Рівень відхилення. Тікети підтримки, які бот закрив без ескалації.
- Повернення до задачі. Скільки клієнтів повернулось наступного місяця, щоб скористатись тим самим флоу?
Якщо ці чотири рухаються в правильному напрямку, бот працює. Якщо «повідомлень за сесію» зростає, а ці плоскі, бот функціонує — але не заробляє.
Коли його виводити з експлуатації
Бот — це продукт. У продуктів є життєвий цикл. Якщо базова задача змінюється — платіжний провайдер з'їжджає, воркфлоу спрощується, фіча йде на сайт — бот міг втратити свою роботу непомітно. Аудитуйте свого щоквартально й будьте готові вилучити флоу, що більше не несуть вагу. Простіший бот швидший, легший у супроводі та з більшою ймовірністю буде відкритий наступного разу.
Схожі статті
