Як не допустити, щоб AI-чат-бот зіпсував роботу служби підтримки клієнтів: приклад туристичної компанії

AI-чат-бот рідко порушує процес тому, що він «поганий». Найчастіше йому просто не пояснили, де закінчується консультація і починається дія, яка вимагає точних даних або рішення співробітника. Якщо бот одночасно має відповідати на запитання, підбирати тур, обіцяти наявність місць, розраховувати вартість та оформлювати заявку, але не знає меж, він починає заповнювати прогалини здогадками.

Нижче розглянемо проєкт для туристичної компанії, яка приймає запити через сайт, Telegram та Viber. Для неї було розроблено керованого AI-консультанта: він допомагає клієнту з вибором поїздки, працює лише з дозволеними даними та передає менеджеру рішення, які потребують підтвердження.

Чому AI-бот без обмежень починає припускатися помилок

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

Проблема загострюється, коли в одній інструкції поєднуються несумісні очікування: «відповідай коротко», «будь максимально корисним», «продавай активніше», «ніколи не відмовляй клієнту». Бот бачить мету, але не розуміє пріоритетів. У результаті він може впевнено назвати застарілу ціну, пообіцяти раннє заселення без підтвердження або приховати сумнів за переконливим формулюванням.

Початкове завдання туристичної компанії

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

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

Структура інструкції: сім обов’язкових рівнів

1. Роль та кількісно вимірювана мета

Замість абстрактного «ти — менеджер» визначаємо конкретну функцію: початковий AI-консультант туристичної компанії. Його результат — не продаж за будь-яку ціну, а коректно оброблений запит: клієнт отримав зрозумілу відповідь, а менеджер — заявку з напрямком, датами, кількістю мандрівників, бюджетом та важливими побажаннями.

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

2. Дозволені джерела даних

В інструкції зазначено, звідки можна брати факти. Для туристичного бота це можуть бути актуальний каталог пропозицій, система бронювання, затверджена база знань, пам’ятки компанії та дані конкретної заявки з CRM. Відповіді із загальної пам’яті моделі дозволяються лише для нейтральних пояснень, які не змінюють умови покупки.

• Ціна та наявність — лише з системи бронювання із зазначенням часу перевірки.
• Правила в’їзду та візові питання — із затвердженої пам’ятки із зазначенням дати оновлення та рекомендацією перевірити офіційне джерело.
• Умови оплати та скасування — у договорі або в базі знань компанії.
• Історія клієнта — лише з тієї частини CRM, до якої має доступ бот, і лише в межах поточного звернення.

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

3. Явні заборони

Заборони краще формулювати у вигляді конкретних дій, а не розпливчастого «не помиляйся». У туристичному сценарії бот не повинен:

• визначати маршрут, готель, рейс, ціну, знижку або наявність місць;
• підтверджувати бронювання до отримання відповіді від системи та перевірки менеджером;
• обіцяти візу, в’їзд до країни або результат розгляду документів;
• просити надіслати номер паспорта, банківські реквізити або повний пакет документів у відкритому чаті;
• самостійно змінювати дані клієнта в CRM без підтвердження;
• приховувати відсутність інформації фразами на кшталт «найімовірніше, все буде добре».

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

4. Послідовність діалогу

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

1. Зрозуміти, що потрібно клієнту: підбір поїздки, питання щодо існуючого бронювання або консультація щодо документів.
2. Перевірити, які дані вже є у повідомленні та в CRM, щоб не запитувати їх знову.
3. Для нового туру уточнити напрямок або уподобання, дати, місто вильоту, склад учасників та орієнтовний бюджет.
4. Показати не більше трьох релевантних варіантів і пояснити відмінності, використовуючи прості критерії.
5. З’ясувати, який варіант підходить більше, та оформити заявку для менеджера.
6. Перед відправленням ще раз перевірити основні параметри та отримати підтвердження від клієнта.

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

Як визначити характер і стиль на основі старих діалогів

Старі листування корисні не як величезна папка, яку моделі завантажують без розбору. З них потрібно виокремити сталі правила спілкування: довжину відповіді, допустимий рівень емоційності, звичні формулювання, спосіб ставити уточнювальні запитання та реакцію на складні ситуації.

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

Профіль спілкування для бота налаштували так:

• тон спокійний, доброзичливий і діловий, без фамільярності;
• звернення на «Ви», ім’я вживається лише у тому випадку, якщо клієнт сам його повідомив;
• відповідь зазвичай складається з двох–чотирьох коротких абзаців;
• емодзі допускаються рідко і лише нейтральні;
• спочатку пряма відповідь, потім уточнювальне запитання;
• не застосовувати тиск, штучну терміновість та фрази на кшталт «ідеальний варіант для всіх»;
• у разі негативної реакції визнати незручність, не сперечатися та швидко залучити співробітника.

Коли бот повинен передати діалог людині

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

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

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

Тестування перед запуском та контроль після нього

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

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

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

Як виглядала інструкція з експлуатації

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

Роль: первинний AI-консультант туристичної компанії.

Мета: відповісти на безпечні довідкові запитання та підготувати
структуровану заявку для менеджера.

Пріоритети: точність → безпека → корисність → швидкість.

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

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

Став по одному уточнювальному запитанню та не повторюй уже відоме.
Перед створенням заявки повтори дати, склад поїздки та бюджет.

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

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

Що в підсумку отримує туристична компанія

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

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

Головний ефект тут полягає не в тому, що ШІ відповідає на все. Навпаки: цінність виникає тоді, коли система добре розуміє, що вона вміє, чого не знає і коли має зупинитися.

Короткий перелік питань перед запуском AI-бота

1. Роль та результат діалогу описані конкретно.
2. Для кожного типу фактів вказано дозволене джерело.
3. Заборонені дії перелічені разом із безпечною альтернативою.
4. Визначено порядок питань та підтвердження перед записом даних.
5. Стиль ґрунтується на об’єктивних, якісних діалогах, а не на всій історії в цілому.
6. Існують чіткі умови передачі людині та формат резюме.
7. Підготовлено набір звичайних, складних та провокаційних тестів.
8. Призначено відповідального за перегляд діалогів та оновлення правил.

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