Покрытие речевой аналитики: какие звонки действительно дошли до разбора

Отчёт речевой аналитики показывает только успешно обработанные записи, поэтому расхождение с телефонией выглядит как потеря. Чтобы понять, куда делись разговоры, нужен исходный реестр входа и разбивка по статусам обработки.

Покрытие речевой аналитики — это доля записей, дошедших до успешного разбора, от общего числа записей в исходном реестре входа за тот же период. Считать его нужно по первичному источнику, а не по отчёту аналитики, и отдельно показывать ожидающие, исключённые, ошибочные и дублирующиеся записи. Оговорка: без единого правила привязки к периоду и явных правил исключения проценты несопоставимы.

Представьте условный отдел продаж, где за месяц, по данным телефонии, было 4 800 входящих и исходящих звонков, а в отчёте речевой аналитики за тот же период оказалось 3 900 разобранных разговоров. Руководитель смотрит на два числа, не понимает разницы в 900 записей и делает вывод, что «аналитика врёт». На самом деле она может не врать — она просто отвечает на другой вопрос. И пока этот вопрос не сформулирован, любые проценты покрытия превращаются в гадание.

Механизм здесь простой, но его легко упустить: между событием «звонок состоялся» и событием «разговор попал в выборку анализа» лежит цепочка передачи записи, загрузки, постановки в очередь, обработки и сохранения результата. На каждом шаге часть записей может отсутствовать по разным причинам — и каждая причина требует своего знаменателя. Покрытие речевой аналитики — это не одно число, а набор отношений между состояниями записей. Ниже — методика, как собрать исходный реестр входа, разложить его по статусам и понять, где именно теряются разговоры.

Исходный реестр входа: откуда берётся знаменатель

Первый шаг — договориться, что считать знаменателем. Обычно его берут из отчёта телефонии или из выгрузки АТС, потому что именно там фиксируется факт соединения. Но и здесь есть развилка: считать все попытки дозвона, только состоявшиеся соединения или только разговоры длиннее определённого порога. Если в телефонии 4 800 событий, а в аналитику физически не могут попасть, скажем, несостоявшиеся вызовы без аудио, то честный знаменатель — не 4 800, а число записей, которые вообще были созданы. Эти условные цифры нужны только для иллюстрации логики, а не как норматив.

Практическая рекомендация: строить реестр входа не из отчёта аналитики, а из первичного источника — журнала звонков АТС или выгрузки записей. В реестре на каждую запись должны быть идентификатор звонка, время начала, направление, длительность, тип (входящий, исходящий, внутренний), ссылка на файл записи и текущий статус обработки. Тогда любой процент покрытия считается как доля записей в нужном статусе от общего числа записей в реестре за тот же период. Без такого реестра вы сравниваете отчёт с отчётом и спорите о том, чей знаменатель правильнее.

Отдельно стоит зафиксировать, что реестр входа — это не отчёт для руководства, а рабочий объект для сверки. Его ценность в том, что он позволяет увидеть не только «сколько разобрано», но и «что именно не разобрано и почему». Как только реестр появляется, разговор о покрытии переходит из плоскости доверия к системе в плоскость конкретных статусов.

Если ваша задача — сверить покрытие анализа, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Пять состояний записи, которые нельзя смешивать

Любая запись в цепочке обработки находится в одном из состояний, и смешивать их в одном проценте — главная методическая ошибка. Условно можно выделить пять состояний: ожидает обработки, обрабатывается, обработана успешно, исключена по правилу и завершилась ошибкой. Каждое состояние отвечает на свой вопрос и имеет свой знаменатель.

Если сложить «обработана» и «исключена» и назвать это покрытием, вы завысите картину: исключённые записи не анализировались. Если сложить «обработана» и «ошибка», вы смешаете успешный разбор с техническими потерями и получите число, которое не отражает ни фактическое покрытие, ни долю сбоев. Корректный подход — показывать покрытие как долю успешно обработанных от общего числа записей, а рядом отдельными строками выводить доли ожидающих, исключённых и ошибочных. Тогда число 3 900 из 4 800 перестаёт быть загадкой: возможно, 300 записей ещё в очереди, 400 исключены по правилу коротких вызовов, а 200 упали с ошибкой.

Важно, чтобы статус был у каждой записи, а не вычислялся задним числом из наличия результата. Запись без результата — это не «нулевое покрытие», это неизвестный статус, и его нужно явно помечать. Иначе пустые файлы и потерянные записи сливаются в одну серую массу.

Пустой файл: когда запись есть, а разбирать нечего

Условный эпизод: в реестре входа есть звонок длительностью 47 секунд, файл записи присутствует, но его размер — ноль байт. Телефония считает звонок состоявшимся, реестр видит запись, а система анализа получает пустой файл и не может его обработать. Если такие случаи не отделять, они попадут в «ошибки» и испортят статистику технических сбоев, хотя на самом деле это проблема на стороне записи, а не обработки.

Правильная реакция — отдельный статус «пустой файл» и правило: такие записи не считаются ни разобранными, ни технически ошибочными, а выносятся в отдельную категорию с указанием причины. Дальше вопрос к тому, кто отвечает за запись: возможно, на стороне АТС сбой, возможно, звонок прервался до начала записи. Это уже не задача речевой аналитики, но покрытие без учёта этой категории будет неполным.

Стоит проверять размер файла и его длительность ещё на входе, до постановки в очередь. Это дешевле, чем гонять пустой файл через распознавание и получать ошибку на выходе. И это делает реестр честнее: вы заранее знаете, что часть записей физически не содержит аудио.

Запись ещё обрабатывается: почему «сегодня» и «вчера» не сравнимы

Второй условный эпизод: руководитель сравнивает покрытие за вчера и за позавчера и видит, что вчера оно ниже. Причина может быть не в потерях, а в том, что часть вчерашних записей ещё стоит в очереди. Обработка не мгновенная: запись загружается, распознаётся, разбирается, результат сохраняется. В зависимости от объёма и настроек очереди задержка может составлять часы, а на пиковых нагрузках — дольше.

Отсюда правило: сравнивать покрытие можно только по «закрытым» периодам, где все записи достигли финального статуса. Для свежих периодов нужно показывать не только долю обработанных, но и долю записей в ожидании и обработке. Иначе вы сравниваете завершённый вчерашний день с незавершённым сегодняшним и делаете неверный вывод.

Полезно ввести понятие «возраст записи»: сколько времени прошло с момента появления записи в реестре. Если запись висит в ожидании дольше согласованного порога, это сигнал о проблеме с очередью, а не о нормальной задержке. Порог — вопрос договорённости внутри процесса, а не универсальная норма. Но без него «ещё обрабатывается» превращается в удобное объяснение для любой задержки.

Дубликат: одна запись, два идентификатора

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

Распознавать дубликаты лучше по совокупности признаков: идентификатор звонка в телефонии, время начала, длительность и, если доступно, хеш аудиофайла. Один идентификатор звонка — самая надёжная связка, если телефония его передаёт. Если не передаёт, приходится опираться на время и длительность, что менее надёжно.

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

Исключённый тип: осознанные потери, которые надо назвать

Часть записей исключается по правилам осознанно. Например, внутренние звонки между сотрудниками, короткие вызовы без содержательного разговора, автоответчики, служебные номера. Это не потери обработки, а решение о том, что анализировать. Но если такие записи просто исчезают из отчёта, покрытие выглядит ниже реального, а причина не видна.

Правило должно быть явным и зафиксированным: какие типы записей исключаются, по какому признаку и кто это правило утвердил. В реестре у исключённой записи должен быть статус «исключена» и причина исключения. Тогда в отчёте покрытия появляется отдельная строка: столько-то записей исключено по правилу, и это ожидаемо.

Отдельный вопрос — пересмотр правил. Если правило исключения меняется, покрытие за прошлые периоды может стать несравнимым с текущим. Поэтому правило стоит версионировать: хранить, по какой версии правила запись была исключена. Иначе через полгода никто не вспомнит, почему часть записей выпала.

Ошибка загрузки: техническая потеря, которую видно только в реестре

Ошибка загрузки — это запись, которая должна была попасть в анализ, но не попала из-за сбоя. Она может не появиться в отчёте аналитики вообще, потому что отчёт строится по успешно обработанным записям. Именно поэтому реестр входа обязателен: без него ошибка загрузки невидима.

Ошибки загрузки стоит классифицировать: сбой сети, отказ авторизации, превышение лимита, некорректный формат файла. Классификация помогает понять, где чинить, и отделить разовые сбои от системных. И она же даёт материал для проверки: если ошибки одного типа повторяются, это уже не случайность.

Важно не прятать ошибки в общий процент. Если 200 записей упали с ошибкой, а вы показываете только «покрытие 81%», никто не поймёт, что 4% разговоров потеряно технически. Ошибки должны быть отдельной строкой с динамикой.

Разные окна времени в двух отчётах

Классическая ловушка: отчёт телефонии и отчёт аналитики строятся по разным окнам времени. Один считает звонки по времени начала, другой — по времени завершения или по времени загрузки записи. Звонок, начавшийся в 23:58 и закончившийся в 00:03, попадёт в разные дни в двух отчётах. На коротком периоде это даёт расхождение, которое легко принять за потерю.

Решение — договориться об одном правиле привязки записи к периоду и применять его во всех отчётах. Обычно это время начала звонка, но правило может быть и другим — главное, чтобы оно было единым и задокументированным. В реестре входа нужно хранить и время начала, и время завершения, и время загрузки, чтобы при сверке можно было пересчитать по любому правилу.

Отдельно стоит проверить часовые пояса. Если телефония пишет время в одном поясе, а аналитика — в другом, расхождение может достигать нескольких часов, и часть записей «переедет» в соседний день. Это скучная деталь, но именно она часто объясняет загадочные расхождения, которые ищут неделями.

Реестр покрытия звонков: что должно быть в реестре

Реестр входа — это таблица, где каждая строка соответствует одной записи, а столбцы описывают её путь. Минимальный набор полей: идентификатор записи, идентификатор звонка, время начала и завершения, длительность, направление, тип, размер файла, ссылка на аудио, текущий статус, причина статуса, версия правила исключения, время последнего изменения статуса. Этого достаточно, чтобы считать покрытие по любому срезу и объяснить каждую потерю.

Форма важна не сама по себе, а потому что она задаёт вопросы, на которые отчёт обязан отвечать. Если в реестре есть поле «причина», то в отчёте появляется разбивка по причинам. Если есть «версия правила», то можно сравнить периоды корректно. Если есть «время последнего изменения статуса», то видно, какие записи зависли.

Реестр не обязан быть красивым дашбордом. На первом этапе это может быть выгрузка в таблицу, которую ответственный сотрудник сверяет раз в неделю. Главное — чтобы она существовала и обновлялась, иначе покрытие остаётся числом без происхождения.

Реестр покрытия звонков на экране сотрудника

Сотруднику, который отвечает за качество данных, нужен не процент покрытия, а список записей, требующих внимания. Интерфейс должен позволять фильтровать по статусу, сортировать по возрасту записи и видеть причину. Тогда работа превращается из «посмотреть отчёт» в «разобрать очередь проблем».

Разумно разделить два экрана. Первый — сводка для руководителя: покрытие, доли ожидающих, исключённых и ошибочных, динамика по закрытым периодам. Второй — рабочий список для сотрудника: конкретные записи с проблемами, сгруппированные по причине, с возможностью переотправить запись или пометить как разобранную вручную. Это разные аудитории и разные задачи, и смешивать их в одном экране не стоит.

В рабочем списке полезно показывать «возраст» записи и то, сколько раз она пыталась обработаться. Запись, которая падает с ошибкой третий раз, — это уже не случайный сбой, а повод разбираться. И сотрудник должен видеть, что с ней уже делали, чтобы не повторять одни и те же действия.

Как проверять покрытие: несколько тестов на согласованность

Проверка покрытия — это не разовое упражнение, а набор регулярных тестов на согласованность данных. Первый тест: сумма записей по всем статусам должна равняться общему числу записей в реестре за период. Если не равняется, значит, часть записей потерялась между системами или статус не проставлен. Второй тест: число обработанных записей в реестре должно совпадать с числом записей в отчёте аналитики за то же окно времени. Расхождение — сигнал о разных правилах привязки к периоду.

Третий тест: записи со статусом «ожидает» не должны быть старше согласованного порога. Если такие есть, очередь работает неправильно. Четвёртый тест: доля дубликатов не должна расти от периода к периоду — рост говорит о проблеме в интеграции. Пятый тест: исключённые записи должны иметь причину и версию правила; записи без причины — это скрытые потери.

Эти тесты не требуют сложной инфраструктуры. Их можно реализовать как набор запросов к реестру, которые запускаются по расписанию и складывают результат в отдельную таблицу. Главное — не считать покрытие один раз, а проверять его регулярно и смотреть на динамику.

Практикум: сверка покрытия на условном примере

Возьмём условный месяц и условные числа, чтобы пройти путь целиком. В реестре входа 5 000 записей. Из них 4 100 обработаны успешно, 350 ожидают обработки, 300 исключены по правилу коротких вызовов, 150 завершились ошибкой загрузки, 100 оказались дубликатами. Сумма: 4 100 + 350 + 300 + 150 + 100 = 5 000. Реестр сходится, это первый признак порядка.

Теперь считаем покрытие. Если брать все 5 000 записей, покрытие — 82%. Но 100 дубликатов не должны входить в знаменатель, потому что это не отдельные разговоры. Если их исключить, знаменатель — 4 900, покрытие — около 84%. Если дополнительно исключить 300 записей по правилу, знаменатель станет 4 600, а покрытие — около 89%. Каждое число верно для своего вопроса, и задача — не выбрать «правильное», а явно назвать, что вы считаете.

Дальше смотрим на ожидающие 350 записей. Если период ещё не закрыт, это нормально. Если период закрыт, а 350 записей всё ещё в ожидании, это проблема очереди. Смотрим на 150 ошибок: если они одного типа, это системный сбой; если разных — возможно, разовые. Смотрим на 100 дубликатов: если они появились в одном интервале времени, стоит проверить, что происходило с интеграцией в этот момент.

Итог практикума — не одно число, а таблица из нескольких строк: покрытие по всем записям, покрытие без дубликатов, покрытие без дубликатов и исключённых, доля ожидающих, доля ошибок, доля дубликатов. Такая таблица отвечает на разные вопросы и не даёт спрятать потери за общим процентом.

Реестр покрытия звонков: когда правило не срабатывает однозначно

Не все записи укладываются в пять состояний. Бывают пограничные случаи: звонок длился 12 секунд, и правило исключает короткие вызовы, но в этом разговоре клиент успел назвать проблему. Формально запись исключена, содержательно — потеряна. Такие случаи стоит выносить в отдельную категорию «исключена, но требует проверки» и периодически просматривать выборку.

Другой случай — запись, которая обработалась, но результат пустой: распознавание вернуло текст, а разбор не выделил ни одной сущности. Формально это успешная обработка, но содержательно — возможно, потеря. Здесь помогает выборочная проверка: брать долю «успешных, но пустых» записей и смотреть, что в них. Если доля растёт, стоит проверить качество распознавания, но это уже соседняя тема, а не покрытие.

Третий случай — записи, которые появились в реестре, но не имеют идентификатора звонка. Их нельзя связать с телефонией, и они висят как «неопознанные». Это не ошибка обработки, а проблема передачи данных. Такие записи нужно помечать и разбирать отдельно, иначе они либо завышают покрытие, либо теряются в общей массе.

Что делать с полученной картиной

Покрытие речевой аналитики — это не метрика качества распознавания и не показатель доставляемости в CRM. Это ответ на вопрос «какая доля записей дошла до разбора и что случилось с остальными». Пока на этот вопрос нет ответа с разбивкой по статусам, любые выводы о качестве анализа преждевременны: вы можете изучать прекрасно разобранные 80% разговоров и не знать, что в оставшихся 20% были самые важные звонки.

Работа с покрытием начинается с реестра входа и заканчивается регулярной сверкой. Между этими точками — явные правила исключения, классификация ошибок, борьба с дубликатами и единое правило привязки к периоду. Ни один из этих шагов не требует сложных технологий, но каждый требует договорённости о том, что считать потерей, а что — ожидаемым поведением.

Конкретный шаг проверки, с которого стоит начать: возьмите один закрытый период, выгрузите реестр входа из первичного источника и постройте таблицу статусов. Если сумма по статусам не сходится с общим числом записей — вы нашли первую дыру, и она важнее любого процента покрытия. Дальше можно двигаться по статусам: что в ожидании, что исключено, что упало. Так покрытие превращается из абстрактного числа в список конкретных задач.

Отдельно стоит договориться, кто отвечает за каждую категорию. Ошибки загрузки — зона интеграции. Пустые файлы — зона телефонии. Дубликаты — зона передачи данных. Исключения — зона правил анализа. Пока ответственные не назначены, статусы будут копиться, а покрытие — падать без объяснений. Это организационный вопрос, но без него методика остаётся теорией.

И последнее: не пытайтесь свести покрытие к одному числу для отчётности. Одно число удобно, но оно скрывает причины. Набор из нескольких строк — покрытие, ожидание, исключения, ошибки, дубликаты — занимает немного места, но отвечает на вопрос «почему» и позволяет увидеть динамику. Именно динамика, а не абсолютное значение, показывает, работает ли процесс.

Проверка по применимым документам и внутренним регламентам — задача уполномоченного сотрудника. Методика выше описывает, как организовать сверку, а не устанавливает нормы или обязанности. Решение о том, какие пороги и правила использовать, принимается внутри процесса и фиксируется в документах.

Смежный вопрос разобран отдельно: Качество распознавания речи: WER и ошибки в суммах.