Щотижнева перевірка якості ШІ-відповідей

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

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

Які діалоги читати, а які пропустити?

Читати треба тільки два типи. Решту — пропустити, вони нічого не скажуть.

1. 1

   Обірвані діалоги

   Асистент відповів — клієнт замовк. Найчастіша причина: відповідь не дала наступного кроку.

2. 2

   Передані менеджеру

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

3. 3

   Повторні питання

   Клієнт перепитує те саме двічі — відповідь була формально правильною й незрозумілою.

4. 4

   Успішні — вибірково

   Два-три для контролю тону. Не більше: вони підтверджують, а не вчать.

Що саме вимірювати?

Три числа, які можна порахувати вручну по вибірці:

1. Скільки діалогів дійшли до наступного кроку — тобто клієнт назвав розмір, місто, або погодився на оформлення. Це і є користь.
2. Скільки пішли до людини — і головне, з якої причини. Правильна передача (скарга, торг) — це успіх, а не збій. Передача через «не зрозумів питання» — збій.
3. Скільки обірвалися після відповіді асистента. Якщо ця частка не падає між тижнями, проблема в структурі відповідей, а не в окремих формулюваннях.

Коли правити інструкцію, а коли додавати сценарій?

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

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

Як не зламати те, що працює?

Одна зміна за ітерацію. Це нудно й це єдиний спосіб зрозуміти, що подіяло.

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

Чекліст щотижневої перевірки

1. Відкрити діалоги за тиждень, відібрати обірвані й передані людині.
2. Прочитати 10–15, помітити повторювані причини (не окремі помилки — саме патерни).
3. Порахувати три числа: дійшли до кроку / пішли до людини / обірвалися.
4. Вибрати ОДНУ зміну інструкції, яка закриває найчастіший патерн.
5. Прогнати набір тестових питань до й після зміни.
6. Записати рядок у таблицю тижня.