Як клієнти ставляться до ШІ-ботів і що робить спілкування зручним
Щоб оцінити спілкування клієнта з ШІ-ботом, перевіряйте, чи розв'язано його задачу і чи легко перейти до людини, коли бот не впорався. Важливо також чесно представити помічника: хто відповідає, що він уміє, чого не вміє і як перейти до співробітника. Дані про те, що розкриття природи бота знижувало продажі, існують, але вони отримані в дуже конкретних умовах і не є підставою приховувати ШІ. До того ж у ЄС з 2 серпня 2026 року діють вимоги прозорості AI Act щодо систем, які спілкуються з людьми.
Після статті ви зможете написати чесне вітальне повідомлення бота, визначити правила передачі розмови співробітнику і вибрати метрики, які покажуть роздратування клієнтів без здогадок.
Що насправді дратує клієнта
Коли клієнт пише «дайте мені живу людину», перевірте, чи не зіткнувся він із однією з таких ситуацій.
Бот не розуміє запит. Клієнт формулює питання своїми словами, а бот відповідає на інше або пропонує нерелевантне меню. Після двох-трьох таких відповідей терпіння закінчується.
Доводиться повторювати. Клієнт уже назвав номер замовлення, описав проблему, а після передачі оператору його просять зробити те саме знову. Повторення сприймається як ознака того, що компанія не цінує його час.
Бот не може розв'язати задачу, але не зізнається в цьому. Відповідь виглядає ввічливо і впевнено, але нічого не змінює: повернення не оформлене, статус не з'ясований, а розмова формально «закрита».
Немає шляху до людини. Кнопки «зв'язатися з оператором» немає, вона захована, або бот кілька разів намагається «допомогти самостійно», перш ніж дозволити передачу.
Ці проблеми можуть виникати через слабкий сценарій, відсутність доступу до потрібних даних і погано продуману передачу. Звідси практичний висновок: перш ніж обговорювати, як «подати» бота, варто перевірити, чи він справді допомагає у сценаріях, для яких його запущено.
Що показує польовий експеримент — і де межі висновку
В одному польовому експерименті понад 6 200 клієнтів фінансової компанії випадково отримували структуровані вихідні продажні дзвінки від бота або людини. Коли бот не повідомляв про свою природу до розмови, результат продажів був приблизно на рівні досвідчених працівників і приблизно вчетверо вищим, ніж у недосвідчених. Попереднє повідомлення, що телефонує бот, супроводжувалося зниженням частки покупок більш ніж на 79,7%. Ефект був меншим за пізнішого розкриття та серед клієнтів, які раніше взаємодіяли зі ШІ. Клієнти, які знали, що говорять із ботом, розмовляли коротше й оцінювали його як менш обізнаного та емпатійного.
Чому цей результат не можна переносити на сучасну підтримку:
- це вихідні продажні дзвінки, а не вхідні звернення клієнта, який сам шукає допомоги;
- це структурований голосовий сценарій продажу, а не розв'язання проблеми із замовленням;
- дані зібрано до масового поширення генеративних моделей, і ставлення людей до ШІ-співрозмовників з того часу могло змінитися — це окреме питання, яке вимагає нових даних;
- метрикою була покупка, а не розв'язання задачі чи задоволеність.
І найважливіше: дослідження описує, як люди реагували, а не дає дозволу вводити їх в оману. Стратегія «розкривати пізніше» з цього експерименту не сумісна з вимогами там, де застосовується стаття 50 AI Act: за нею інформація має надаватися щонайпізніше під час першої взаємодії.
Що саме вимагає стаття 50. Постачальники ШІ-систем, призначених для безпосередньої взаємодії з людьми, мають проєктувати їх так, щоб люди знали, що спілкуються зі ШІ, якщо це не очевидно для обізнаної, уважної та розважливої людини. Обов'язки прозорості застосовуються з 2 серпня 2026 року. Чи поширюється AI Act на ваш бізнес, хто у вашому ланцюгу є постачальником системи і в якій формі має бути розкриття — питання для юридичної перевірки. Але навіть там, де закон прямо не вимагає розкриття, приховування ШІ створює ризик втрати довіри, коли клієнт це виявить.
Як представити помічника: роль, межі, вихід до людини
Хороше представлення бота відповідає на три питання клієнта ще до того, як він їх поставить: «з ким я говорю», «з чим мені тут допоможуть» і «що робити, якщо не допоможуть».
Навчальний приклад: вітання і два шляхи розмови
Текст і сценарій нижче — редакційний зразок, а не готове юридичне формулювання і не опис реального проєкту.
Вітання:
> «Я ШІ-помічник сервісу. Допоможу знайти інформацію про ваше замовлення, доставку й повернення. Якщо питання потребуватиме рішення співробітника, я передам розмову разом з усім, що ви вже розповіли».
Шлях 1: простий статус замовлення. Клієнт пише: «Де моє замовлення 4512?» Бот перевіряє, що клієнт авторизований і замовлення належить йому, читає статус з облікової системи і відповідає: «Замовлення передано службі доставки вчора, очікувана дата — четвер. Надіслати номер для відстеження?» Розмова закінчується, коли клієнт отримав відповідь, а не коли бот вирішив, що «все зрозуміло».
Шлях 2: суперечка щодо повернення. Клієнт пише: «Мені відмовили в поверненні, але товар прийшов пошкоджений». Бот не сперечається і не обіцяє рішення, на яке не має повноважень. Він уточнює кілька фактів — номер замовлення, що саме пошкоджено, чи є фото, — і пояснює: «Рішення щодо повернення ухвалює співробітник. Я передаю йому вашу розмову, номер замовлення й фото, повторювати нічого не доведеться». Оператор отримує картку з уже зібраними даними і продовжує з того місця, де зупинився бот.
У цьому прикладі бот не прикидається людиною, чесно називає межі своїх повноважень і робить передачу корисною, а не формальною.
Чого не варто писати у вітанні
Деякі формулювання здаються дружніми, але створюють хибні очікування, які потім обертаються роздратуванням:
- «Допоможу з будь-яким питанням». Бот, який не вміє оформлювати повернення, після такої обіцянки розчаровує сильніше, ніж бот, який одразу назвав свої межі.
- «Зараз з'єднаю з менеджером», якщо в цей час операторів немає. Краще чесно: «Співробітники працюють з 9:00 до 18:00. Я збережу ваше питання, і вам відповідять у робочий час».
- «Я все розумію» чи інші заяви про емоції та розуміння, які клієнт може сприйняти як імітацію людини.
- Довгий перелік можливостей. Три-чотири найчастіші задачі достатньо; решту бот може запропонувати, коли зрозуміє запит.
Окреме питання — ім'я. Бот може мати ім'я, якщо воно не створює враження, що це співробітник. «Помічник Аліса» з поясненням «я ШІ-помічник» — прийнятно. Ім'я й аватар реальної людини без пояснення — ні.
Як зберегти контроль за клієнтом
Клієнт почувається комфортно, коли розуміє, що відбувається, і може це змінити. Для ШІ-бота це означає кілька конкретних механізмів.
Уточнення замість здогадок. Якщо запит неоднозначний, бот перепитує: «Ви маєте на увазі повернення коштів чи заміну товару?» — замість того, щоб обрати варіант навмання.
Підтвердження перед дією. Перш ніж скасувати замовлення, змінити адресу чи оформити заявку, бот показує, що саме зробить, і просить підтвердити.
Виправлення відомостей. Якщо бот неправильно зрозумів номер, дату чи суму, клієнт може це виправити одним повідомленням, і виправлене значення використовується далі.
Зрозуміла ескалація. Шлях до людини доступний у будь-який момент і не вимагає «пройти» кілька кроків з ботом. Клієнт знає, що відбудеться далі: чат з оператором зараз, відповідь у робочий час чи зворотний дзвінок. Якщо оператори недоступні, бот прямо це повідомляє, а не імітує очікування.
Чесність щодо невпевненості. Коли бот не має даних, він каже «я не знайшов цієї інформації», а не формулює правдоподібну відповідь.
Як виміряти досвід без здогадок
Найпоширеніша пастка — вважати, що якщо клієнт не попросив людину і не поскаржився, він задоволений. Деякі платформи підтримки рахують розмову розв'язаною не тільки тоді, коли клієнт прямо це підтвердив, а й тоді, коли він не просив оператора і не відповів негативно протягом короткого часу. Наприклад, одна платформа підтримки автоматично позначає розмову як «припущено розв’язану» через три хвилини, якщо клієнт не попросив людину й не відреагував негативно. Такий показник корисний для обліку навантаження, але не замінює вимірювання задоволеності: клієнт міг просто піти.
Метрики, які варто відстежувати разом:
| Метрика | Що показує | На що звернути увагу |
|---|---|---|
| Підтверджене розв'язання | Клієнт сам відповів, що питання вирішено | Окремо від припущеного розв'язання |
| Повторне звернення з тієї ж теми | Бот формально «закрив», але проблема лишилася | Вікно підрахунку визначте заздалегідь, наприклад 72 години чи 7 днів |
| Запит на оператора | Де бот не впорався або клієнт йому не довіряє | Аналізуйте, на якому кроці розмови виникає запит |
| Відмова від розмови | Клієнт пішов без відповіді | Порівнюйте з тими самими сценаріями до запуску бота |
| Час очікування оператора після передачі | Чи передача справді допомагає | Довге очікування після бота дратує сильніше, ніж очікування без бота |
| Оцінка після розв'язання | Суб'єктивне враження | Опитуйте після завершення задачі, а не після першої відповіді бота |
| Скарги | Найсерйозніші провали | Розбирайте вручну, а не лише рахуйте |
Порівнювати варто співставні сценарії: статус замовлення з ботом і без бота, а не «бот» у цілому з «операторами» в цілому. Оператори часто отримують складніші звернення, тому пряме порівняння їхніх оцінок з оцінками бота некоректне.
Як покращувати сценарій
Покращення ШІ-бота — це робота з конкретними проблемами в конкретних розмовах, а не загальне «налаштування тону».
Порядок роботи:
- Зберіть провальні розмови. Ті, що закінчилися запитом оператора, відмовою, повторним зверненням чи скаргою. Розбирайте їх регулярно і вибірково, з різних сценаріїв.
- Визначте тип проблеми. Бот не зрозумів запит; не мав доступу до потрібних даних; дав неправильну відповідь; не мав повноважень, але не передав розмову; передав, але оператор не отримав контексту.
- Змініть одну річ. Додайте джерело даних, змініть правило ескалації, перепишіть відповідь для певного типу запитів — і зафіксуйте, що саме змінено і коли.
- Перевірте ефект на тому самому сценарії. Порівняйте метрики до і після зміни для того самого типу звернень і за порівнянний період. Якщо обсяг малий, збирайте дані довше, ніж хочеться, щоб не прийняти випадкове коливання за покращення.
- Перевірте, чи не погіршилось інше. Нове правило ескалації може зменшити скарги, але збільшити навантаження на операторів. Це теж треба бачити.
Навчальна ілюстрація одного циклу (вигадана ситуація): під час розбору з'ясувалося, що клієнти часто просять оператора після питання «коли повернуть гроші». Причина — бот не має доступу до статусу повернення і відповідає загальною фразою про строки. Команда підключає до бота статус повернення з облікової системи і змінює лише цю відповідь. Через кілька тижнів порівнюють для цього типу звернень частку запитів оператора, повторних звернень і підтвердженого розв'язання з тим самим періодом до зміни. Якщо запитів оператора поменшало, але скарг стало більше, зміну переглядають, а не вважають успіхом лише за одним показником.
Що зробити на своєму процесі
- Перепишіть вітання бота так, щоб воно називало роль, межі можливостей і спосіб перейти до людини.
- Зробіть вихід до оператора доступним у будь-який момент і поясніть клієнту, що буде далі.
- Передавайте зібраний контекст разом із розмовою, щоб клієнт не повторював історію.
- Розділіть підтверджене і припущене розв'язання у звітах і додайте повторні звернення та запити оператора.
- Щотижня розбирайте вибірку провальних розмов і класифікуйте причини.
- Змінюйте по одній речі і перевіряйте ефект на тих самих сценаріях.
- Попросіть юриста оцінити, чи застосовується до вас стаття 50 AI Act або інші вимоги щодо розкриття, і в якій формі.
Часті запитання
Рекомендуємо так, від першого повідомлення: зрозуміла роль бота знижує непорозуміння і зберігає довіру. Чи є це юридичним обов'язком саме для вашої компанії і в якій формі, залежить від застосовного права: у ЄС стаття 50 AI Act вимагає інформувати людей про взаємодію зі ШІ, якщо це не очевидно, а обов'язки прозорості застосовуються з 2 серпня 2026 року. Застосовність до вашого випадку варто перевірити з юристом.
Можна, якщо ім'я не створює хибного враження, що з клієнтом спілкується співробітник. Поруч з іменем має бути зрозуміло, що це ШІ-помічник. Для зручності клієнта важливіші не ім'я, а чітка роль, межі можливостей і доступна передача оператору.
Через поведінкові та прямі сигнали: відмови від розмови, повторні звернення з тієї ж теми, запити оператора, скарги, оцінки після розв'язання задачі та частку підтвердженого розв'язання. Порівнюйте співставні сценарії до і після змін. Не вважайте відсутність скарги ознакою задоволеності. Якщо ви плануєте ШІ-помічника для клієнтів або хочете зрозуміти, чому чинний бот дратує людей, команда BotLabs може разом з вами розібрати один сценарій: які звернення приходять, що бот має право робити сам, коли й з якими даними передає розмову співробітнику. За коротку консультацію визначимо, з якого сценарію почати і що вимірювати, щоб бачити реальний досвід клієнтів.
Консультація з передачі від бота до людини
За 15 хвилин із фахівцем BotLabs з AI-впроваджень обговоримо один тип звернень: де бот перестає допомагати, як клієнт викликає оператора і що відбувається далі. Визначимо перше правило передачі та показник, за яким перевірити зміну.
Запит клієнта
Передача людині
15 хвилин із фахівцем: оберемо правило передачі людині й показник для перевірки одного типу звернень.
