Реалізація голосового AI-бота для підтвердження замовлень

Голосовий бот для підтвердження замовлень: де розривається процес

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

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

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

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

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

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

Подія йде в облікову систему один раз, тому подвійних записів і «дребезгу» статусів не виникає; запис розмови та розшифрування залишаються прив'язаними до замовлення.

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

Сценарії автоматичного підтвердження: ефект у цифрах

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

• Частка підтверджених замовлень. У пік ручний обдзвон не доганяє потік: оператори закривають перші позиції черги, решта висить до таймауту. Бот обдзвонює весь список — приріст 20–25 п.п. і жодного провалу в години навантаження.
• Час до підтвердження. Дзвінок іде через хвилину після оформлення, поки клієнт ще біля телефону, а не через годину, коли звільнився оператор. Коротка пауза — вищий відгук.
• Навантаження на операторів. Типові випадки — замовлення в наявності, адреса й час без змін — ідуть на автомат, це 60–70% звернень. Оператор залишається на перенесеннях, замінах і відмовах.
• Повторні звернення. Клієнт не телефонує «що із замовленням»: статус підтверджено й видно в Битрикс24. Частка таких дзвінків падає в рази й звільняє ту саму лінію.
• Зниклий клас відмов. Замовлення, що зависли без підтвердження й скасовані за таймаутом, перестають виникати як явище.

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

Режими обдзвону: порівняння підходів та їхні обмеження

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

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

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

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

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

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

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

1. Аудит дзвінків. Розмічаємо записи та журнали за період: скільки замовлень доходить до підтвердження, на якій репліці обривається діалог, які формулювання клієнт перепитує. На виході — карта відмов і словник реальних заперечень замість здогадів.
2. Схема сценарію. Розгалуження за відповіддю: підтверджую, не підтверджую, перенесення дати, питання щодо складу. Гілки «не я замовляв» і «передзвоніть пізніше» ведуть до передачі оператору з контекстом розмови, а не в глухий кут.
3. Правила обдзвону. Вікно додзвону, кількість спроб та інтервали між ними, тихі години, поведінка при недодзвоні. Вичерпали спроби — замовлення йде оператору разом з історією дзвінків.
4. Зв'язок з обліковою системою. Статус змінюється за підсумком розмови, а не окремим вивантаженням. Повторний дзвінок не створює другого статусу й не зсуває замовлення з черги збирання.
5. Тестова вибірка замовлень. Прогін на реальних замовленнях із ручним розміченням: де бот зрозумів неправильно — правимо формулювання й поріг спрацьовування, поки розходження не стануть поодинокими.
6. Передача зміни. Регламент правок сценарію, панель з метриками, розбір спірних діалогів. Далі зміни вносимо за даними, а не за відчуттями.

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

Правила маршрутизації, сценарії та документація за підсумками

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

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

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

Комплект передаємо з версіонуванням: правка фіксується, попередня версія залишається доступною для відкату.

Кейс: як автоматичний обдзвон знизив навантаження на зміну

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

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

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

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

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

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

Окремо розібралися з класом відмов. Раніше недоступний номер, помилкове введення та усвідомлена відмова падали в одну метрику «скасування», і було незрозуміло, що лагодити.

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

Чим відрізняється обдзвон автоінформатором від діалогового сценарію?

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

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

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

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

Відмінність від контакт-центру не в тому, хто «краще» говорить, а в тому, що забирає бот, а що йде людям.

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

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

Складні випадки: поганий зв'язок, діалекти, відмови від дзвінка

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

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

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

Чи зрозуміє бот діалект або сильний акцент?

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

Клієнт відмовляється розмовляти з ботом — що тоді?

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

Куди потрапляє спірне замовлення?

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

Обговоримо задачу: які дані потрібні для оцінки

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

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

Щоб повернутися з оцінкою та планом за етапами, а не з приблизною вилкою, потрібні ввідні нижче. Частину з них уточнюємо на розборі записів і на дзвінку з вашою службою доставки.

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

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