Чат-бот плюс живий менеджер. Як розділити роботу і не втратити клієнта на передачі

Суперечка про те, чи потрібен бот, зазвичай точиться не там. Ботів ненавидять не за автоматизацію, а за момент, коли людина 4 рази намагається пояснити проблему, не отримує нічого осмисленого і не може докликатися живого співробітника. Нижче критерій розподілу питань, 4 тригери передачі діалогу людині, таблиця зон відповідальності та розбір ситуацій, де бот не окупиться взагалі.

Головне зі статті:

• Питання віддають боту, якщо в нього є єдина правильна відповідь, відома заздалегідь

• Кнопка виклику людини присутня в першому ж повідомленні, і це знижує частоту її використання, а не підвищує

• Передача вважається успішною лише тоді, коли менеджер бачить передісторію і клієнту не доводиться повторювати

• Нічний бот окупається швидше за денний, бо вночі альтернатива не менеджер, а тиша

• Частка автоматично закритих звернень зростає і при поганому сценарії, тому оцінювати за нею небезпечно

• Сценарій, написаний з голови, застрягає на розпізнаванні 40% звернень

Критерій розподілу питань між ботом і людиною

Робочий критерій один. Якщо в питання є єдина правильна відповідь, відома заздалегідь, його віддають боту. Якщо відповідь залежить від ситуації, настрою або суми, її залишає людина.

Перевіряється просто. Візьміть 200 останніх звернень і розсортуйте за цією ознакою. Зазвичай від 40 до 60% потрапляють у першу категорію, і це той обсяг, який знімається з менеджерів.

Таблиця зон відповідальності

Складена нами за підсумками розбору типових потоків звернень у роздрібі та сервісі.

Другий критерій відсікає питання з дорогою помилкою

Навіть питання з єдиною відповіддю віддають людині, якщо помилка у відповіді дорого коштує. Строки гарантійного ремонту, умови повернення коштів, рекомендації щодо застосування.

Тут автоматика припустима в інформаційному вигляді з посиланням на спеціаліста, але не як остаточна відповідь.

Бот кваліфікує, але не продає

Спроба провести людину сценарієм продажу автоматично дає гірший результат, ніж коротка розмова з менеджером.

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

Точка передачі діалогу людині

Введемо робоче поняття. Точка передачі — це момент, у який бот припиняє обробку і діалог іде людині разом з усією зібраною передісторією. Якість схеми визначається не сценарієм бота, а тим, як влаштована ця точка.

4 тригери, за якими бот зобов’язаний віддати діалог

Клієнт попросив напряму. Бот 2 рази поспіль не зрозумів питання. У повідомленні є ознаки невдоволення. Тема стосується грошей або скарги.

Два рази, а не три і не п’ять. Кожна наступна невдала спроба зменшує шанс, що клієнт дочекається людини.

Кнопка виклику менеджера має бути в першому ж повідомленні. Практика показує ефект, зворотний до побоювань компаній, — коли вихід видно, ним користуються рідше, бо зникає відчуття пастки.

Менеджер отримує діалог разом із передісторією або схема не працює

Тут проходить межа між робочою і неробочою схемою. Якщо менеджер починає з «розкажіть, що у вас сталося», уся економія часу обнуляється, а клієнт злиться.

Правильно, коли переписка з ботом пишеться в ту саму картку клієнта, що й подальша розмова. Менеджер відкриває картку, читає 6 рядків і продовжує з середини.

Саме тому зв’язка бота з CRM важливіша за вибір самого бота. Підключений до системи номер месенджера забезпечує єдину стрічку діалогу незалежно від того, хто відповідав у конкретний момент.

Зворотна передача потребує окремого правила

Сценарій, про який забувають. Менеджер розв’язав питання, діалог закрито, але через 2 дні клієнт пише знову з іншого приводу.

Розумне правило таке. Якщо попереднє звернення було скаргою, наступне одразу йде до людини. У всіх інших випадках бот працює як завжди.

Експертна врізка

Найстійкіша помилка при впровадженні — сценарій пишуть виходячи з того, як компанія уявляє собі питання клієнтів, а не з того, як ці питання ставляться насправді. Люди пишуть «а коли приїде», а не «уточніть статус доставки замовлення». Для українських компаній додається ще один шар — частина клієнтів пише російською, частина українською, а частина змішує обидві мови в одному реченні. Сценарій, зібраний лише з однієї мовної вибірки, втрачає добру третину звернень. Єдиний надійний спосіб побудувати робочий сценарій — взяти вивантаження з 300 реальних діалогів і зібрати формулювання звідти дослівно, включно з друкарськими помилками, скороченнями і суржиком. Компанії, які роблять цей крок, отримують частку розпізнаних звернень вище 80% з першої версії. Компанії, що пишуть сценарій з голови, застрягають на 40% і потім пів року правлять його за скаргами.

Ніч, вихідні та пікові періоди

Нічний бот окупається швидше за денний

Удень альтернатива боту — менеджер, і клієнт порівнює автоматику з живою людиною не на її користь. Уночі альтернатива — тиша до ранку, і тут будь-яка осмислена відповідь виграє.

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

Відповідати по суті він не зобов’язаний. Достатньо 3 функцій — прийняти звернення, зафіксувати його в CRM, назвати конкретний час відповіді вранці.

Пікове навантаження готують за місяць, а не в сезон

У сезон потік звернень зростає в рази, і бот працює як буфер. Він знімає довідкові питання, через які менеджери не встигають відповідати готовим купити.

Сценарій, увімкнений у розпал сезону, гарантовано містить помилки, які нікому виправляти. Запускайте заздалегідь.

На свята бот замінює оголошення на дверях

Окремий випадок. Повідомлення з датами роботи, приймання заявок у чергу і зрозумілий план розбору після вихідних.

Клієнту тут не потрібен діалог, йому потрібна визначеність. Одне точне повідомлення працює краще за складний сценарій.

Обмеження для сфер із цілодобовими зобов’язаннями

Нічна автовідповідь незастосовна там, де звернення може бути терміновим по суті — аварійні служби, медичні питання, охорона, технічна підтримка з договірним часом реакції. У цих сферах бот припустимий лише як маршрутизатор до чергового, а не як спосіб відкласти відповідь до ранку.

Оцінка якості сценарію

4 показники, які знімають разом

Частка звернень, закритих без участі людини. Ізольовано вона беззмістовна, дивитися потрібно в парі з наступним показником.

Частка клієнтів, які звернулися повторно з того самого питання. Саме вона показує, чи було питання розв’язане, чи клієнт здався.

Час до передачі людині. Понад 3 хвилини означає перевантажений сценарій.

Оцінка після діалогів із передачею порівняно з оцінкою діалогів без бота. Від’ємна різниця вказує на проблему в точці передачі, а не в самому боті.

Частка автоматизації зростає і при поганому сценарії

Показник збільшується у 2 різних випадках. Коли бот добре розв’язує питання і коли клієнти перестають чекати та йдуть.

Відрізнити одне від іншого можна лише через повторні звернення і через виручку. Частка автоматизації зросла, а кількість замовлень впала — отже, ви автоматизували не підтримку, а відмову від спілкування з вами.

Сценарій переглядають раз на місяць

Переглядайте діалоги, де бот не зрозумів питання. Кожен такий випадок — або нове формулювання, або нова гілка.

За пів року сценарій зазвичай зростає вдвічі, а частка незрозумілих звернень падає до одиниць відсотків. Без перегляду відбувається зворотне — мова клієнтів змінюється, а бот лишається колишнім.

Коли бот не потрібен

Економія на операторах не настає при малому потоці

Теза звична — бот знімає навантаження з підтримки. Контртеза така. Сценарій потрібно написати, перевірити і потім щомісяця правити, і ця робота не зникає після запуску.

Обмеження звідси таке. При потоці нижче 30 звернень на день повноцінний сценарій не окупається, бо вартість підтримки сценарію порівнянна з вартістю ручної обробки. Висновок для практики — почніть із нічної автовідповіді з фіксацією заявки і подивіться, скільки звернень приходить поза графіком.

Однорідний складний продукт погано лягає на сценарій

Якщо 80% звернень потребують розрахунку, підбору або консультації, автоматизувати нема чого. Бот у такій ніші виконає лише ідентифікацію, і його цінність зводиться до економії 30 секунд.

Тут розумніше вкластися в шаблони відповідей для менеджерів і у швидкість розподілу вхідних.

Чого ми не вимірювали

Поріг у 30 звернень на день наведено як орієнтир, а не як виміряну величину. Він зміщується залежно від вартості години співробітника і від частки повторюваних питань, тому рахувати потрібно за своїми цифрами.

Також ми не розбираємо сценарії з генеративними моделями, де відповідь формується на льоту. Їхня поведінка при нестандартних зверненнях потребує окремої перевірки, і переносити на них правила з цієї статті передчасно.

ЧаПи:

Питання: Чи обов’язково попереджати клієнта, що він спілкується з ботом

Відповідь: Так, і це в інтересах компанії. Клієнт, який дізнався про це в середині розмови, почувається обманутим. Одна фраза на початку знімає питання, а на готовність спілкуватися майже не впливає

Питання: Чи можна використовувати бота на тому самому номері, де працюють менеджери

Відповідь: Так, це і є робоча схема. Клієнт бачить один контакт компанії, а всередині діалог передається між автоматикою і людьми. Розділяти номери має сенс лише при дуже великому обсязі однотипних звернень

Питання: Що робити, якщо бот дав клієнту невірну інформацію

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

Питання: Чи потрібен бот компанії з потоком менше 30 звернень на день

Відповідь: Повноцінний сценарій не окупиться, а нічна автовідповідь із фіксацією заявки цілком. Починати варто з неї

Питання: Як бот впливає на обмеження месенджерів

Відповідь: Бот, що відповідає, працює всередині діалогів, які почав клієнт, і ризиків не створює. Обережність потрібна там, де автоматика ініціює переписку з тими, хто вам ще не писав