01. Аудит 100 % звонков и переклассификация без повторного ASR
| Статус | ядро продукта, в MVP (январь 2027) |
| Тариф | все подписки; в API-режиме — транскрипт + метрики |
| Зависимости | Архитектура: пайплайн, стек, безопасность §2, §4 |
Проблема
Отдел контроля качества физически слушает 1–7 % звонков: выборка формируется вручную, а «неудобные» звонки (короткие, с конфликтом, с отказами) в неё не попадают. Руководитель принимает решения по 3 % разговоров и считает, что знает про остальные 97 %.
Вторая, менее очевидная проблема: модель классификации устаревает. Сменился скрипт, появилась новая кампания, изменилась таксономия — и весь исторический массив звонков описан старыми метками. У классических решений повторный разбор означает повторный прогон распознавания: дорого, долго, иногда невозможно (аудио уже удалено).
Решение
Разделяем дорогое и дешёвое. Распознавание (ASR) делается один раз и сохраняется в S3/MinIO как JSON с таймкодами. Классификация — отдельная стадия, которая читает транскрипт и пишет вердикт по ключу call_id + taxonomy_version.
Отсюда три следствия, которые и продаются:
- 100 % покрытие. Обрабатываются все записи, без выборок и «ручных отборов». Стоимость
минуты это позволяет: полный охват дешевле, чем сегодняшний частичный аудит силами ОКК (Цены и тарифы: подписки, API и on-prem §3).
- Переклассификация архива за часы. Изменили таксономию или промпт — запускается только
стадия классификации. ASR не повторяется. Пересчёт 6 млн звонков — это работа LLM-слоя, а не GPU-распознавания: часы вместо недель.
- Сравнение версий таксономии. Каждый вердикт хранит
taxonomy_version, поэтому можно
ответить на вопрос «сколько было бы конфликтов, если считать по новому определению» — без повторной обработки аудио.
Как это выглядит
- Дашборд покрытия: «обработано 100 % из 1 284 930 звонков за период», отдельно — доля
звонков, где сработала очередь ручного контроля.
- Кнопка «Переклассифицировать»: выбор периода + версии таксономии → задача с прогрессом
и ETA; по завершении — отчёт «что изменилось» (сколько звонков сменило метку).
- API:
POST /v1/reclassify {from, to, taxonomy_version}→job_id;
GET /v1/jobs/{job_id} → прогресс. Тарификация — по полям classification.*, без повторной оплаты минут.
Метрики успеха
| Метрика | Цель |
|---|---|
| Доля обработанных звонков от поступивших | 100 % (SLA ≤ 24 ч, цель ≤ 30 мин) |
| Время переклассификации 1 млн звонков | ≤ 6 ч |
| Стоимость переклассификации минуты | ≤ 0,03 ₽ |
| Доля звонков в очереди ручного контроля | ≤ 5 % (порог уверенности настраивается) |
Этапы
- MVP: разделение стадий, версионирование таксономии, дашборд покрытия.
- v1.1: переклассификация по кнопке и через API, отчёт «что изменилось».
- v1.2: переклассификация расписанием (при изменении таксономии — автоматически на
последние N месяцев).
Монетизация
Фича не тарифицируется отдельно — она делает осмысленной саму подписку: клиент платит за объём минут, а не за «повторную обработку». Технический эффект: переклассификация обрабатывается LLM-слоем автоматически, поэтому её можно включать в тариф без оговорок.
Почему этого нет у других
- SaaS для отделов продаж (Rechka, SalesAI, DEERAY): классификация и распознавание
связаны в один прогон — «пересчитать по-новому» означает заплатить за минуты снова.
- API-конструкторы (SpeechSense, SaluteSpeech): переклассификация — задача клиента;
аналитического слоя и версий таксономии там нет.
- Enterprise-вендоры (ЦРТ, BSS, Naumen): умеют, но это часть проекта внедрения — каждое
изменение таксономии идёт через подрядчика и счёт.
Исходный markdown