Проектирование механизма апелляций

Продукт

Naumen Conversation Intelligence — платформа речевой аналитики для контакт-центров. Продукт анализирует диалоги операторов с клиентами и помогает контролировать качество обслуживания. Один из важных процессов — ручная оценка: эксперты прослушивают диалоги и оценивают их по набору критериев. Результат оценки напрямую влияет на зарплату и премию оператора.

Проблема

Возможность оспорить оценку формально существовала, но жила вне системы. Процесс выглядел так: оператор смотрит оценку в продукте → ищет нужного эксперта в чате или через другого человека → пишет, что не согласен → ждёт ответа. Запросы терялись, договорённости забывались, статус невозможно было отследить. Из-за затянувшихся разбирательств сотрудники не получали премию вовремя.

Задача: перевести хаотичный процесс в управляемый механизм внутри продукта.

Сложность

1. Много ролей — и у каждой своё поведение

В процессе участвуют 3 основные роли: оператор, эксперт, главный эксперт (контролер). У каждой — свой набор действий, свой уровень видимости, свои ограничения. Нужно было спроектировать поведение для каждой роли отдельно и предусмотреть все пересечения: что видит эксперт, когда апелляция ушла к главному эксперту? Что видят остальные пользователи, пока апелляция на рассмотрении?

2. Синхронизация с существующей переоценкой

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

3. Нет референсов

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

Исследование

Провела интервью с 5 операторами и 3 экспертами. Ключевые инсайты:

Что важно оператору

• Видеть детали оценки при подаче апелляции — конкретный критерий, комментарий проверяющего
• Иметь возможность прикрепить ссылку на документацию или базу знаний в обоснование
• Отслеживать поданную апелляцию — в каком она статусе, рассмотрена или нет

Что важно эксперту

• Видеть оценку целиком при ответе на апелляцию
• Иметь возможность переоценить диалог или отклонить с обоснованием
• Не путать апелляцию с обычной переоценкой

Процесс работы над задачей

Рассматривала два варианта.

Вариант A: апелляция в отдельном сайдшите

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

Поэтому первый концепт — апелляция в отдельном сайдшите. Чтобы сохранить контекст оценки, добавила внутрь аккордеон с критериями.

Результат: хотела разгрузить основной блок — а получила дублирование. Блок оценки фактически копировался внутрь апелляции. Плюс отдельный слой не был синхронизирован с переоценкой — появлялся риск «подвисших» апелляций.

Вариант A — апелляция в отдельном сайдшите

Вариант B: апелляция внутри блока оценки

Апелляция встроена в существующий блок оценки как аккордеон. Оператор нажимает «Оспорить» — раскрывается секция с полем обоснования. Ниже — все критерии и комментарии эксперта. Эксперт в том же блоке видит апелляцию и может переоценить диалог или отклонить с обоснованием.

Выбрала вариант B — он не дублирует информацию и связывает апелляцию с переоценкой в одном месте.

Карточка оценки у оператора

Оператор отправил апелляцию

Эксперту пришла апелляция

Эксперт отклоняет апелляцию

Детали решения

Аккордеон — скрыт по умолчанию

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

Работа с ролевой моделью

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

Информирование пользователя заранее

Количество апелляций ограничено настройками проекта. Оператор заранее видит сколько попыток осталось. Когда лимит исчерпан — действие недоступно с понятным объяснением. Важно было сообщить об ограничении до того, как оператор начал писать обоснование, а не после.

Синхронизация с переоценкой

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

История

Вся цепочка апелляций сохраняется в оценке: обоснования, ответы, даты, ФИО. Доступна всем ролям, даже если апелляцию на проекте потом отключили.

Валидация

Перед передачей в разработку проверила решение на пользователях — прошла сценарии для каждой роли. Убедилась, что процесс в целом читается без объяснений.

Результат