# 01. Аудит 100 % звонков и переклассификация без повторного ASR

| | |
|---|---|
| **Статус** | ядро продукта, в MVP (январь 2027) |
| **Тариф** | все подписки; в API-режиме — транскрипт + метрики |
| **Зависимости** | [02-architecture.md](../02-architecture.md) §2, §4 |

## Проблема

Отдел контроля качества физически слушает 1–7 % звонков: выборка формируется вручную, а
«неудобные» звонки (короткие, с конфликтом, с отказами) в неё не попадают. Руководитель
принимает решения по 3 % разговоров и считает, что знает про остальные 97 %.

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

## Решение

**Разделяем дорогое и дешёвое.** Распознавание (ASR) делается один раз и сохраняется в
S3/MinIO как JSON с таймкодами. Классификация — отдельная стадия, которая читает транскрипт
и пишет вердикт по ключу `call_id + taxonomy_version`.

Отсюда три следствия, которые и продаются:

1. **100 % покрытие.** Обрабатываются все записи, без выборок и «ручных отборов». Стоимость
   минуты это позволяет: полный охват дешевле, чем сегодняшний частичный аудит силами ОКК
   ([06-pricing.md](../06-pricing.md) §3).
2. **Переклассификация архива за часы.** Изменили таксономию или промпт — запускается только
   стадия классификации. ASR не повторяется. Пересчёт 6 млн звонков — это работа LLM-слоя,
   а не GPU-распознавания: часы вместо недель.
3. **Сравнение версий таксономии.** Каждый вердикт хранит `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 % (порог уверенности настраивается) |

## Этапы

1. **MVP:** разделение стадий, версионирование таксономии, дашборд покрытия.
2. **v1.1:** переклассификация по кнопке и через API, отчёт «что изменилось».
3. **v1.2:** переклассификация расписанием (при изменении таксономии — автоматически на
   последние N месяцев).

## Монетизация

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

## Почему этого нет у других

- **SaaS для отделов продаж** (Rechka, SalesAI, DEERAY): классификация и распознавание
  связаны в один прогон — «пересчитать по-новому» означает заплатить за минуты снова.
- **API-конструкторы** (SpeechSense, SaluteSpeech): переклассификация — задача клиента;
  аналитического слоя и версий таксономии там нет.
- **Enterprise-вендоры** (ЦРТ, BSS, Naumen): умеют, но это часть проекта внедрения — каждое
  изменение таксономии идёт через подрядчика и счёт.