Як протестувати робота перед масовим запуском
Перш ніж вмикати голосового робота на всю базу лідів, варто перевірити сценарій на невеликій вибірці дзвінків. Пілот показує, як реальні клієнти відповідають на живі репліки, де сценарій ламається і що саме плутає людей. Нижче — скільки дзвінків достатньо для тесту, що слухати в записах, які правки вносити першими і за яким сигналом можна переходити до масового запуску.
Навіщо тестувати робота, а не запускати одразу на всю базу
Сценарій написаний, телефонія й CRM підключені — здається, лишилось тільки натиснути «старт» на всій базі лідів. Але сценарій, який виглядає логічно на папері, і сценарій, який витримує реальні відповіді живих людей, — це часто дві різні речі.
Клієнти перебивають, відповідають не так, як передбачала команда, ставлять зустрічні питання. Одна з найдорожчих помилок впровадження — коли перший запуск одразу йде на всю базу; ми вже розбирали це в матеріалі Типові помилки при впровадженні голосового робота. Тут — детальніше про сам процес тестування: скільки дзвінків достатньо, що слухати і коли рухатись далі.
Скільки лідів брати для пілотного тесту
Універсального числа немає, і будь-хто, хто називає точну цифру без деталей про ваш сценарій, або вгадує, або переносить чужий досвід на вашу нішу. Розмір пілоту залежить від того, скільки гілок у сценарії й наскільки різноманітна ваша база клієнтів.
Орієнтир простий: для короткого сценарію з однією метою зазвичай вистачає невеликої вибірки — кількох десятків дзвінків, щоб побачити основні патерни відповідей. Розгалужений сценарій із кількома винятками вимагає ширшої вибірки, бо рідкісні гілки просто не встигнуть спрацювати на малій кількості дзвінків.
| Сценарій | На що дивимось | Орієнтир пілоту |
|---|---|---|
| Одна мета, коротка розмова | чи розуміє робот типові відповіді | невелика вибірка дзвінків |
| Кілька гілок і винятків | чи спрацьовують рідкісні гілки | ширша вибірка дзвінків |
| Є передача менеджеру | чи коректно й вчасно передається розмова | окрема перевірка саме таких випадків |
Що слухати в записах тестових дзвінків
Цифри на дашборді — скільки дзвінків, яка середня тривалість — корисні, але не показують суті. Головне джерело правди на етапі пілоту — самі записи розмов, а не зведена статистика.
- Чи розуміє робот відповіді, сформульовані не так, як у сценарії.
- У яких місцях клієнт перепитує або не розуміє питання робота.
- Чи природно звучать паузи й переходи між репліками.
- Чи спрацьовує передача менеджеру там, де це справді потрібно.
Які правки вносити в сценарій за підсумками тесту
Не всі правки однаково важливі. Найкраще спочатку виправити те, що трапляється часто й псує розмову для багатьох клієнтів, а вже потім братися за рідкісні винятки.
- Формулювання, які регулярно плутають клієнтів, — переписати найпершими.
- Місця, де бракує гілки для типової відповіді, — додати нову гілку.
- Умови передачі менеджеру, що спрацьовують запізно чи невчасно, — уточнити тригери.
- Рідкісні винятки, що трапилися один-два рази, — відкласти до наступної ітерації.
Як налаштувати поступове масштабування після пілоту
Коли перший цикл правок зроблено, не варто одразу переходити на всю базу. Надійніше розширювати вибірку крок за кроком, повторюючи ту саму перевірку.
Як поступово масштабувати голосового робота після тесту
Запустіть пілот на малій вибірці
Оберіть невелику й показову частину бази й прогоніть на ній робота з поточним сценарієм — без розширень і винятків.
Прослухайте записи й зафіксуйте патерни
Прослухайте всі дзвінки пілоту, а не тільки невдалі, і випишіть, які формулювання плутають клієнтів найчастіше.
Внесіть правки в сценарій
Спочатку виправте те, що трапляється часто, потім — рідкісні винятки. Не намагайтесь закрити все за одну ітерацію.
Розширюйте вибірку поступово
Повторюйте цикл на більшій вибірці, поки черговий тест не перестане приносити нові суттєві правки, — і лише тоді масштабуйте на всю базу.
Коли робот готовий до запуску на всю базу
Чіткого календарного строку тут немає — є стан сценарію. Головний сигнал готовності: чергова хвиля тестових дзвінків не приносить нових суттєвих правок, а лише підтверджує те, що вже працює.
Якщо після розширеної вибірки правки й далі трапляються часто — це сигнал не поспішати, а зробити ще один цикл прослуховування, перш ніж вмикати робота на всю базу.
Часті питання
Скільки дзвінків достатньо для тестового пілоту?
Універсальної цифри немає: для короткого сценарію з однією метою зазвичай вистачає кількох десятків дзвінків, щоб побачити основні патерни. Розгалужений сценарій вимагає ширшої вибірки, бо рідкісні гілки спрацьовують не одразу.
Що робити, якщо в записах багато незрозумілих відповідей клієнтів?
Спочатку виправте формулювання, які плутають найбільше клієнтів, і додайте гілки для типових відповідей, яких бракувало в сценарії. Рідкісні винятки можна відкласти до наступного циклу тесту.
Чи можна одразу масштабувати вдалий пілот на всю базу?
Краще розширювати вибірку поступово, повторюючи цикл прослуховування й правок. Один вдалий пілот на кількох десятках дзвінків ще не гарантує, що сценарій витримає все розмаїття реальної бази.
Хто повинен слухати записи тестових дзвінків?
Той, хто відповідає за сценарій і знає мету дзвінка, — менеджер продажів, власник процесу чи людина, яка налаштовувала робота. Стороння людина без контексту легко пропустить важливі деталі розмови.
R7K12 Voice — ШІ-робот для обдзвону лідів
Робот сам телефонує вашим лідам за секунди після заявки — кваліфікує, відповідає на питання й передає гарячих у вашу CRM.
Спробувати безкоштовно
Засновник R7K12 — сервісу наскрізної аналітики, CRM і автоматизації дзвінків. Пише про те, як бізнесу не втрачати ліди, швидше обробляти заявки й рахувати реальну окупність реклами.