Механизм апелляций: 100% споров перешли в продукт
Саммари
Спроектировала функцию оспаривания оценок для платформы речевой аналитики. Весь процесс жил в чатах и почте. Провела исследование, определила подход и спроектировала решение. За 3 месяца все апелляции перешли в продукт.
Контекст
Naumen Conversation Intelligence — платформа для аналитики голосовых, текстовых и роботизированных коммуникаций в контакт-центрах. Один из сценариев использования: эксперты оценивают диалоги операторов по критериям, и эти оценки напрямую влияют на зарплаты и премии.
Проблема
Клиент пришёл с запросом: нужна функция оспаривания оценок внутри продукта. На брифе стало понятно что за этим стоит более глубокая проблема.
Оспорить оценку можно было, но в личной переписке. Обсуждения в чатах и почте терялись, не имели статуса, не фиксировались. Около 20% оценок оспаривались потому что напрямую влияли на премии.
Для бизнеса это не просто про неудобство. Ощущение несправедливой оценки влияет на мотивацию и удержание операторов.
Задача
Перевести процесс оспаривания оценок внутрь продукта, чтобы пользователи могли подать апелляцию и отслеживать статус на каждом этапе.
Критерий успеха: 90%+ апелляций проходят внутри продукта в течение квартала.
Исследование
Провела интервью с 5 операторами и 5 экспертами, чтобы понять как устроен процесс оспаривания сейчас.
Главная боль оператора — отсутствие обратной связи после отправки. Непонятно дошло ли обращение и будет ли кто-то его рассматривать. Из-за этого начинали писать повторно.
Отдельно выяснилось что перед подачей апелляции и операторы и эксперты возвращаются к оценке: переслушивают диалог, проходят по критериям, смотрят комментарии. Весь нужный контекст находится в блоке оценки, но интерфейс там перегружен. Это и стало главным ограничением при проектировании.
Поиск решения
Я рассматривала два подхода: вынести апелляцию в отдельный слой или встроить её в существующий блок оценки.
Вариант с отдельным слоем
Первый казался проще, потому что не нужно трогать перегруженный интерфейс. Но когда сделала прототип, стало видно проблему: оценка оказывалась в двух местах одновременно и они могли разойтись. Например диалог уже переоценён, а апелляция по нему всё ещё открыта.
Вариант с встраиванием в оценку
Выбрала второй вариант: апелляция живёт там же где оценка. Сложнее с интерфейсом, зато всё в одном месте и ничего не теряется.
Решение
Апелляция появляется прямо в карточке оценки. Оператор подаёт её там же где видит результат, эксперт там же разбирает. Не нужно переключаться между экранами и искать контекст в другом месте.
У каждой роли свой набор действий: оператор подаёт апелляцию, эксперт рассматривает, главный эксперт контролирует. Статус и история видны всем участникам. Исчезает ситуация когда непонятно что вообще происходит с обращением.
Переоценку при открытой апелляции намеренно ограничили: она возможна только внутри апелляции. Это связывает два процесса и не даёт им разойтись.
Отдельно решала вопрос с уведомлениями. В продукте не было центра уведомлений, поэтому решила подсветить апелляции в списке оценок. Не идеальное решение, но оно не требовало усложнения системы и не давало апелляциям теряться.
Валидация
Перед передачей в разработку протестировала прототип на 5 пользователях. Основной сценарий проходили без затруднений, но появился инсайт который я упустила на интервью.
Я предполагала что апелляция — это текстовое обоснование. На практике операторы почти всегда аргументируют ссылками на регламенты, базу знаний или скрипты. Во время теста спрашивали: «А я могу сюда вставить ссылку?». Добавила возможность прикреплять ссылку прямо в комментарий. Без этого сценарий оставался неполным.
Результат
Операторы подают апелляцию и отслеживают статус, эксперты работают с ней в одном месте вместе с оценкой. То что раньше терялось в чатах и почте теперь живёт внутри системы.