Розробка AI-автообдзвону для нагадування клієнтам про запис

AI-автообдзвін: де ламається нагадування клієнтів про запис

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

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

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

Третє — дублі в журналі запису. Ручний додзвін і автоматичне нагадування йдуть паралельно й не знають одне про одного: на один час з’являються два записи, а робот-обдзвін підтвердження запису телефонує щодо візиту, який вже скасовано або перенесено. Клієнт отримує суперечливі повідомлення й перестає довіряти нагадуванням узагалі.

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

Зрив нагадувань виглядає як «телефонували, але не додзвонилися», а насправді дзвінок не був поставлений у чергу взагалі.

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

Менше неявок і ручної роботи: ефект автоматичних дзвінків

Дзвінок за добу й контрольний — за пару годин до візиту: робот уточнює, чи прийде клієнт, і одразу записує відповідь у систему запису. Голосовий канал складніше пропустити, ніж повідомлення в месенджері, тому частка підтверджених візитів зростає з половини до 85–90%.

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

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

Розвантаження адміністраторів — друга половина ефекту. Обдзвін списку на завтра забирає в людини години зміни й усе одно йде вибірково; робот проходить весь список за один прогін і не втомлюється до вечора. Адміністратор підключається лише до нестандартних випадків.

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

Формати AI-автообдзвону: голос, сценарії та інтеграції

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

Найдорожче в реалізації — не голос, а зв’язка з журналом запису.

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

Тому ми спочатку описуємо обмін з обліковою системою — наприклад, з amoCRM або галузевої МІС — і тільки потім збираємо сценарій дзвінка під реальні статуси запису.

Етапи впровадження: від розбору бази записів до запуску

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

1. Аудит бази записів і правил скасування. Перевіряємо заповненість телефонів, дублі, минулі візити, те, як система позначає скасування. На виході — карта полів і правила: кому телефонувати, за скільки годин до візиту, скільки спроб додзвону робити.

2. Схема розмови. Фіксуємо гілки — підтвердження, перенесення, відмова, недодзвін, прохання з’єднати з людиною. Для кожної визначаємо, що робот говорить і куди передає запит, щоб клієнт не залишався в глухому куті.

3. Налаштування сценаріїв і голосу. Записуємо репліки, налаштовуємо паузи й поріг розпізнавання під реальний шум, додаємо повтор питання й стоп-слова. Прогін на телефонах команди — до першої розсилки.

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

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

6. Регламент ескалації та передавання. Описуємо, за яких фраз робот одразу з’єднує з адміністратором, як фіксуються збої й кому надходить повідомлення. Передаємо налаштування, схему гілок та інструкцію з правки реплік.

Що передаємо на руки: сценарії дзвінків і регламенти

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

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

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

• Сценарії дзвінків і гілки діалогу — привітання, підтвердження запису, перенесення, відмова, прохання передзвонити пізніше, передача живому адміністратору. Для кожної гілки зазначено, чим вона закінчується і який статус надходить у систему.
• Карта змінних підстановки — які поля беруться з журналу запису в момент набору (ім’я, дата й час прийому, адреса точки, спеціаліст) і що підставляється, якщо поле порожнє.
• Правила доступу до бази — ролі на читання й вивантаження, маскування контактів, строк зберігання, порядок узгодження вивантаження й заборона на використання даних поза обдзвоном.
• Журнал дзвінків — запис розмови, розшифровка, підсумковий статус (підтвердив, переніс, відмовився), причина відмови й кількість спроб додзвону за кожним номером.
• Схема зв’язки з журналом запису — напрямок і частота обміну, обробка конфліктів (запис скасували вручну під час обдзвону), повторна постановка в чергу.
• Інструкція для адміністраторів — як виключити клієнта з обдзвону, як повернути запис у роботу, що дивитися при розбіжності статусів, куди писати при збої.
• Регламент ескалації — кому надходить сигнал про збій, час реакції чергового, порядок зупинки кампанії повністю.
• Чек-лист приймання — набір контрольних сценаріїв, які проганяються на реальних даних перед підписанням передавання.

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

Кейс: як мережа салонів знизила неявки після запуску

Як було

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

Частка підтверджень трималася близько 40%: частина номерів не відповідала, повторні спроби з’їдали час стійки, а зайнятий слот залишався за клієнтом до самого візиту.

Що змінили

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

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

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

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

Окремо закрили клас відмов, який найчастіше псує статистику: короткий виклик, скидання, відповідь не тієї людини, прохання передзвонити.

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

Чим робот-підтвердження відрізняється від ручного обдзвону?

Робот-підтвердження — це не аудіозапис із кнопками, а діалоговий сценарій: розпізнавання мовлення переводить відповідь клієнта в намір (підтвердити, перенести, відмовитися), рушій вибирає наступну репліку й тримає розмову в межах підтвердження запису.

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

Робот сильніший там, де розмова передбачувана.

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

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

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

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

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

Технічні сумніви: додзвін, відмови, повторні записи

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

Що буде з дублями та застарілими номерами в базі?

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

Чи можна телефонувати ввечері?

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

Що робити, якщо розпізнавання не розібрало відповідь?

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

Як підтверджується повторний запис?

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

Обговоримо задачу: план запуску та точки контролю

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

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

Що входить у план запуску і за якими точками ми звіряємося:

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

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