Atlas — внутренний сервис
Back office
UX research
Web
До создания бекофиса все команды работали в 5-7 разных системах, вручную перенося данные между ними. Это тормозило работу, множило ошибки и мешало мешало масштабированию.
Бизнес поставил задачу создать внутренний продукт для 30+ человек, который объединит управление контентом, работу с клиентами и поставщиками, логистику и операционные процессы
Взаимодействие с командой
Работал в плотной связке с CТО и лидами для согласования решений. С разработкой был выстроен привычный процесс: передача документации → сопровождение на проде → финальное тестирование
Зачем нам внутренний продукт
Провёл 14 интервью (по 45–60 минут) с ключевыми ролями: клиентские менеджеры, закупка, логистика, QC, и контент. Цель — понять, как люди работают сейчас и перенести это в интерфейсные сценарии.
Также были обнаружены проблемы:
—
Коммуникация с клиентами разрознена по многочисленным источникам
—
Не хватает аналитики о поведении и действиях клиентов
—
Процессы между отделами не связаны
—
Файлы хранятся бессистемно и теряются
—
История отсутствует, что затрудняет принятие решений
Исследования реальных процессов
Важно было дать менеджерам единое пространство управления заказами. Помимо имеющихся инструментов мы внедрили новые: таймлайн событий, аналитику по клиенту, карта предпочтений, ИИ-подборку рекомендаций.
Придумал уникальную метрику и написал формулу её расчёта
Средний Показатель учитывает активность клиента (просмотры, избранное, корзина), их веса и экспоненциальное затухание. Он стал частью процесса — теперь менеджеры могут быстро отличить «тёплого» клиента от невовлечённого и отследить динамикузаказ состоит из 35–40 товаров, что усложняет навигацию по товарам
Продуктивность команды заметно выросла, количество рутины и ошибок свелись к минимуму
Страница заказа
Огромную часть продаж занимала подборка товаров. Совместно с СТО мы внедрили функционал на основе ИИ, который автоматически подбирает товары на основе спецификации или пожеланий клиентов. Менеджеру остаётся выбрать подходящее и отправить клиенту.
Данный функционал сократил время подборки товаров на 86%, что позволило команде продаж брать в работу больше потенциальных клиентов.
AI-подборка товаров
По основному сценарию просроченные задачи должны переносится на сегодня/завтра с учётом загруженности сотрудников. Для этого я спроектировал кастомный таймлайн: задачи перетаскиваются из левой колонки в центральные, которые разделены на часовые промежутки. Это повысило читаемость и позволило видеть свободные слоты.
Гибкость работы с задачами получилась за счёт разделения функционала:
—
В дашборде заказа менеджер создаёт и видит задачу по конкретному клиенту
—
В списке задач он планирует свой рабочий день, внося точечные корректировки по времени
Таск-менеджер
Для списка заказов используется привычный пайплайн с цветовой индикацией этапов продаж. На основе инсайтов из интервью карточка была доработана:
—
Отображаются срочные и ближайшие задачи
—
Заказы «на паузе» визуально отличаются и находятся в конце списка
—
Показаны ключевые параметры заказа, чтобы руководство быстрее ориентировалось в массиве карточек
Список фильтров формировался на основе опроса команды продаж. После запуска MVP сотрудники отдельно отметили, что фильтры позволяют настроить список под их персональные предпочтения
Воронка продаж
Со временем в компании появился запрос на единый ИИ-чат, включающий в себя 12 часто используемых моделей. Сразу была очевидна проблема: большой список затрудняет выбор. Вместе с разработчиками мы нашли несколько решений:
—
Встроили автоподбор модели, который анализирует промпт и перенеправляет его наиболее подходящей модели
—
Разделили список на быстрые и «думающие» модели
—
Подсветили ключевые особенности с помощью иконок и тултипов
Модуль реализован как попап — его можно двигать и ресайзить, не мешая работе со страницей
Единый AI-чат
Большой проблемой была разрозненная коммуникация среди множества мессенджеров, а также общения внутри нашего маркета. Стояла задача объединить и структурировать все чаты на одном экране.
После нескольких итераций появилась финальная концепция:
—
Список разделён на внешние мессенджеры и встроенное общение в маркете
—
Чаты по товарам сгруппировали по комнатам, в которые они добавлены
—
Закреплён основной чат
—
Добавлена фильтрация, в том числе скрытие пустых чатов и без новых сообщений
После релиза мы получили важный фидбек
Просмотр внутренних чатов не давал общей картины. Мною был предложен сводный чат, в котором показаны все сообщения с пометкой исходного чата
Консолидация чатов
Старшим менеджерам нужно было ревьюить большое количество «слитых» заказов. Цель — уменьшить переходы в карточку заказа.
Я выяснил, на чём они основывают решения, и собрал таблицу с фильтрами по ключевым данным. Пользователи отметили, что 8/10 решений принимаются по таблице и только спорные кейсы требуют детального анализа
Таблица для ревью
Мы сознательно отказались от внедрения количественных метрик по ряду причин:
—
Высокий загруженность разработки. Приоритет был на скорость реализации, а не на настройку аналитики
—
Погрешности метрик в продуктах с небольшой аудиторией (до 40 человек)
—
Основой проектирования были реальные процессы
Мы опирались на качественную оценку: постоянный сбор и анализ фидбека сотрудников
Рабочие процессы важнее «хотелок»
Мы проектировали интерфейс, исходя из анализа реальных сценариев, а не личных предпочтений. Такой подход гарантирует, что продукт будет востребован и полезен в долгосрочной перспективе
Как мы замеряли успех
