Коли власник малого бізнесу в Польщі думає про впровадження ШІ для обробки телефонних дзвінків, зазвичай виникає той самий страх: «якийсь робот буде розмовляти з моїм клієнтом, він його розізлить, все заплутає, і я втрачу цього клієнта назавжди». Це зрозуміло — кожен з нас мав роздратовану розмову з автоматом, який не розумів, що ми говоримо, і замість допомоги лише погіршував ситуацію. Добре налаштований сценарій ШІ — це не робот, який заважає процесу, а впорядкований процес, який веде розмову через ті самі кроки, що досвідчений ресепшн, тільки без втоми, без пропуску інформації та без втрати деталей.
У цій статті я розберу один типовий сценарій — запис на прийом — на конкретні кроки: від першого звуку, який чує клієнт, до моменту, коли запис з'являється в календарі та CRM. Покажу також, де в цьому процесі може втрутитися людина і чому ці точки прийняття рішень важливі як для якості обслуговування, так і для відповідності вимогам — бо з 2 серпня 2026 року AI Act накладає конкретні вимоги прозорості на системи, з якими спілкується людина. Ти побачиш точно, що говорить клієнт, що відповідає система, і коли — точніше, взагалі чи — потрібна людина.
Після прочитання ти знатимеш, як виглядає повний хід розмови ШІ з клієнтом, які рішення приймає система на кожному етапі і де варто зберегти контроль людини, щоб обслуговування було і ефективним, і безпечним.
Хід розмови: від дзвінка до запису в календарі
Розмова з ШІ-ресепшн — це не один безперервний діалог, а послідовність чітких етапів, кожен з яких має свою мету і свої правила. Нижче представлено повний хід для сценарію запису на прийом — найчастішого випадку в малому бізнесі послуг.
- 01дзвінок
- →02відповідь
- →03ціль
- →04дані
- →05вікно
- →06підтвердження
Це шість кроків, кожен з яких може проходити по-різному залежно від того, чого саме хоче клієнт і як він реагує. Нижче я розглядаю кожен з цих кроків окремо.
Крок 1 — привітання та представлення системи
Перші кілька секунд розмови визначають весь дальший хід. Клієнт, який чує незнайомий голос, має знати, з ким розмовляє. Тут з'являється вимога з AI Act — регламенту, який з 2 серпня 2026 року накладає на постачальників і користувачів систем ШІ конкретні обов'язки прозорості.
З 2 серпня 2026 року діють вимоги прозорості AI Act: особа, яка використовує систему ШІ, має бути чітко проінформована про те, що вона взаємодіє з машиною, якщо це не є очевидним. Це стосується, зокрема, чат-ботів, віртуальних асистентів та автоматизованих систем обслуговування користувачів Міністерство цифровізації, gov.pl, 03.08.2026.
Це означає, що привітання не може звучати як голос живої людини — система має чітко сказати, що це автоматизована ресепшн. Прикладне привітання може виглядати так:
«Добрий день, ви дзвоните до [назва компанії]. З вами говорить автоматизована ресепшн. Чим я можу допомогти?»
Це лише дві або три прості фрази. Це не місце для довгих пояснень — система говорить, хто вона, і відразу запрошує до розмови. Деталі того, що саме говорить система в привітанні — це окрема тема налаштування, але принцип один: клієнт з першої секунди знає, що розмовляє з машиною. Йому не потрібно здогадуватися, не потрібно питати «а ви там», не потрібно відчувати, що щось приховується.
Що робить система на цьому кроці
Система відповідає на дзвінок після одного або двох гудків — тут немає місця для очікування, бо кожна секунда тиші збільшує ризик, що клієнт покладе трубку. У фоні система вже знає, яка компанія обслуговує цей номер, які послуги пропонує та які у неї години роботи. Якщо клієнт дзвонить поза годинами роботи, система може відразу перейти до процедури нічного режиму — але про це в дальшій частині.
Крок 2 — визначення мети дзвінка
Коли клієнт вже знає, з ким розмовляє, наступний природний крок — зрозуміти, чого він хоче. Не кожен дзвонить, щоб записатися на прийом — деякі хочуть перенести час, інші скасувати, ще інші мають питання про послугу або скаргу. Система має розрізняти ці наміри і обробляти кожен по-іншому.
У цьому місці з'являється класифікуюче питання: «Чим я можу допомогти?» або «Скажіть, з чим ви дзвоните». Клієнт відповідає вільно, а система аналізує відповідь і відносить її до однієї з категорій.
| Мета дзвінка | Що робить система | Коли передає людині |
|---|---|---|
| Запис на прийом | Переходить до збору даних і пропонує вільні вікна | Коли клієнт хоче дату, яку система не бачить у календарі |
| Перенесення часу | Знаходить існуючий запис і питає про нову дату | Коли зміна стосується багатьох параметрів одночасно |
| Скасування прийому | Скасовує запис і відправляє підтвердження | Коли клієнт називає неясну причину |
| Питання про послугу | Відповідає на основі введеної інформації про компанію | Коли питання виходить за рамки введених даних |
| Скарга | Приймає звернення і передає на обробку | Завжди — скарга вимагає людської реакції |
| Термінова справа | Перенаправляє негайно | Завжди — термінові справи не проходять через автомат |
Ця відмінність ключова, бо від неї залежить весь дальший хід розмови. Система не може припускати, що кожен, хто телефонує, хоче записатися на прийом — вона має спочатку зрозуміти намір. При цьому певні категорії — скарги, термінові справи, юридичні або медичні питання — за визначенням вимагають людини, і хороший сценарій розпізнає це відразу, не витрачаючи час клієнта на непотрібні питання.
Крок 3 — збір мінімуму даних
Коли система вже знає, що потрібно клієнту, вона переходить до збору інформації, необхідної для виконання цієї потреби. Для типового запису на прийом це зазвичай чотири дані: ім'я, номер телефону, назва послуги та зручний час. Але — і це важливо — система не запитує все відразу і не запитує зайве.
Чому це важливо в контексті РОДО: чим менше даних ти збираєш, тим менше у тебе захисту і тим менший ризик порушення. Системі не потрібна домашня адреса клієнта, щоб записати його на послугу у Варшаві, не потрібен номер PESEL для запису на стрижку, і не потрібні медичні деталі в телефонній розмові — якщо тільки ці деталі не є необхідними для самої послуги. Принцип мінімізації даних (ст. 5 п. 1 літ. c РОДО) означає, що ти запитуєш лише те, що дійсно потрібно.
Прикладний діалог може виглядати так:
Система: «Будь ласка, назвіть ім'я». Клієнт: «Іван Іванов». Система: «Дякую. Будь ласка, номер телефону». Клієнт: «[номер телефону]». Система: «На яку послугу хочете записатися?» Клієнт: «Стрижка». Система: «Який час вам підходить? Можу запропонувати вівторок о 17:00, середу о 10:00 або четвер о 14:00».
Це лише чотири питання, прості, конкретні, без зайвих деталей. Система не запитує «а вам вранці чи вдень», не запитує «хто вас направив», не запитує про додаткові зауваження — хіба що клієнт сам почне про них говорити.
Приклад на умовних числах — підстав свої
Припустимо, твій салон обробляє 300 дзвінків на місяць. Середній час розмови з живим адміністратором — 3 хвилини. Якби кожен з цих розмов був на 30 секунд коротший завдяки впорядкованому сценарію ШІ, це заощадило б 150 хвилин на місяць — це понад 2,5 години роботи. Ці 2,5 години — це час, який співробітник може витратити на обслуговування клієнта, який вже прийшов, замість розмови по телефону.
Крок 4 — календар і підтвердження часу
Коли система вже знає, що потрібно клієнту, і має базові дані, вона переходить до найважливішого моменту: призначення часу. Тут ШІ з'єднується безпосередньо з календарем компанії і бачить реальні, актуальні вікна.
Система не пропонує час, який вже занятий — календар є єдиним джерелом правди, без подвійних записів, без ручної перевірки, чи занятий цей час кимось ще в проміжку. Це одна з головних переваг автоматизації: усунення людської помилки у вигляді застарілого стану графіка.
Вибір часу зазвичай відбувається так: система пропонує два або три вільні вікна, найближчі можливі, і чекає вибору клієнта. Якщо жоден із запропонованого часу не підходить, клієнт може запропонувати свій — система тоді перевіряє, чи він вільний, і або підтверджує, або інформує, що цей час занятий, і пропонує альтернативу.
Після вибору часу система повторює його вголос для клієнта: «Ви підтверджуєте вівторок о 17:00?» Це момент підтвердження, який усуває непорозуміння — клієнт чує точно, що буде записано, і може виправити помилку до того, як щось потрапить у систему.
Що відбувається, коли вільних вікон немає? У добре налаштованому сценарії клієнт не залишається з порожнім обіцянням. Система може запропонувати записатися в список очікування, до якого повертаються, коли хтось скасує запис. Або — якщо компанія так налаштувала — система пропонує передзвін, коли з'явиться вільне вікно, що відповідає побажанням клієнта. Це залежить від того, як компанія налаштувала свій потік обслуговування, але принцип один: клієнт завжди знає, на чому стоїть.
Крок 5 — темп розмови та якість взаємодії
Швидкість і плавність розмови мають величезне значення для відчуття комфорту клієнта. Система, яка мовчить занадто довго після питання, перебиває клієнта на півслові або сама занадто часто перебиває — відлякує. Документація OpenAI щодо голосових агентів вказує конкретні параметри, на які варто звертати увагу при тестуванні та оптимізації сценарію.
Порівняльні тести включають виконання завдання, затримку чутної відповіді, перебивання та небажану тишу. Для кожної метрики затримки визначаються спостережувані події початку і кінця, а також повідомляються медіана і хвіст розподілу OpenAI, Voice agents docs.
Що це означає на практиці: якщо після питання системи клієнт каже «а взагалі-то я хотів», система має розпізнати це перебивання і дозволити клієнту закінчити думку — а не обрізати речення і йти далі. Так само, якщо клієнт мовчить довше кількох секунд після питання, система має м'яко відреагувати — повторити питання або запитати, чи не поклав клієнт трубку. Це не очевидні поведінки — кожна вимагає свідомого налаштування і тестування.
У чому полягає тестування сценарію
Тестування — це не разова перевірка, чи «працює щось». Це багаторазове повторення тих самих сценаріїв з різними варіантами: запис, перенесення, скасування, скарга, «хочу людину», розмова польською, розмова англійською, розмова в шумі, розмова поза годинами роботи. Для кожного варіанту вимірюється час виконання, кількість перерваних речень, кількість повторів з боку клієнта і те, чи була в підсумку досягнута мета розмови.
Результати цих тестів дозволяють налаштувати параметри: скільки секунд тиші — це занадто багато, наскільки агресивно система може перебивати повтори, коли краще одразу переключити на людину. Це не разове налаштування — це безперервний процес покращення, бо поведінка клієнтів теж змінюється.
Крок 6 — передача людині
При найкращому налаштуванні бувають ситуації, коли автоматизація не справляється або не має приймати рішення самостійно. У таких моментах сценарій має передбачати передачу дзвінка живому співробітнику — або в реальному часі, якщо хтось доступний, або у формі передзвону з повним резюме.
Коли система має віддати розмову людині:
Коли клієнт про це просить. Це найпростіше правило: якщо хтось каже «хочу говорити з живою людиною» або «переключіть мене до когось», система не має наполягати на автоматизації.
Коли з'являється скарга. Скарга — це делікатна, емоційна справа, яка вимагає людського підходу — емпатії, розуміння контексту, вміння гасити конфлікт. Автоматизація може її прийняти і зареєструвати, але не має вирішувати самостійно.
Коли тема виходить за рамки знань системи. Якщо клієнт запитує про те, чого немає в базі знань — нова послуга, особливий випадок, нестандартне побажання — система має це розпізнати і передати.
Коли з'являється термінова або юридична справа. В областях високого ризику, де помилка може мати серйозні наслідки, OpenAI рекомендує, щоб людина переглядала результати роботи моделі, перш ніж вони будуть використані на практиці OpenAI, Safety best practices. Це принцип human in the loop — людина в петлі прийняття рішень.
Коли система не впевнена. Якщо розпізнавання мови не спрацювало кілька разів, якщо контекст розмови неясний, якщо клієнт явно роздратований — краще передати розмову, ніж далі погіршувати проблему.
Як виглядає передача
Якщо співробітник доступний прямо зараз, система може з'єднати дзвінок в реальному часі — клієнт чує коротке оголошення «будь ласка, зачекайте, з'єдную з консультантом» і розмова продовжується в голосовому режимі. Якщо нікого немає на місці, система може призначити передзвін: «хочете, ми передзвонимо протягом [X] хвилин? Тоді я представлю вашу справу консультанту».
Ключове те, що передача — це не невдача — це свідомий елемент сценарію. Хороша автоматизація не намагається бути універсальною; вона знає свої межі і поважає їх.
Крок 7 — після розмови: SMS, CRM і транскрипт
Коли розмова закінчується, автоматизація на цьому не закінчується. Є ще кілька кроків, які виконує система, перш ніж вважати справу закритою.
По-перше, SMS з підтвердженням. Клієнт отримує повідомлення з резюме: датою, часом, назвою послуги і, можливо, інструкцією з підготовки до прийому. Це не автоматична відповідь типу «дякуємо за звернення» — це конкретна інформація, яку клієнт може зберегти в телефоні без необхідності діставати папірець.
По-друге, запис в CRM. Система записує всі зібрані дані разом з резюме розмови: що хотів клієнт, що було узгоджено, скільки разів клієнт повторював інформацію, чи була розмова передана людині. Це останнє поле важливо з точки зору аналізу — якщо значна частина розмов з певної категорії закінчується передачею, варто перевірити, чи не потребує сценарій коригування.
По-третє, транскрипт розмови. У поетапному варіанті можна зберегти транскрипт, перевірити правила, перш ніж текстовий агент відповість, викликати внутрішні системи і лише потім генерувати мову OpenAI, Voice agents docs. Це означає, що кожна розмова архівується і доступна для подальшого перегляду — людиною, яка може захотіти перевірити деталі, або системою, яка аналізує якість обслуговування.
Хто відповідає за дані з транскрипту
Транскрипт — це запис розмови, а значить, він містить персональні дані клієнта — ім'я, номер телефону, тему розмови. Ці дані мають оброблятися відповідно до РОДО. Якщо ти користуєшся зовнішнім постачальником системи ШІ для транскрибування, ти маєш укласти з ним письмовий договір доручення на обробку персональних даних — це не опція, це обов'язок. Управління з захисту персональних даних (UODO) наклало на Сулковицький центр культури адміністративний штраф у розмірі 2,5 тис. злотих за доручення обробки персональних даних без укладеного в письмовій формі договору доручення і без попередньої перевірки того, чи обробник забезпечує достатні гарантії впровадження відповідних технічних заходів UODO, рішення від 21.09.2022. Договір доручення — це основа; без нього ти відповідаєш за обробку так, ніби робиш це сам, і несеш повну відповідальність за можливі порушення.
Типові аварійні ситуації і як їх обробляє добре налаштований сценарій
Навіть найкращий сценарій стикається з ситуаціями, що вимагають гнучкості. Нижче найчастіші випадки і способи їх обробки.
Система не розпізнала ім'я або назву вулиці
Якщо клієнт говорить невиразно, має акцент або на фоні є шум, система може не зрозуміти клієнта з першого разу. Хороший сценарій у такій ситуації не задає одне й те саме питання по колу — пропонує альтернативу: «не могли б ви назвати ім'я по буквах?» або «хочете, я прочитаю, що записав, і виправлю помилки?»
Клієнт говорить іншою мовою
Якщо система виявляє мову, відмінну від налаштованої (наприклад, клієнт починає англійською в компанії, яка обслуговує польською), сценарій може мати підготовлені універсальні повідомлення: «вибачте, ми обробляємо дзвінки польською — можу допомогти польською?» Якщо клієнт не говорить польською, система передає тому, хто може обробити цю мову, або інформує, що компанія не підтримує цю мову.
На фоні шум
Коли система виявляє високий рівень шуму на фоні — розмова на фоні, музика, вуличний рух — вона може попросити про кращі умови: «вибачте, я чую багато шуму на фоні. Не могли б ви перейти в тихіше місце?» Це просте втручання, яке часто вирішує проблему без необхідності передачі людині.
Клієнт просить живу людину
Ця подія передбачена в кожному хорошому сценарії. Система не має сперечатися, переконувати або задавати додаткові питання — вона просто виконує запит: «звичайно, з'єдную з консультантом» або «будь ласка, зачекайте, ми передзвонимо протягом [X] хвилин».
Два клієнти хочуть один і той самий час
Якщо тим часом хтось інший записався на той самий слот, система має це виявити і запропонувати рішення: новий час, інший день, запис у список очікування. Клієнт не має дізнаватися про колізію лише після приходу в компанію.
Перевір сам: список із 10 тестових дзвінків
Перед впровадженням ШІ-ресепшн у своїй компанії протестуй сценарій на наборі типових ситуацій. Нижче список із 10 дзвінків, які варто провести — або самому, або з допомогою когось із команди, або використовуючи інструменти автоматичного тестування.
- Запис на прийом у стандартному сценарії.
- Перенесення існуючого прийому на інший день.
- Скасування прийому із зазначенням причини.
- Питання про нову послугу, якої немає в базі знань.
- Скарга на якість обслуговування з попереднього прийому.
- Пряма просьба поговорити з живою людиною.
- Розмова в умовах шуму (наприклад, з вулиці).
- Розмова англійською в компанії, що працює польською.
- Розмова поза годинами роботи компанії.
- Розмова, в якій клієнт багаторазово повторюється і плутається в деталях.
Для кожної з цих розмов відзнач: скільки разів клієнт мав повторити одну і ту саму інформацію, скільки часу зайняло досягнення мети, чи був дзвінок переданий людині, і яка була остаточна оцінка — чи досяг клієнт того, заради чого дзвонив.
Після проведення цих тестів у тебе буде конкретна картина того, де сценарій працює добре, а де потребує виправлень. Тести не спрямовані на доведення того, що автоматизація працює — вони покликані показати, де вона ще не працює.
Як це виглядає, коли дзвінки веде система
Коли ти впровадиш ШІ-ресепшн, щоденна робота з телефонами змінюється так, що це складно оцінити без знання деталей. Мова не про те, що «робот бере трубку» — мова про впорядкування процесу, який раніше залежав від настрою, втоми та уваги конкретної людини.
У типовий день із ШІ-ресепшн це виглядає так: клієнт дзвонить, система відповідає і представляється як автоматизована ресепшн. Клієнт говорить, що йому потрібно — наприклад, хоче записатися на прийом. Система запитує ім'я, телефон і зручний час. Пропонує вільні вікна. Клієнт обирає. Система відправляє SMS з підтвердженням і записує все в CRM з резюме: що хотів клієнт, на який час записано, чи потрібно щось підготувати. Ти як власник або менеджер бачиш вранці список нових записів і перевіряєш лише ті, які вимагають уваги — скарги, питання за межами знань системи, незвичайні побажання.
Це не магія і не обіцянка великих заощаджень. Це просто впорядкований процес, який усуває найчастіші помилки: забутий запис, непідтверджений прийом, необроблена скарга, пропущене питання клієнта.
Якщо ти хочеш побачити, як саме працює цей сценарій у твоїй компанії — які питання запитує система, які дані збирає, як інтегрується з твоїм календарем — ти можеш це перевірити в дії. Aura вибудовує телефонний шар, де відповідає AI: знає твої послуги, ціни та графік і вміє довести справу до кінця. Деталі на сторінці AI-ресепшен і телефонія.
Перевір також, як працює повна екосистема: Системи бронювання дозволяють клієнту самостійно обирати час без телефонної розмови, а Автоматичні повідомлення відправляють підтвердження та нагадування SMS, поштою або WhatsApp — завжди зі згодою клієнта і з можливістю відмови. Разом ці три послуги створюють замкнений цикл обслуговування, в якому телефон, календар і комунікація з клієнтом працюють як один цілісний шар. Якщо хочеш, щоб усі дані клієнтів опинялися в одному місці, додай CRM та автоматизації — телефон, форма, месенджери та картка Google записують в одному місці. А якщо ведеш багато розмов одночасно і потрібна допомога в кваліфікації лідів, AI-кваліфікація лідів оцінює та тегує заявки за потенціалом.
Дізнайся більше про автоматизацію в бізнесі зі статей: Автоматизація обробки запитів: одна черга замість п'яти скриньок, Автоматизація процесів у компанії: що реально можна передати системі, а що ні, Автоматизація і RODO: де фізично знаходяться дані Ваших клієнтів, Помилки при впровадженні автоматизації: п'ять ситуацій, коли ми радимо не починати.
Часті питання
Клієнт не розізлиться, що розмовляє з роботом?
Залежить від того, як налаштований сценарій. Клієнт розізлиться, якщо робот не розуміє, що він говорить, постійно просить повторити, не може відповісти на просте питання і не дає переключитися на людину. Добре налаштований сценарій чітко говорить на початку, що це автоматизація, не вдається з живою людиною, збирає мінімум даних і не витрачає час клієнта на зайві кроки. Багато клієнтів віддають перевагу швидкій розмові з автоматом, який вирішує питання за 60 секунд, а не очікуванню на лінії з живим адміністратором, який відповість через три хвилини.
Що якщо ШІ не зрозуміє клієнта?
Хороший сценарій передбачає резервні процедури: повторення питання іншими словами, прохання назвати інформацію по буквах, перехід у режим передачі людині. Клієнт не має бути змушений повторювати одне й те саме по колу — після другої невдалої спроби система має запропонувати переадресацію.
Дзвінки записуються і хто має доступ?
Транскрипти зберігаються, якщо ти так налаштуєш систему. Доступ має людина, яку ти призначиш у компанії. Якщо ти користуєшся зовнішнім постачальником ШІ, у тебе має бути з ним договір доручення обробки персональних даних — без нього ти відповідаєш за відповідність РОДО так, ніби обробляв ці дані сам.
Скільки це коштує?
Вартість залежить від кількості дзвінків, які обробляє система, і від обраного набору функцій. Ми не вказуємо конкретні ціни. Детальніше про те, як рахувати вартість невідповідених дзвінків, читай у статті Скільки коштують пропущені дзвінки у компанії – формула для розрахунку на власних цифрах.
Можна протестувати до впровадження?
Так, перш ніж вирішуватися на повне впровадження, варто протестувати сценарій на реальних розмовах або симуляціях. Проведи 10 тестових дзвінків із списку вище і подивися, як система справляється з кожною ситуацією. За результатами можна налаштувати питання, додати відсутні шляхи і встановити, які дзвінки завжди мають йти людині.
Може ШІ обслуговувати кілька компаній одночасно?
Технічно так, але з точки зору якості краще, якщо кожна компанія має свій виділений сценарій. Інший набір послуг, інший графік, інші години роботи, інша база знань — все це вимагає індивідуального налаштування. Одна система може обслуговувати кілька компаній, але кожна з них має мати свій потік, адаптований під себе.