Яку частку звернень справді може закрити ШІ-підтримка
Універсального «реального відсотка» звернень, які ШІ закриває без оператора, не існує. Цифри з кейсів постачальників можуть бути чесними, але вони стосуються конкретного потоку звернень, конкретного визначення «закрито» і конкретного способу рахувати. Перенести таку цифру на свою підтримку можна лише тоді, коли збігаються всі три складники, а це буває рідко.
Тому починати треба не з відсотка, а з трьох питань. Що ви вважаєте розв’язаним зверненням? Які звернення потрапили в знаменник? Чи враховано повторні контакти з тією самою проблемою? Після цієї статті ви зможете прочитати обіцянку постачальника так, щоб побачити, що за нею стоїть, вибрати звернення для пілота і виміряти результат на власних даних. А ще розрізнятимете дві різні речі, які часто змішують: ШІ, що допомагає оператору, і ШІ, що відповідає клієнту самостійно.
Що означає «закрито»: три різні події
Слово «закрито» в підтримці має щонайменше три значення, і вони дають дуже різні цифри.
Діалог завершився. Клієнт перестав писати. Це найлегше виміряти, але найменше говорить про результат. Людина могла отримати відповідь, а могла здатися, піти на сайт конкурента або набрати номер гарячої лінії.
Звернення не передали людині. У галузі це часто називають containment, тобто «утримання» звернення в боті. Метрика показує, що оператор не підключався. Вона не показує, чи отримав клієнт те, що йому було потрібно.
Клієнт підтвердив розв’язання. Людина відповіла «так, допомогло» або поставила позитивну оцінку. Це найближче до справжнього результату, але й тут є обмеження: підтверджують далеко не всі, і ті, хто підтверджує, можуть відрізнятися від тих, хто мовчить.
Є ще четверта подія, яку легко пропустити: повторне звернення. Якщо клієнт повернувся з тим самим питанням через день, попереднє «закрито» було хибним, хоч би як його порахували.
Коли хтось називає відсоток закриття, перше уточнення: яка з цих подій вважається закриттям і чи віднімаються повторні звернення.
Як читати цифри постачальників
Метрики ШІ-підтримки можуть мати різні знаменники й правила зарахування. Наприклад, один показник може рахувати лише розмови, у яких бот брав участь, а інший — усі нові звернення. Деякі системи зараховують розв’язання, коли клієнт явно погодився, а також коли він не попросив оператора й не заперечив. Це припущене розв’язання, а не пряме підтвердження.
Перш ніж порівнювати постачальників або переносити чужий результат у бізнес-план, запитайте:
- що в чисельнику: лише підтверджені, підтверджені й припущені чи всі закриті розмови;
- що в знаменнику: усі звернення, лише ті, у яких бот брав участь, чи окремі категорії;
- за який період і на якому потоці рахували;
- чи враховані повторні звернення та в якому часовому вікні;
- чи рахують передачі оператору окремо, і яку роль люди виконували в потоці;
- чи охоплює показник відповіді до отримання рішення, чи лише підтверджене завершення потреби.
Якщо бот охопив лише частину потоку, його частку розв’язаних звернень не можна називати часткою всіх звернень компанії. Перевірте обидва знаменники й окремо покажіть охоплення, підтверджені результати, припущені результати та повторні контакти.
Навчальний розрахунок: один потік, кілька різних відсотків
Числа в цьому прикладі вигадані для пояснення. Для кожної з 360 розмов, які бот позначив як розв’язані, минули повні сім днів спостереження; звернення наприкінці місяця враховано лише після завершення цього періоду. Інакше 320 розмов без повторного звернення не можна було б чесно порахувати.
| Показник | Кількість | Частка від звернень до бота (600) | Частка від усього потоку (1000) |
|---|---|---|---|
| Усі звернення за місяць | 1000 | 100% | |
| Звернення, які потрапили до бота | 600 | 100% | 60% |
| Бот позначив як розв’язані (підтверджені + припущені) | 360 | 60% | 36% |
| З них клієнт явно підтвердив розв’язання | 200 | 33% | 20% |
| З 360 «розв’язаних» клієнт повернувся з тим самим питанням протягом 7 днів | 40 | ||
| «Розв’язані» без повторного звернення | 320 | 53% | 32% |
Одна й та сама робота бота дає 60%, 53%, 36%, 33%, 32% або 20% залежно від того, що поділити на що. Арифметика правильна в кожному рядку, але висновок буде хибним, якщо 60% від звернень до бота подати як «ШІ закриває 60% звернень компанії». Так само важливо не приховувати 40 повторних контактів усередині загальної кількості позначених як розв’язані.
Арифметика: 360 / 600 = 60%; 360 / 1000 = 36%; 200 / 600 ≈ 33%; 200 / 1000 = 20%; 360 − 40 = 320; 320 / 600 ≈ 53%; 320 / 1000 = 32%.
Операторська допомога й автономне розв’язання — різні результати
ШІ може підтримувати клієнтський сервіс принаймні двома способами. У першому він підказує оператору: шукає інформацію, пропонує чернетку відповіді або допомагає дотримуватися процедури. Розмову веде людина, тож результат вимірюють на рівні роботи команди — наприклад, часом обробки, кількістю розв’язаних звернень на годину, якістю відповідей і повторними контактами.
У другому способі ШІ відповідає клієнту самостійно. Тут важливо окремо рахувати звернення, у яких система брала участь, передані оператору, підтверджені клієнтом і позначені як розв’язані без прямого підтвердження. Якщо клієнт замовк, це ще не доводить, що його питання вирішено.
Є також тестування агентів у симульованих сценаріях. Воно допомагає перевірити, чи система виконує інструкції, користується інструментами й дотримується заданих правил у контрольованих умовах. Такий тест корисний для пошуку помилок і нестабільної поведінки, але не вимірює частку успішних розв’язань у реальному потоці конкретної компанії.
Тому результати операторського помічника, симуляційного тесту й автономної підтримки не можна підставляти в одну формулу. Для бізнес-рішення потрібен власний пілот: на визначених категоріях, із перевіркою правильності відповіді, повторних контактів і передач оператору.
Які звернення брати в пілот
Пілот варто будувати на зверненнях, де результат можна однозначно перевірити. Добрі кандидати мають кілька спільних рис:
- часті й схожі між собою: статус замовлення, графік роботи, як змінити пароль, де знайти документ;
- мають стабільні правила: відповідь не залежить від настрою менеджера чи винятку для конкретного клієнта;
- мають джерело правди: статус береться з облікової системи, правило з актуальної бази знань;
- дозволяють перевірити результат: можна сказати, чи правильною була відповідь, не опитуючи клієнта.
Погані кандидати для першого пілота: скарги, повернення коштів з умовами, суперечки щодо рахунків, будь-що з персональними чи медичними даними, запити, де потрібне рішення з повноваженнями. Їх можна автоматизувати частково, наприклад збір інформації перед передачею оператору, але не як «закрито ботом».
Практичний спосіб відбору: візьміть звернення за останні кілька місяців, розкладіть за темами і для кожної теми оцініть частоту, стабільність правил і можливість перевірки. У пілот ідуть дві-три теми з високими оцінками за всіма трьома критеріями.
Навчальна таблиця відбору тем
Оцінки в таблиці умовні й вигадані для прикладу. Кожен критерій оцінюється від 1 до 3.
| Тема звернення | Частота | Стабільність правил | Можна перевірити відповідь | Рішення |
|---|---|---|---|---|
| Де моє замовлення | 3 | 3 | 3: статус є в обліковій системі | У пілот |
| Графік роботи й адреси | 2 | 3 | 3: дані на сайті | У пілот |
| Як змінити дані профілю | 2 | 3 | 2: залежить від інтерфейсу | У пілот після перевірки інструкцій |
| Повернення товару | 3 | 2 | 2: є винятки за станом товару | Бот збирає дані, рішення за оператором |
| Скарга на якість | 2 | 1 | 1: потрібна оцінка людини | Не в пілот |
| Суперечка щодо рахунку | 1 | 1 | 1: потрібні повноваження | Не в пілот |
Таблиця не підказує, скільки звернень бот закриє. Вона допомагає не почати з теми, де результат неможливо перевірити, а помилка коштує дорого.
Власна методика вимірювання
Щоб отримати цифру, якій можна довіряти, її доведеться виміряти самостійно. Ось мінімальна методика.
Визначте метрики до запуску. Запишіть, що є чисельником і знаменником кожної метрики, яке вікно для повторного звернення (наприклад, 7 днів) і як визначається «те саме питання». Не змінюйте визначення посеред пілота.
Рахуйте кілька метрик паралельно. Частку участі бота, частку закритих без оператора, частку підтверджених клієнтом, частку повторних звернень і частку переданих оператору. Окремо по кожній темі.
Розмічайте випадкову вибірку. Щотижня беріть випадкову вибірку розмов, які бот позначив як розв’язані, і давайте працівнику перевірити: чи правильна відповідь, чи повна, чи відповідає правилам. Без цього ви знаєте лише, що клієнт замовк, а не що відповідь була правильною.
Відстежуйте повторні контакти в усіх каналах. Клієнт, який не отримав відповіді в чаті, може подзвонити. Якщо телефонні звернення не пов’язуються з чатом, повторні контакти будуть недораховані.
Вимірюйте задоволеність окремо. Оцінка після розмови, скарги, частка клієнтів, які просили людину й не отримали її. Ці показники не повинні бути частиною формули розв’язання, їх читають поруч.
Перевіряйте якість передачі. Частина звернень неминуче піде до оператора. Подивіться, чи отримує оператор короткий опис проблеми і вже зібрані дані, чи клієнту доводиться повторювати все спочатку. Погана передача псує враження навіть тоді, коли сам бот відповідав правильно, і збільшує час роботи оператора над такими зверненнями.
Майте порівняння. Якщо можливо, порівняйте ту саму тему до і після запуску або ввімкніть бота для частини потоку випадковим чином. Інакше сезонні зміни можна прийняти за ефект бота.
Рішення про розширення
Розширювати ШІ-підтримку на нові теми варто тоді, коли пілот показав результат за кількома метриками одночасно, а не за однією. Розширення виправдане, якщо:
- частка підтверджених розв’язань і частка без повторних звернень стабільні протягом кількох тижнів;
- вибіркова перевірка показує прийнятний рівень помилок у відповідях;
- скарг на бота не більше, ніж було на відповідний канал раніше;
- оператори не отримують складніші звернення без контексту, тобто передача працює;
- економія часу операторів перевищує витрати на підтримку бази знань, перевірки й обробку помилок бота.
Останній пункт часто недооцінюють. Бот потребує людей: хтось оновлює базу знань, розбирає помилкові відповіді, налаштовує правила передачі. Ця робота має входити в розрахунок економії.
Якщо одна з метрик погіршилась після розширення, наприклад зросли повторні звернення в новій темі, поверніть тему в режим, де бот лише збирає інформацію для оператора, і з’ясуйте причину.
Висновок: як оцінити ШІ-підтримку на своєму потоці
- Зафіксуйте визначення: що таке розв’язане звернення, яке вікно повторного контакту, що в знаменнику.
- Порахуйте поточний потік звернень за темами і виберіть дві-три теми з частими, стабільними й перевірюваними запитами.
- Налаштуйте облік частки участі бота, закритих без оператора, підтверджених клієнтом, повторних і переданих звернень окремо.
- Щотижня розмічайте випадкову вибірку «розв’язаних» розмов.
- Пов’яжіть звернення з різних каналів, щоб бачити повторні контакти.
- Порівнюйте з періодом до запуску або з контрольною частиною потоку.
- Розширюйте лише ті теми, де стабільні всі метрики, і рахуйте повну вартість підтримки бота.
- Цифри чужих кейсів використовуйте лише разом із їхніми визначеннями, а не як прогноз для себе.
Часті запитання
Ні. Containment показує, що звернення не передали людині. Resolution rate залежить від визначення постачальника: він може включати підтверджені клієнтом розв’язання і припущені, коли клієнт не попросив людину й не висловив незгоди. Відсутність передачі оператору ще не доводить, що питання клієнта розв’язано: людина могла піти або звернутися іншим каналом.
Так. Повторний контакт з тим самим питанням є одним із найкращих сигналів хибного закриття. Але вікно часу (день, тиждень) і правило, що вважається «тим самим питанням», треба визначити заздалегідь і не змінювати під час вимірювання. Також варто пов’язувати звернення з різних каналів, інакше частину повторних контактів не буде видно.
Лише як результат конкретного проєкту з його визначеннями, вибіркою та потоком звернень. Якщо кейс показує високий відсоток, з’ясуйте знаменник, тип розв’язання, період і категорії. Навіть за повного збігу визначень інший бізнес має інші запити, правила й клієнтів, тому чужа цифра може бути орієнтиром для питань, але не обіцянкою результату.
Консультація з пілота ШІ-підтримки
За 15 хвилин із фахівцем BotLabs з AI-впроваджень обговоримо одну категорію звернень, ознаки розв’язання та повторні контакти. Визначимо, які дані зібрати для пілота, щоб оцінити результат на вашому потоці.
Звернення
Критерії пілота
15 хвилин із фахівцем: оберемо категорію звернень і дані для перевірки розв’язань та повторних контактів.
