Автоматичне оцінювання дзвінків: де ламається ручний контроль
Контроль якості обслуговування досі тримається на вибірковому прослуховуванні: супервайзер фізично встигає розібрати одиниці відсотків розмов за зміну.
Решта потоку не оцінюється взагалі, а сама вибірка зміщена — до неї потрапляють найдовші, найконфліктніші або вже проблемні дзвінки, відкриті за скаргою. У підсумку метрика описує не роботу відділу, а те, що зручно було відкрити.
Друге джерело викривлення — людський. Один і той самий запис двоє перевіряльників оцінюють по-різному: розбіжність в один-два бали за шкалою вважається нормою, бо критерії живуть у голові та в усних домовленостях, а список перевірок оновлюється рідше, ніж змінюється продукт. Оцінка операторів перестає бути порівнюваною — ні між людьми, ні між місяцями.
Третя проблема — час. Розбір доходить до співробітника через тижні, коли він не пам'ятає ні контексту, ні клієнта, ні власних формулювань. Зворотний зв'язок надходить у момент, коли поведінка вже не відтворюється, і навчання не прив'язується до конкретної репліки.
Розбираємо, як це закривається суцільним автоматичним оцінюванням дзвінків: розмітка розмов за типовими сценаріями, єдині критерії на весь потік записів і зворотний зв'язок того ж дня, поки розмова ще в роботі.
Що дає система: відмова від вибірковості та єдина шкала
Суцільна перевірка розмов змінює саму логіку контролю: система обробляє весь потік дзвінків, а не вибірку в кілька відсотків, яку фізично встигає прослухати керівник.
Мовлення розпізнається на Whisper і розділяється за спікерами, далі кожна репліка звіряється з чек-листом критеріїв — обов'язкові формулювання, перебивання, коректність умов, робота із запереченням.
Оцінку отримує кожен запис, а спірний фрагмент позначається міткою часу: розбір іде за цитатою, а не за пам'яттю.
Єдина шкала оцінювання — другий ефект. Критерії та ваги живуть у конфігурації, а не в голові перевіряльника, тому та сама розмова під час повторної перевірки отримує близький бал.
Розбіжність між двома перевіряльниками скорочується з бала-півтора до десятих, а спірні випадки йдуть в окрему вибірку для калібрування.
Час до зворотного зв'язку вимірюється хвилинами: розбір надходить оператору тієї ж зміни, поки контекст дзвінка свіжий, а не через тиждень на загальних зборах. Це змінює сенс контролю — розбір стає навчанням, а не звітом.
Окремо зникає клас пропущених порушень. Критичні критерії — не озвучені умови, сума або строки — піднімаються флагом незалежно від підсумкового балу, і керівник бачить список таких дзвінків, а не розраховує, що вони не потрапили у вибірку.
На цьому тлі якість роботи відділу стає вимірюваною: видно частку дзвінків із критичними порушеннями, зсув розподілу оцінок і динаміку за кожним критерієм.
Варіанти впровадження: готовий сервіс, власна модель, гібрид
Три режими різняться тим, чия модель виносить оцінку і на яких даних вона навчалася.
Готове рішення працює на моделі, навченій на загальному потоці дзвінків; власна модель — на ваших записах і вашому регламенті; гібридний підхід залишає базову модель, але добудовує її галузевою лексикою та правилами розмови.
Вибір зводиться до трьох параметрів: строк запуску до перших оцінок, обсяг підготовчих робіт з вашого боку та вимоги до галузевої лексики — наскільки важливо, щоб система розуміла внутрішні назви, скорочення та формулювання регламенту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готове рішення | Потрібні оцінки за типовими критеріями та запуск у короткий строк, власний корпус записів ще не зібрано | Загальна лексика: внутрішні назви продуктів, скорочення та формулювання регламенту розпізнаються гірше |
| Власна модель | Жорсткі вимоги до термінології, власні критерії, є або збирається розмічений корпус дзвінків | Розмітка, навчання та супровід; до перших оцінок — тижні, а не дні |
| Гібридний підхід | Потрібен швидкий старт і при цьому власна лексика та регламент | Словники й правила потрібно оновлювати вслід за змінами в продукті та регламенті розмови |
На практиці розвилка рідко буває бінарною: зазвичай стартують на готовому рішенні — отримати перші оцінки та звірити їх із вибірковою ручною перевіркою, — паралельно накопичуючи розмічені дзвінки. Через кілька тижнів оцінку переводять на власну або гібридну модель без зупинки контролю якості.
Етапи робіт: від аудиту записів до передачі системи
Починаємо не з коду, а з архіву записів: без розуміння того, як реально звучать розмови, будь-яка шкала виявиться відірваною від практики. Нижче — етапи впровадження; порядок не змінюємо, бо кожен крок спирається на артефакти попереднього.
-
Аудит записів. Вивантажуємо вибірку з архіву за кілька місяців, прибираємо тишу та службові вставки, перевіряємо якість каналів. На виході — карта розмов: типові сценарії, частка аномальних дзвінків, місця, де запис потребує попередньої обробки.
-
Постановка шкали. Збираємо критерії разом із керівниками напряму: що вважаємо привітанням, виявленням потреби, роботою із запереченням, дотриманням регламенту. Кожному критерію — вага та опис граничних випадків, включно з «не застосовно».
-
Розмітка та навчання моделі. Розмічаємо кілька сотень діалогів за затвердженою шкалою, спірні випадки розбираємо між розмітниками. Так формулювання перестають допускати подвійне тлумачення, а система навчається на узгоджених прикладах.
-
Перевірка на контрольній вибірці. Відкладені діалоги, які не брали участі в навчанні, звіряємо з ручною розміткою — за кожним критерієм окремо, а не за середнім балом. Розбіжність вище допустимої означає повернення до формулювання, а не підкручування порогу.
-
Пілот на живому потоці. Включаємо систему на частині дзвінків, звіряємо оцінки з розбором керівника зміни, налаштовуємо пороги сповіщень. Видно, скільки розмов потребує уваги і як часто оцінка спірна.
-
Навчання команди. Показуємо керівникам, як читати звіт і як оспорити оцінку щодо конкретного дзвінка, операторам — як розбирати свої. Передаємо опис шкали та регламент її перегляду.
Конфігурації, схеми оцінювання та регламенти розмітки
Передаємо не презентацію, а робочий пакет: кожен документ прив'язаний до файлу в репозиторії замовника, тому правила оцінювання можна правити без нашої участі. Нижче — що залишається в команди після запуску автоматичного оцінювання дзвінків.
- Конфігурації оцінювання. Ваги критеріїв, пороги спрацювання та набори правил за типами дзвінків — файлами, які версіонуються разом із кодом; правка проходить той самий контрольний прогін на еталонній вибірці.
- Схема інтеграції з телефонією. Точка підключення до АТС, формати вивантаження записів, поведінка при обриві сегмента або затримці, куди надходить сигнал про помилку і як довантажуються пропущені дзвінки.
- Опис шкали. Що означає кожен бал, як рахується підсумок, які критерії обов'язкові, а які лише коригують оцінку, де межі «задовільно» та «потребує розбору».
- Політики доступу. Ролі — оператор, супервайзер, методист, аналітик: хто бачить запис і розшифровку, хто змінює шкалу, строки зберігання та правила знеособлення.
- Регламент спірних випадків. Як оператор оспорює оцінку, хто розбирає спір і в який строк, як рішення фіксується та потрапляє в донавчання системи.
- Інструкції для перевіряльників. Як збирати вибірку для контролю якості, що вважати розбіжністю з моделлю, за яким порогом розбіжностей переглядати правила.
Окремо ведемо журнал змін: дата, автор і причина кожної правки шкали — щоб через пів року було зрозуміло, чому оцінка змістилася.
Кейс: як прибрали вибіркову перевірку у відділі продажів
Відділ продажів — близько 40 операторів на двох лініях. Контроль якості тримався на трьох старших менеджерах: вони прослуховували 2-3% розмов, кожен за своїм чек-листом.
Зворотний зв'язок доходив до оператора через один-два тижні, а розбіжність оцінок між перевіряльниками на тому самому дзвінку сягала третини шкали — оспорити оцінку не було чим, критеріїв на руках не було.
Зібрали автоматичне оцінювання: записи підтягуються з телефонії та Бітрікс24, мовлення розпізнається, модель розмічає розмову за чек-листом — скрипт і привітання, виявлення потреби, робота із запереченнями, зафіксовані домовленості.
Кожен бал прив'язаний до фрагмента запису, тому оператор бачить, за що знято, і що переграти в наступній розмові.
Перевіряльники більше не слухають усе підряд: вони розбирають спірні випадки, які система позначає сама — низька впевненість розпізнавання, конфлікт критеріїв, заперечення без реакції оператора.
Метрики до та після
- Частка перевірених дзвінків: 2-3% → 100%.
- Час до зворотного зв'язку оператору: 7-14 днів → того ж дня, зазвичай протягом години після зміни.
- Розбіжність оцінок між перевіряльниками на одній розмові: близько 30% → у межах 5%.
- Спірні випадки, розібрані в день звернення: 10-15% → 9 із 10.
- Ручних прослуховувань у старших менеджерів стало приблизно втричі менше за повного покриття розмов.
Що робити, якщо записи лежать у розрізнених системах
Різні телефонії майже завжди означають різні джерела даних: хмарна АТС пише розмови у своєму сховищі та віддає їх через API, записи з другої системи вивантажуються файлами на сервер, а частина дзвінків надходить із месенджерів і мобільних застосунків менеджерів.
Формати теж не збігаються — стиснені та потокові, стерео й моно, з різною довжиною каналу та різною розміткою каналів «оператор/клієнт». Поки це не зведено до одного вигляду, будь-яке оцінювання дзвінків починається з ручної метушні, а не з аналізу.
Перший крок — інвентаризація джерел: які системи пишуть звук, де він зберігається, за якою ознакою кожен запис пов'язаний з угодою. Далі будується шар збору: конектори до API телефонії та CRM, вивантаження архівів, довантаження пропущених за період файлів.
Кожен запис отримує єдиний технічний паспорт — джерело, час, напрямок, учасники, канал. Це і є основа, без якої єдиний контур розмітки не збирається.
Ключова проблема в таких проєктах — зіставлення з історією угод.
Номер клієнта, внутрішній ідентифікатор у amoCRM, додатковий номер оператора та мітка часу рідко сходяться ідеально, тому ми робимо багатоступеневе зв'язування: точний збіг за ідентифікатором, потім за номером і вікном часу, потім ручна черга для спірних випадків.
Частка записів, прив'язаних до угоди, вимірюється на кожному прогоні — за нею видно, де рветься зв'язок.
Поверх цього збирається єдиний контур розмітки: транскрипт із розділенням за мовцями, прив'язка до етапу угоди, результати автоматичного оцінювання дзвінків та оцінка оператора.
Після цього дзвінки з усіх телефоній можна порівнювати між собою — за відділами, продуктами, стажем оператора.
Якщо частина записів історично залишилася без прив'язки, вони потрапляють в окремий шар: їх можна розмічати за змістом, а зв'язок із клієнтом відновлювати пізніше, коли з'явиться угода.
Спершу ми розбираємо вашу карту джерел і показуємо, яка частка дзвінків прив'язується до угод автоматично, а яка потребує доопрацювання.
Складні випадки: шум, перебивання, діалект, іронія
Шум і перебивання ламають розпізнавання не самі по собі, а на стиках: система позначає ділянку, де обидва канали говорять одночасно, і не склеює репліки в одну.
Записи надходять роздільними каналами — мовлення оператора та клієнта не змішується, тому перекриття видно позиційно, а не за здогадом. Такі ділянки не викидаються з оцінки: вони позначаються як спірні, бо саме там найчастіше губиться ключова фраза.
Діалект і сильний акцент б'ють по закінченнях, службових словах і назвах — сенс фрази вгадується, а точність за сутностями падає.
Ми розширюємо словник записами конкретного регіону й ухвалюємо рішення за наміром: якщо модель упевнена в суті запиту, але не впевнена в окремих словах, кейс оцінюється за змістом, а не відкидається.
Для переносного сенсу правило жорсткіше: іронія, сарказм та алегорії дають конфлікт між тональністю і смисловим тегом, і такий конфлікт автоматично не вирішується.
Там, де починається здогад, ми свідомо залишаємо ручну перевірку. Упевненість моделі порівнюється з порогом, який налаштовується під конкретний потік: зазвичай на прослуховування йде кілька відсотків дзвінків — ті, де оцінка розходиться з очікуваною або де сигнал обрізано.
Кожен перевірений запис повертається в розмітку, і правила уточнюються, а не залишаються зафіксованими раз і назавжди.
Що відбувається із записом, де канал глухий або обрізаний?
Система не добудовує фрази й не видає оцінку за здогадом — такий дзвінок позначається як непридатний для автоматичного розбору й уходить у чергу на прослуховування.
Якщо обрізаних записів стає багато, це видно за часткою спірних кейсів, і ми розбираємося з джерелом: налаштуваннями запису на боці телефонії, а не моделлю.
Чи можна зовсім відмовитися від ручної перевірки?
Технічно — так, поріг можна підняти до нуля, і всі дзвінки будуть оцінені автоматично. Але тоді спірні ділянки з іронією, перекриттями та діалектом отримають формальну оцінку, яка виглядає переконливо й потребує значних витрат під час розбору з оператором.
Гібридний режим дає стабільну якість: машина закриває основний обсяг, людина — лише те, де рішення неоднозначне.
Обговоримо задачу та повернемося з планом робіт
Щоб обговорити задачу предметно, а не в загальному вигляді, достатньо описати процес так, як він улаштований зараз: хто перевіряє дзвінки, за якими критеріями і скільки часу йде на одну вибірку.
Готувати технічне завдання заздалегідь не потрібно — його ми зберемо разом за вашими вихідними даними, а формальний документ на цьому етапі лише подовжить шлях.
Якщо є записи розмов і регламент оцінювання хоч у чернетковому вигляді, цього достатньо, щоб перейти від слів до оцінки обсягу.
- опис поточного контролю якості: хто оцінює, за якими критеріями, як часто і з якою періодичністю;
- знеособлена вибірка записів за кілька тижнів — обов'язково включно з тими розмовами, які сьогодні оцінюють як спірні;
- чинний регламент або чек-лист оцінювання, навіть якщо він живе в таблиці й ніде не затверджений;
- дані про навантаження: скільки дзвінків на день, яка частка потрапляє в перевірку, скільки часу займає розбір одного;
- відомості про системи, де вже зберігаються записи та результати оцінювання, і про те, як до них можна підключитися;
- обмеження щодо доступів і зберігання персональних даних, які потрібно врахувати до старту, а не після.
Після розбору ми повертаємося з оцінкою обсягу, порядком співпраці та планом робіт за етапами: підготовка даних і розмітка спірних випадків, налаштування та калібрування системи на вашій вибірці, перевірка точності на розмовах, де думки розходяться, і запуск у поточному процесі. План узгодимо до початку робіт, щоб очікування щодо обсягу та результату збігалися.
