Раздел «Входящие» в CRM-системе
Раздел «Входящие» в CRM используется для обработки уведомлений, активностей и запросов на согласование. Он задумывался как единая точка входа для всех событий системы, однако пользователи редко обращались к нему в работе и предпочитали использовать другие разделы.
Это отражалось в метриках, и у команды появился вопрос: возможно ли повысить ценность раздела. Передо мной стояла задача разобраться, почему раздел не используется, и понять, можно ли сделать его полезным инструментом в работе пользователей.
проблемы
Посещаемость раздела была значительно ниже других разделов системы.
Коллеги из других команд жаловались, что разделом неудобно пользоваться.
что я сделала
// процесс и решения
01 Поиск причин
Первоначальная задача — понять, почему пользователи не используют раздел.
Вместе с бизнес-аналитиком мы собрали доступные данные:
- обратную связь от пользователей, которую БА получала в рамках работы с продуктом;
- результаты ежегодного опроса удовлетворённости CRM;
- анализ текущего интерфейса и сценариев работы с входящими.
На основе полученных данных я сформировала гипотезы о проблемах и направлениях улучшений.
02 что я выяснила
Разные типы событий выглядели одинаково, хотя требовали совершенно разной работы. А главное — раздел только показывал событие, но не вёл к его выполнению. Получался тупик: чтобы что-то сделать, пользователь всё равно уходил в другой раздел.
А конкретно это проявлялось в четырех местах:
Непонятно, какие события требуют действия, а какие — просто к сведению
Из входящих некуда перейти к работе над объектом
Статус прочитанности не отражал, что пользователь реально видел
Список перегружен данными, которые в работе не используются
После подробного анализа раздела стало понятно, как можно бороться с каждой из проблем.
03 поиск новой структуры
После анализа стало понятно, что разделу нужна не группировка «новые / старые» по дропдауну, а структура, которая учитывает разные сценарии работы. Я рассмотрела два варианта.
Задачи и уведомления (требует / не требует действия)
Сначала вариант казался логичным, но внутри «задач» снова смешивались согласования и активности — а у них разная обязательность. Согласование нужно обработать: оно ждёт решения и само не закроется. Активность можно взять в работу, а можно осознанно пропустить — она информирует, но не блокирует.
Складывать их в одну корзину «требует действия» некорректно: половина того, что туда попадает, действия не требует.
Согласования, активности, уведомления (по типу события)
Он лучше ложился на структуру CRM и позволял задать свой сценарий для каждого типа. Четвёртой оставила вкладку «Все» — не свалкой, а единым потоком, где типы остаются различимы за счёт иконок-бейджей. Так пользователь, которому лень переключать табы, всё равно получает считываемый список.
04 переход к работе внутри сущности
// проблема
У входящих нет отдельных карточек — только строки. Так было в системе задолго до меня, и это оправданное ограничение: раздел не должен превращаться в полноценную почту внутри CRM, для переписки у команды есть корпоративная почта.
Задача «Входящих» в другом — не хранить сообщения, а ускорить обработку входящих событий. Старая версия с этим не справлялась: строка давала номер сделки, имя клиента — и всё, дальше пользователь вручную копировал данные и уходил искать объект в другом разделе, а то и вовсе сразу игнорировал раздел.
// решение
Я обсудила с разработчиками и добавила переход прямо в связанную сущность там, где она есть: согласование ведёт в карточку сделки или согласования, напоминание — в карточку активности, а уведомления остаются для информации. Так тупиковый раздел стал точкой перехода.
05 логика прочитанности
// проблема
Раньше все входящие становились прочитанными сразу после открытия раздела. Но реальный сценарий другой: пользователь открывал входящие, копировал номер сделки, уходил согласовывать и возвращался позже — и уже не мог понять, какие события он не видел.
// решение
Я разделила два состояния — «увидел» и «выполнил действие». Для уведомлений (у которых нет сущности, и весь их жизненный цикл — увидел/не увидел) добавила отметку «прочитано» контекстным действием и кнопку «отметить всё», а для согласований статус прочитанности вводить не стала: прочтение не равно решению, и такая отметка создавала бы ложное ощущение, что задача закрыта. Пропустить согласование = сделка в застое. Логика работает на всех вкладках, включая "Все".
06 улучшение сканируемости списка
// проблема
В строках было много данных, которые не влияли на работу. Инициатор нужен редко и виден прямо в сделке или активности; названия активностей на обработку входящих тоже не влияют — менеджеры приоритизируют список разве что по клиенту. Этот избыток не помогал быстро разобрать входящие, а только мешал.
// решение
Бизнес-аналитик переработала содержание сообщений с учётом ограничений системы — убрала второстепенное, сократила формулировки, привела к единому формату.
А со стороны интерфейса я перестроила отображение строки:
- добавила иконки-бейджи по типам, чтобы тип считывался ещё до чтения текста
- визуально сильнее разделила прочитанные и непрочитанные сообщения
- переработала отображение времени
- вынесла клиента отдельной строкой — каждое входящее с ним связано, и именно по клиенту строят приоритет
07 изменение фильтрации
// проблема
Фильтры тоже не отвечали реальным задачам: по инициатору не фильтровал никто, а поиск по дате не давал посмотреть входящие за период — хотя для отчётов менеджеры регулярно анализируют конкретный отрезок времени.
// решение
Убрала неиспользуемые параметры, добавила востребованные — клиент, период, статус прочитанности — и вынесла их в боковую панель для консистентности с остальными разделами системы.
результаты
После редизайна раздел перестал быть кандидатом на удаление и встроился в ежедневную работу — пользователи начали обращаться к нему напрямую, а не в обход.
Уже через месяц после релиза раздел показал результат: число ежедневных обращений выросло примерно втрое — пользователи начали заходить во «Входящие» каждый день и работать с ними напрямую. Это подтверждала и положительная обратная связь от пользователей.
x3
