Качество ответов первой линии проверяется на вашей выборке реальных обращений, а не на демонстрации подрядчика. Рабочая процедура выглядит так: собираете 200 обращений из собственного журнала, пишете к каждому эталонный ответ, прогоняете набор через систему и считаете четыре метрики. Пороги по каждой из них записываются в договор до начала работ, вместе с тем, что происходит при их невыполнении.
Главное число в этой процедуре — не доля закрытых обращений, а доля фактических ошибок: случаев, когда система назвала неверный срок, условие возврата или размер скидки. Красивые 70% автоматических ответов при трёх процентах вранья про деньги дороже, чем скромные 45% без единой такой ошибки, и это разница, которую видно в рублях.
Все расчёты ниже — на модельной компании кластера: 6 000 обращений в месяц, автоматически закрывается 45%, то есть 2 700 обращений, стоимость одного обращения 92 ₽, бюджет проекта 380 000 ₽. Порядок разбора: почему демонстрация ничего не доказывает, как собрать тестовый набор, четыре метрики и их пороги, цена ошибки в рублях, контроль после запуска и что делать с каждой найденной ошибкой.
Почему демонстрация подрядчика ничего не проверяет
На встрече показывают диалог: десять вопросов, десять быстрых уместных ответов. Проблема не в том, что показ подготовлен, — готовиться нормально. Проблема в том, что такая демонстрация методически не может обнаружить ни одной из четырёх вещей, которые ломают первую линию в эксплуатации.
- Вопросы выбраны исполнителем. В демонстрацию попадают темы, которые хорошо покрыты базой знаний, а в жизни поток определяется клиентами. Между «система отвечает на десять хороших вопросов» и «система закрывает 45% реального потока» нет никакой связи.
- Формулировки взяты из базы знаний. Клиент пишет не так: с опечатками, голосовым набором без пунктуации, двумя вопросами в одном сообщении и через отрицание — «а разве у вас не бесплатная доставка от трёх тысяч?». На таких формулировках доля верных ответов падает заметно, и именно поэтому они обязаны быть в тестовом наборе.
- Оценивается факт ответа, а не его верность. На демонстрации никто не сверяет названный срок возврата с действующим регламентом. В материале про долю обращений без оператора эта разница уже посчитана: система отвечает в 71% диалогов, а закрывает вопрос в 45%.
- Не проверяются стоп-темы и молчание. Демонстрация показывает, как система отвечает. Половина качества первой линии — в том, как она не отвечает: жалоба, возврат денег, здоровье, прямая просьба позвать человека должны уходить оператору без попытки ответить.
Тестовый набор: 200 обращений, собранных вами
Набор собирается из своего журнала обращений и остаётся у вас: он же будет использоваться при следующей приёмке, при смене подрядчика и при проверке после крупных правок базы знаний. Сплошной случайной выборки недостаточно — в 200 случайных обращениях редкие темы и неудобные формулировки почти не встретятся, а ломается система именно на них. Поэтому набор смешанный.
| Часть набора | Сколько | Как отбирается | Что проверяет |
|---|---|---|---|
| Сплошная выборка | 110 | Подряд за одну неделю, без отбора и без исключений | Реальную структуру потока: сколько закроется на типичном составе тем |
| Покрытие справочника тем | 40 | По одному-два обращения на каждую тему справочника, включая редкие | Хвост: темы, которые в случайной выборке не появятся |
| Неудобные формулировки | 25 | Опечатки, голосовой набор без пунктуации, два вопроса в сообщении, вопрос через отрицание | Устойчивость понимания там, где текст не похож на базу знаний |
| Стоп-темы | 25 | Жалобы, возвраты денег, здоровье, персональные данные, прямая просьба позвать человека | Молчание: система обязана передать человеку, не пытаясь ответить |
К каждому обращению пишется эталонный ответ — не «правильный по мнению подрядчика», а тот, который дал бы ваш лучший оператор со ссылкой на действующий регламент. Пишет их человек со стороны заказчика, обычно тот же старший оператор, который ведёт базу знаний поддержки. Спорные случаи — где два человека написали разные ответы — размечаются вторым сотрудником независимо: если люди между собой не сходятся, требовать согласия от машины бессмысленно.
Горизонтальная полоса из 200 делений, разбитая на четыре цветовых блока с подписями и числами: «сплошная выборка — 110», «покрытие справочника тем — 40», «неудобные формулировки — 25», «стоп-темы — 25». Под каждым блоком одной строкой, что он проверяет. Слева от полосы вертикальная подпись «тестовый набор остаётся у заказчика», справа — «33 000 ₽, полторы недели». Чертёжный стиль, подписи по-русски.
Четыре метрики и что ловит каждая
Одной цифрой качество первой линии не описывается: любая единственная метрика улучшается за счёт остальных. Долю автоматических закрытий легко поднять, разрешив системе отвечать увереннее, — вырастут ошибки. Ошибки легко убрать, передавая всё человеку, — рухнет доля закрытий. Поэтому метрики считаются одновременно и принимаются вместе.
| Метрика | Порог | Как считается на тестовом наборе | Что ловит |
|---|---|---|---|
| Доля решённых без человека | не ниже 45% | Ответ дан, передачи оператору не было, повторного обращения по той же теме за 72 часа нет | Реальную полезность: экономический смысл всего проекта |
| Доля фактических ошибок | не выше 2% от отправленных ответов | Ответ противоречит базе знаний, регламенту или данным учётной системы | Вранье про сроки, условия и деньги — самую дорогую категорию сбоев |
| Доля необоснованных эскалаций | не выше 25% от всех передач человеку | Ответ был в базе знаний, но система всё равно отдала диалог оператору | Перестраховку: систему, которая формально не ошибается, потому что почти не работает |
| Повторные по той же теме за 72 часа | не выше 10% | Тот же клиент, та же тема справочника, новое обращение в течение трёх суток | Ответы, которые формально даны, но вопрос не закрыли |
| Срабатывание стоп-тем | 100% на 25 обращениях | Передача человеку без попытки ответить, без уточняющих вопросов | Единственная метрика без допуска: одно срабатывание из 25 — уже провал |
Порог по эскалациям стоит пояснить отдельно. Нормальная доля передач человеку в первые месяцы — 10–20% потока, и снижать её надо пополнением базы знаний, а не понижением порога неуверенности; механика разобрана в материале про стоп-темы и перевод на оператора. Метрика приёмки смотрит не на общую долю передач, а на её качественный состав: сколько передач случилось там, где ответ в базе знаний был. Если таких больше четверти, система не понимает собственную базу, и лечится это правкой статей, а не настройками.
Четыре вертикальные шкалы-манометра в ряд, у каждой красная отметка порога и подпись. Шкала 1: «решено без человека», порог «не ниже 45%», зелёная зона сверху. Шкала 2: «фактические ошибки», порог «не выше 2%», зелёная зона снизу. Шкала 3: «необоснованные эскалации», порог «не выше 25% от передач», зелёная зона снизу. Шкала 4: «повторные за 72 часа», порог «не выше 10%», зелёная зона снизу. Пятым элементом сбоку — не шкала, а выключатель с двумя положениями и подписью «стоп-темы: 100% из 25, допуска нет». Чертёжный стиль, подписи по-русски.
Почему фактические ошибки дороже всех остальных метрик
Повторное обращение стоит вам одной обработки. Неверно названное денежное условие стоит либо уступки, либо жалобы — и то и другое дороже. Поэтому порог по ошибкам единственный, который мы предлагаем делать блокирующим: работа не принимается вообще, а не дорабатывается.
Ответ, который противоречит проверяемому источнику: статье базы знаний, действующему регламенту или данным учётной системы. Не путать с неудачной формулировкой и с неполным ответом — это отдельные, менее дорогие категории. Ключевое свойство фактической ошибки в том, что клиент действует по ней: планирует возврат в названный срок, ждёт названную скидку, рассчитывает на названные условия гарантии.
Теперь сравнение, ради которого расчёт и делался. Порог в 2% выглядит строгим ровно до того момента, пока не посмотреть, что бывает без него. Заброшенная база знаний уже через квартал даёт 7,7% ответов с устаревшими данными — это посчитано отдельно в разборе того, сколько стоит ведение базы знаний. Система, принятая по демонстрации и ни разу не проверенная на своей выборке, обычно живёт в диапазоне 5–8%. Разница между 2% и 6% — четыре процентных пункта, то есть 52 352 ₽ в месяц и 628 224 ₽ в год против разовых 33 000 ₽ на сборку тестового набора.
Столбиковая диаграмма из двух столбцов с общей осью в рублях в месяц. Столбец «порог приёмки 2%» — 26 176 ₽/мес. Столбец «без приёмки, 6%» — 78 528 ₽/мес. Между ними вертикальная стрелка с подписью «разница 52 352 ₽/мес, 628 224 ₽ в год». Внизу под осью горизонтальная линия-отсечка с подписью «сборка тестового набора — 33 000 ₽ разово». Сбоку мелкой строкой: «цена одного процентного пункта — 13 088 ₽/мес».
Пороги приёмки: что писать в договор
Порог, записанный как «система должна работать качественно», не порог. Проверяемая формулировка отвечает на четыре вопроса: какая метрика, какое значение, на какой выборке и кто считает. Без последних двух пунктов приёмка превращается в спор, потому что исполнитель посчитает на своих примерах и получит другую цифру — и формально будет прав.
| Метрика | Порог | Последствие невыполнения |
|---|---|---|
| Доля решённых без человека | не ниже 45% тестового набора | Доработка за счёт исполнителя, повторная приёмка через 2 недели |
| Доля фактических ошибок | не выше 2% отправленных ответов | Работа не принимается и не оплачивается до повторной приёмки |
| Доля необоснованных эскалаций | не выше 25% всех передач | Доработка за счёт исполнителя |
| Повторные по той же теме за 72 часа | не выше 10% | Доработка за счёт исполнителя |
| Срабатывание стоп-тем | 100% на 25 обращениях | Работа не принимается; допуска по этому пункту нет |
| Кто считает и на чём | Заказчик на своём тестовом наборе, набор передан исполнителю до начала работ | Расхождение в счёте разбирается по журналу прогонов, а не по устной версии сторон |
Прятать набор до приёмки бессмысленно: исполнитель всё равно будет настраивать систему на похожих обращениях, а вы получите приёмку-лотерею вместо инженерной работы. Набор отдаётся в начале проекта, вместе с эталонными ответами. Защита от подгонки — не секретность, а второй, контрольный набор из 50 обращений, собранный тем же способом уже после старта работ и не показанный никому. Расхождение метрик между основным и контрольным набором больше 7 процентных пунктов означает, что систему учили отвечать на конкретные вопросы, а не пользоваться базой знаний.
Контроль после запуска: 40 диалогов в неделю
Приёмка фиксирует состояние на один день. Дальше меняются прайс, условия доставки, ассортимент и регламенты, а база знаний отстаёт от них с задержкой — и доля ошибок ползёт вверх без единого изменения в системе. Поэтому выборочный контроль — не проектная работа, а постоянная строка эксплуатации, и её надо закладывать в смету наравне с ведением базы знаний.
- 1Размер выборки — 40 диалогов в неделю: это около 6% недельного объёма автоматических ответов при потоке 2 700 в месяц. Меньше 25 диалогов в неделю бессмысленно: при доле ошибок 2% ожидаемое число находок падает ниже одной, и вы неделями смотрите на чистую выборку, ничего не зная о реальном уровне.
- 2Выборка смещённая, а не случайная: 20 диалогов случайных и 20 с признаками проблемы — клиент переформулировал вопрос, попросил человека, обратился повторно в течение суток. Полностью случайная выборка тратит время на диалоги, где заведомо всё в порядке.
- 3Смотрит редактор базы знаний, а не подрядчик и не руководитель. У редактора уже есть контекст: он знает, какие статьи менялись на прошлой неделе и какие темы спорные. Три минуты на диалог, два часа в неделю, 8,6 часа в месяц по ставке 1 100 ₽ — это 9 460 ₽ в месяц отдельной строкой, помимо 23 200 ₽ на само ведение базы.
- 4Найденное попадает в тот же список правок, что и заявки от операторов, с обязательным типом ошибки. Без типа список превращается в свалку из формулировок вроде «бот ответил не то», по которой через месяц нельзя понять, что чинить в первую очередь.
- 5Раз в квартал прогоняется полный тестовый набор из 200 обращений. Это четыре часа работы и единственный способ увидеть медленный дрейф метрик, который на выборке в 40 диалогов в неделю статистически не виден.
Лента времени на один квартал с двумя дорожками. Верхняя дорожка — тринадцать одинаковых недельных отметок с подписью «40 диалогов: 20 случайных и 20 с признаками проблемы, 2 часа редактора, 9 460 ₽/мес». Нижняя дорожка — одна отметка в конце квартала с подписью «полный прогон тестового набора: 200 обращений, 4 часа». Между дорожками стрелка вниз с подписью «находки уходят в общий список правок с типом ошибки». Слева от ленты — вертикальная шкала с порогом «фактические ошибки не выше 2%». Чертёжный стиль, подписи по-русски.
Что делать с найденной ошибкой
Самая частая реакция на ошибку — «поправьте бота». Она почти всегда неверна: правка сценария или системного промпта чинит один конкретный случай и создаёт риск сломать десять соседних. Диагноз ставится по тому, где именно разорвалась цепочка, и в четырёх случаях из пяти лечение находится вне системы.
- 1Ответ противоречит базе знаний
Система нашла не ту статью. Лечится разведением похожих статей и правкой их заголовков и первых строк, а не настройками поиска. Типичная причина — две статьи об одном и том же с разными условиями применимости, написанные в разное время.
- 2Ответ соответствует базе, но база устарела
Правится статья, и одновременно — то, что не дало заметить устаревание: дата пересмотра, владелец статьи, привязка к источнику изменения. Если условия доставки поменял отдел логистики, а поддержка узнала от клиента, чинить надо канал уведомления, а не только текст.
- 3Ответ верен, но тема не должна отвечаться автоматически
Эмоциональное обращение, спор о деньгах, вопрос с юридическим оттенком. Здесь верный ответ всё равно вредит: он читается как отписка. Лечение — новая стоп-тема, а не улучшение формулировки. Разбор того, почему бот раздражает клиентов, показывает, что около 11% потока не должно обрабатываться автоматикой в принципе.
- 4Ответ верен, но неполон
Названо условие без ограничения: «возврат в течение 14 дней» без «кроме товаров из перечня». Лечится структурой статьи — одна статья на один вопрос, все условия применимости внутри текста, а не в приложенном файле, потому что длинную статью поиск режет на части.
- 5Система не поняла вопрос
Формулировка добавляется в примеры соответствующей темы справочника. Если за месяц набирается три похожих непонятых вопроса — это заявка на новую тему в справочнике обращений, а не на очередной пример.
| Куда уходит правка | Доля из 100 найденных ошибок | Кто делает |
|---|---|---|
| Правка базы знаний: статья устарела, неполна или путается с соседней | 62 | Редактор базы знаний |
| Правка справочника тем: вопрос не попал ни в одну тему или попал не в ту | 21 | Редактор совместно с руководителем поддержки |
| Новая стоп-тема: ответ верен, но тема не для автоматики | 11 | Владелец процесса, письменным решением |
| Правка сценария или интеграции: система не получила данные из учётной системы | 6 | Подрядчик |
Из этого распределения следует главный организационный вывод статьи. Владелец качества первой линии — редактор базы знаний на стороне заказчика, а не подрядчик: 94% правок делаются вашими руками и в ваших данных. Договор на поддержку системы, в котором исполнитель отвечает за качество ответов, но не имеет доступа к регламентам и не влияет на скорость их обновления, — договор, который не будет выполнен ни одной из сторон.
Когда полная процедура приёмки избыточна
Процедура стоит 33 000 ₽ на сборку набора и 9 460 ₽ в месяц на постоянный контроль. Есть случаи, где это дороже защищаемого, и признавать их честнее, чем продавать методику всем подряд.
- Система только отвечает на справочные вопросы и не называет условий с деньгами и сроками. Если весь охват — адрес, режим работы и как проехать, категория фактических ошибок почти пуста, и хватает набора из 50 обращений и проверки раз в квартал.
- Поток меньше 1 000 обращений в месяц. Один процентный пункт ошибок — это меньше пяти случаев, и статистически на выборке в 200 обращений вы их просто не увидите. Здесь работает не метрика, а сплошной просмотр всех автоматических ответов первые два месяца.
- Первая линия ничего не пишет клиенту сама, а только готовит черновик ответа оператору. Ответственность за верность остаётся на человеке, фактическая ошибка до клиента не доходит, и достаточно двух метрик: доли принятых черновиков и времени на правку.
- Внутренний бот для сотрудников, а не для клиентов. Цена ошибки другого порядка: коллега переспросит, а не потребует исполнить названное условие. Пороги смягчаются до 5% ошибок, контроль — раз в две недели.
Во всех остальных случаях порядок один: тестовый набор собирается до подписания договора, пороги попадают в договор до начала работ, а контрольный набор из 50 обращений собирается после старта и никому не показывается. Это дешевле, чем любой из способов узнать реальное качество на клиентах.
Система, принятая по демонстрации, проверена ровно на тех вопросах, которые к ней не придут.
