Голосовий бот на записі: де губляться дзвінки та час
Пік навантаження в реєстратури припадає на перші години після відкриття та на вечірній відрізок: у це вікно проходить понад половина всіх звернень за день, а на лінії одночасно перебувають один-два адміністратори.
Решта в цей час оформлюють документи, приймають оплату та супроводжують пацієнтів у кабінетах — тобто фізично не можуть взяти слухавку.
Кожен такий дзвінок іде в нікуди: частина людей набирає ще раз за годину, але більшість просто телефонує наступному зі списку, і запис дістається конкуренту.
Пропущені дзвінки в години пік — не «дрібниця на тлі загального навантаження», а прямий витік потоку. Навіть коли слухавку беруть, розмова триває три-чотири хвилини: уточнити послугу, підібрати лікаря, вільний час, продиктувати адресу.
За годину один адміністратор закриває не більше п’ятнадцяти звернень, і будь-яка затримка — уточнення по телефону в колеги, пошук картки в паперовому журналі — розтягує чергу на лінії до десяти хвилин очікування. Люди кидають слухавку на п’ятій хвилині, і ці виклики не відображаються в жодній звітності.
Окрема поломка — ручна фіксація. Поки запис іде в журнал або в таблицю, два адміністратори можуть завести одного клієнта на один і той самий час: подвійні бронювання спливають на прийомі, коли людина вже прийшла, і розрулювати їх доводиться вручну, з вибаченнями та перенесенням.
Перевантаження адміністраторів погіршує все одразу — зростає і кількість пропущених викликів, і частка помилок у розкладі.
Саме цей зв’язок «пік → пропущений виклик → ручний запис → подвійна бронь» і є точкою, де губиться потік.
Розбираємо, як її закриває голосовий бот для запису на прийом: він бере на себе приймання викликів у пікові вікна та автоматичний запис клієнтів, залишаючи адміністраторам складні випадки.
Вимірюваний ефект: пропущені дзвінки, навантаження, частка записів
Починаємо з базових вимірювань на реальному трафіку: частка пропущених дзвінків у пікові години, медіанний час від першого слова клієнта до підтвердженого запису, кількість звернень на зміну адміністраторів.
Зріз фіксуємо на тому самому тижневому інтервалі до й після запуску — інакше порівнювати нічого, і будь-який звіт про ефект перетворюється на суб’єктивні судження.
Доступність лінії запису змінюється першою. Бот тримає кілька розмов одночасно, тому лінія перестає бути зайнятою в наплив: у ранкові та вечірні вікна частка прийнятих звернень піднімається з 60-70% до 95% і вище, а повторні додзвони майже зникають.
Час обробки звернення скорочується завдяки послідовному збору полів без перемикання між вікнами: послуга, спеціаліст, дата й час уточнюються в одній розмові, вільний слот перевіряється одразу, підтвердження надходить у діалозі. Типовий сценарій укладається в 40-60 секунд проти кількох хвилин в оператора.
Частка записів без оператора — головний показник автономності: зазвичай 50-70% звернень бот закриває повністю, решта переходить адміністратору з уже зібраним контекстом, і з’ясовувати заново нічого не потрібно. Навантаження на зміну падає у 2-3 рази, ті самі люди обробляють більше звернень у ті самі години.
Окремо рахуємо частку діалогів із передачею оператору, скасування та перенесення, записи, що дійшли до візиту. Ці цифри показують, який сценарій дообучувати, і слугують підставою для наступної ітерації.
Сценарії голосового бота: жорсткий, діалоговий, гібридний
Вибір режиму розмови визначає, скільки правил запису можна накласти на голосового бота і наскільки передбачувано він поводиться.
Чим жорсткіше дерево питань, тим простіший аудит кроків і нижчий ризик неповних даних; чим вільніший діалог, тим вищі вимоги до розбору репліки та перевірки того, що бот витяг із відповіді.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Жорсткий: дерево питань | Запис на прийом за фіксованим набором полів, високе навантаження на лінію, потрібен повний аудит кожного кроку | Репліка поза гілкою заводить розмову в глухий кут; перенесення часу, зміна спеціаліста або уточнення щодо підготовки потребують окремої гілки |
| Вільний діалог і дерево питань як підказка | Клієнт ставить запитання про підготовку до прийому, послугу або адресу, а сам запис — лише один з результатів розмови | Відповідь не повторюється від дзвінка до дзвінка, обов’язкова перевірка витягнутих полів перед записом у розклад |
| Гібридний режим розмови | Бот веде запис за сценарієм діалогу з клієнтом, а уточнення та заперечення обробляє вільною відповіддю | Потрібна явна ознака переходу між режимами та правило повернення до сценарію, інакше бот втрачає нитку |
Ключове, що перевіряємо на кожному режимі, — поведінка на межах.
Якщо бот двічі не розібрав репліку, спрацював стоп-фактор на кшталт запиту медичної поради чи скарги або клієнт прямо просить людину, — передача розмови оператору відбувається разом з історією діалогу та вже зібраними полями. Оператор не перепитує заново, а продовжує з того місця, де зупинився бот.
На пілоті рахуємо дві метрики: частку розмов, доведених до запису без оператора, і повноту полів у створеному записі. За ними й вибирається режим — зазвичай гібридний, з поступовим розширенням вільної частини в міру накопичення розшифровок реальних дзвінків.
Етапи впровадження: від розбору дзвінків до передачі в підтримку
Роботи йдуть послідовно: кожен етап спирається на результат попереднього, тому сценарій не переписують на ходу, а уточнюють за фактами. Нижче — порядок, у якому ми ведемо впровадження голосового бота.
Як влаштовано порядок робіт
- Аудит вхідних звернень. Беремо записи та розшифровки за період і розмічаємо їх за темами: запис, перенесення, скасування, питання про послугу, повернення. Рахуємо частки та довжину діалогів — видно, які 15–20 сценаріїв закривають основну масу дзвінків, а що чесніше одразу віддавати людині.
- Схема маршрутизації дзвінка. Фіксуємо: який номер куди потрапляє, у які години бот відповідає сам, за якими ознаками передає оператору, що робить при обриві та повторному дзвінку. Тут же визначаємо точки, де бот зобов’язаний запросити підтвердження.
- Сценарій і зв’язка з розкладом. Репліки, розгалуження, словники назв послуг — формулювання проходимо вичиткою, щоб знизити кількість перепитувань. Перевіряємо роботу з вільними вікнами: зайнятий час бот не займає двічі, а пропонує найближчу альтернативу.
- Тестова експлуатація бота. Спочатку синтетичні дзвінки на повний набір гілок, потім обмежена частка живого трафіку з переведенням на оператора за першого збою. Збираємо метрики: частка діалогів без передачі людині, середня тривалість, кількість уточнювальних питань.
- Приймання голосового сценарію. Контрольний набір дзвінків проходить замовник: типові гілки, рідкісні випадки, обрив зв’язку. Критерії — коректні записи в розкладі, відсутність задвоєнь, зрозуміла передача оператору.
- Передача в підтримку. Віддаємо доступи, схему маршрутизації, опис сценарію та порядок правки реплік; співробітників учимо читати розшифровки й змінювати логіку при зміні розкладу.
Комплект передачі: сценарії, інтеграції, регламенти, доступи
Комплект передачі — не папка зі звітами, а робочий набір: з ним ваша команда сама править репліки, додає лікаря або філію та розбирає збої. Тому кожну позицію нижче ми збираємо так, щоб її можна було відкрити без нас і зрозуміти, що і де змінювати.
- Сценарії діалогу — гілки запису, перенесення, скасування, уточнення спеціаліста й адреси; тексти реплік, варіанти вимови назв, поведінка при перебиванні та мовчанні абонента.
- Правила ескалації звернень — умови передачі розмови оператору: нерозпізнаний запит після кількох уточнень, конфліктне формулювання, запит на зміну наявного запису, терміновий випадок поза розкладом.
- Підключення до системи запису — які сутності бот читає і які створює, схема авторизації, тестовий контур для перевірки правок, поведінка при недоступності зовнішньої системи (що бот говорить і куди пише заявку).
- Документація з голосового бота — карта сценаріїв, словник сутностей і синонімів, опис полів і статусів запису, інструкція з правки реплік і додавання нових гілок.
- Регламент супроводу — які зміни вносимо за заявкою, строки реакції за класами збоїв, хто на вашому боці погоджує тексти й коли зміни випускаються.
- Доступи та володіння — акаунти, ролі й ключі оформлені на замовника, вся історія правок лежить у вашому контурі, після завершення робіт нічого не залишається «на нашому боці».
- Метрики та звітність — частка записів, закритих без оператора, частка зривів на етапі підтвердження, час до відповіді; домовимося, де дивимося ці показники і з якою періодичністю.
Приймання йде за цим самим переліком: кожну позицію перевіряємо на тестовому контурі — проганяємо сценарій, ламаємо зв’язок із системою запису, викликаємо ескалацію. Що не відтворюється у вас, те не передано.
Кейс: запис на прийом у мережі клінік — до і після впровадження
До: пікові години та втрачені звернення
Мережа клінік тримала три лінії на адміністраторів: у ранкові години й після роботи частка прийнятих звернень падала до 62%, решта дзвінків ішла в пропущені — частина пацієнтів до адміністратора так і не доходила.
Підтвердження запису розтягувалося до кількох годин: заявку фіксували в журналі й поверталися до неї, коли звільнялася лінія. Окрема стаття втрат — скасування через помилку: адміністратор плутав напрям, лікаря або час, і за таким зверненням запис доводилося переробляти.
Після: перша лінія на голосовому боті
На першу лінію поставили голосовий бот, який приймає звернення повністю: уточнює напрям, лікаря та зручне вікно, звіряється з розкладом і підтверджує запис.
Розпізнавання налаштували під медичну лексику — назви спеціальностей, прізвища лікарів, формулювання виду «наступного тижня після обіду»; при невпевненості у відповіді бот переводить дзвінок на адміністратора, а не додумує сам. Підтвердження надходить одразу після розмови, повторний дзвінок для уточнення не потрібен.
Метрики до і після:
- частка прийнятих звернень — з 62% до 97% у пікові години;
- час до підтвердження запису — з кількох годин до хвилини розмови;
- скасування через помилку в записі — з 18% до 3%;
- навантаження на адміністраторів змістилося на складні випадки: перенесення, питання щодо підготовки до прийому, робота з тими, хто просить живого співрозмовника.
Технічно проєкт спирається на хмарне розпізнавання мовлення Yandex SpeechKit та інтеграцію з розкладом клініки, тому бот бачить лише вільні вікна й не створює подвійних записів.
Що було вузьким місцем до впровадження — видно за першою цифрою: зростання частки прийнятих звернень дало приріст записів без розширення штату.
Чим діалоговий сценарій відрізняється від дерева питань?
Дерево питань — заздалегідь зверстаний граф: наміру відповідає перехід, маршрут заданий автором сценарію. Діалоговий сценарій веде стан розмови: зберігає зібрані відомості й на кожному кроці вирішує, що уточнити наступним. Різниця видна там, де людина відповідає не за скриптом.
Обробка нестандартних відповідей — головний вододіл. Репліка «мені б наступного тижня, але не в четвер» у дереві не потрапляє в жодну гілку: розмова переходить на оператора. Діалоговий шар розбирає її на слоти — бажаний час, обмеження — і добирає відсутнє зустрічним питанням.
Стійкість розпізнавання мовлення — другий вододіл. Дерево вимагає збігу з очікуваним формулюванням: шум у слухавці, обмовка або ім’я, продиктоване по літерах, ламають перехід.
Діалоговий сценарій звіряє кілька гіпотез розпізнавання й перепитує підтвердження, утримуючи контекст сесії.
Складність підтримки сценарію зростає по-різному. У дереві новий варіант відповіді множить гілки, і правку одного питання перевіряють по всіх вхідних шляхах. У діалоговому сценарії змінюється правило збору даних або порядок уточнень.
| Критерій | Дерево питань | Діалоговий сценарій |
|---|---|---|
| Маршрут | заданий графом переходів | будується за станом розмови |
| Нестандартна відповідь | глухий кут або оператор | уточнювальне питання, збір за слотами |
| Помилка розпізнавання | ламає перехід | перепитування та підтвердження |
| Правка сценарію | множить гілки та зв’язки | змінює правило уточнень |
| Перевірка перед випуском | прогін шляхів | прогін діалогів і регресія |
На практиці підходи поєднують: вибір послуги та підтвердження часу тримають на жорстких правилах, а збір даних віддають діалоговому шару — сценарій залишається керованим, але перестає бути крихким.
Технічні сумніви: розпізнавання мовлення, шум, передача оператору
Сумніви до голосового бота в інженерів зазвичай одні й ті самі: що буде на шумній лінії, як він розрізняє паузу та кінець репліки, за якою логікою віддає розмову людині. Розбираємо, як ці ситуації закриті в сценарії.
Що буде при шумі, тихому мовленні та обривах зв’язку?
Шумопридушення та ехопридушення працюють до розпізнавання, а детектор мовлення відрізняє паузу «людина думає» від кінця репліки — бот не перебиває й не відповідає в тишу.
Якщо впевненість розпізнавання за ключовим полем падає нижче порогу, бот не вгадує: перепитує одним коротким питанням, а час і телефон просить підтвердити частинами. При обриві зв’язку виклик не скидається мовчки — останнє питання повторюється.
Як розмова переходить до оператора?
Передача відбувається за явними правилами: пряме прохання «з’єднайте з людиною», кілька невдалих уточнень поспіль, тема поза сценарієм або підвищений тон.
Перед перемиканням бот віддає оператору короткий зведений опис — мета дзвінка, названі дані, вибраний час, — тому розмова продовжується з середини, а не з «вітаю, чим допомогти».
Як бот переносить і скасовує запис?
Новий запис, перенесення та скасування розводяться до підтвердження, інакше бот створює дубль. Він знаходить наявний запис за номером або названим часом, пропонує найближчі вільні вікна в розкладі, фіксує зміну та надсилає підтвердження в месенджер. Якщо запис не знайдено, вмикається переведення на оператора з уже зібраним контекстом.
Обговоримо задачу: розберемо потік дзвінків і повернемося з планом
Щоб оцінка впровадження голосового бота спиралася на факти, а не на припущення, починаємо з розбору потоку звернень.
Надішліть вивантаження дзвінків за типовий тиждень — з тривалістю, часом очікування в черзі та часткою недодзвонів: за ним видно, де губляться записи, які сценарії бот закриває одразу, а які розумніше залишити адміністратору.
Далі обговорюємо впровадження голосового бота предметно. Для плану робіт потрібен ще мінімум контексту — за ним ми рахуємо навантаження й вибираємо порядок етапів:
- записи або вивантаження дзвінків за кілька робочих днів — рахуємо частку типових звернень і повторних питань;
- перелік сценаріїв запису: напрями, філії, правила перенесення, скасування та нагадувань;
- доступи до телефонії та її налаштування — черги, голосове меню, запис розмов;
- опис системи, куди бот ставить запис, та її програмного інтерфейсу для обміну даними;
- вимоги до обробки персональних даних і строки зберігання записів розмов;
- контакт адміністратора або керівника кол-центру — звіримо формулювання та правила ескалації.
На виході ви отримуєте не загальну презентацію, а розбір потоку звернень, схему маршрутизації дзвінків, чернетки сценаріїв і план етапів із порядком старту робіт. Опишіть задачу — повернемося з оцінкою та планом.
