CRM для онлайн-заказов
Проблема
Бизнес:
Рестораны получают заказы из разных цифровых каналов, но создание собственной CRM для их объединения требует значительных инвестиций. Использование нескольких несвязанных сервисов усложняет обработку заказов, увеличивает операционные издержки и мешает масштабированию
Пользователь:
Сотрудники ресторана вынуждены работать сразу в нескольких интерфейсах, вручную обрабатывать обращения и отвечать на повторяющиеся вопросы. Это замедляет обслуживание, повышает количество ошибок и ухудшает клиентский опыт
Задача
Создать универсальный продукт для централизованной обработки онлайн-заказов ресторанов
Решение
Спроектировала универсальную CRM, которая объединяет все каналы заказов, позволяет централизованно управлять меню и базой данных ресторанов, а также адаптировать AI-ассистента под особенности каждого бизнеса
Результат
- Концепт и UI-дизайн
- 10 оригинальных экранов и состояния
- Desktop 1920/1280 + Лендинг 1280/360
- UI-kit
Метрики после релиза
Продукт находится в разработке, поэтому фактических данных после релиза пока нет. После запуска я бы отслеживала следующие продуктовые и UX-метрики
Эффективность обработки заказов
| Метрика | Что показывает | Критерий успеха |
|---|---|---|
| Скорость принятия заказаTTA | Медианное время от поступления онлайн-заказа до первого действия оператора | TTA сокращается, а доля заказов, не принятых в установленный срок, снижается |
| Время обработки заказаAHT | Медианное время активной работы оператора с заказом: проверка данных, коммуникация с гостем и изменение статуса | AHT сокращается без роста ошибок, отмен и повторных обращений |
| Ошибки при обработке заказовOER | Доля заказов с неверным статусом, составом, рестораном, временем или контактными данными | OER и количество повторных ручных действий устойчиво снижаются |
| Автоматизация обращений AI-ассистентомACR | Доля диалогов, корректно завершённых AI-ассистентом без подключения оператора | ACR растёт, при этом не увеличиваются повторные обращения, исправления оператором и негативные оценки |
| Актуальность менюMAR | Доля позиций с корректными ценами, составом и доступностью для каждой точки | MAR приближается к 100%, а число заказов с недоступными позициями и ручных исправлений снижается |
| Централизация обработкиCCR | Доля заказов и обращений, полностью обработанных внутри CRM без сторонних сервисов и ручного дублирования | CCR устойчиво растёт, а количество операций в таблицах, чатах и других сервисах сокращается |
Использование CRM сотрудниками
| Метрика | Что показывает | Критерий успеха |
|---|---|---|
| Успешность ключевых сценариевTSR | Доля задач, выполненных оператором без ошибок и посторонней помощи: найти заказ, изменить статус, ответить гостю или уточнить данные | TSR растёт, а доля прерванных сценариев и обращений за помощью снижается |
| Эффективность поиска и фильтровFUR | Использование фильтров по статусу, типу заявки, каналу, ресторану и периоду, а также результативность поиска | Операторы быстрее находят нужные заказы, используют меньше лишних действий, а доля поисков без результата снижается |
| Использование дашбордаDashboard Usage | Доля операторов и управляющих, которые используют дашборд для контроля показателей и перехода к заказам, требующим внимания | Пользователи регулярно переходят из дашборда к целевым действиям, а не ограничиваются просмотром показателей |
| Освоение CRMTTC | Время, необходимое новому сотруднику для самостоятельного выполнения основных рабочих сценариев | TTC, количество ошибок в первых заказах и число обращений к наставнику сокращаются |
Процесс
-
Исходные материалы
На старте проекта заказчик пришёл с уже сформированной идеей продукта, результатами собственного исследования, описанием ключевых требований и low-fidelity-прототипом. В нём были определены основные разделы CRM, однако не хватало целостной UI-системы, проработки состояний интерфейса и пользовательских сценариев
-
Ключевой экран
Работу начали с совместной проработки страницы заказа — ключевого экрана системы. На нём сформировали визуальную концепцию продукта, определили основные UI-паттерны и принципы оформления. После утверждения направления остальные экраны проектировались на основе выбранной дизайн-концепции
-
UI Kit
Параллельно с проектированием интерфейсов собирался UI Kit. Сначала была сформирована цветовая система и семантика цветов, затем на её основе последовательно создавались компоненты по атомарному подходу
-
Итерации
Из-за минимального объёма исходного ТЗ проект развивался итерационно. После каждого этапа заказчик просматривал готовые решения, уточнял требования и вносил корректировки
-
Интерфейсы CRM
Были спроектированы 10 основных экранов CRM со всеми необходимыми и пустыми состояниями, а также адаптации для ширины 1920 и 1280 px. Дополнительно разработаны модальные окна, выпадающие списки и элементы управления для фильтрации, выбора, редактирования и удаления данных
-
Лендинг и разработка
Финальным этапом стал дизайн промо-лендинга CRM в десктопной и мобильной версиях. После завершения дизайна проект передали в разработку. Сейчас он находится на этапе реализации с последующей поддержкой и уточнениями по запросам команды разработки
Макеты основных экранов
На этапе проектирования у заказчика не было чёткого понимания, каким должен быть главный экран системы. Поэтому здесь мой вклад как UX-дизайнера был наиболее значимым.
Изучив процессы работы ресторанов и похожие решения, я определила ключевые метрики для ежедневного контроля: выручку, количество заказов, средний чек, эффективность AI-ассистента, загрузку по часам, распределение заявок по каналам и базовую аналитику по клиентам
Поскольку продукт продолжает развиваться, именно дашборд, вероятнее всего, будет сильнее всего меняться по мере появления новых сценариев использования и обратной связи от пользователей
Экран заявок стал основой всего интерфейса — именно на нём формировались визуальный стиль и принципы взаимодействия с системой. Поэтому его проектированию было уделено больше всего времени.
Основной задачей стала разработка карточки заявки. Я проанализировала лучшие практики с помощью ChatGPT и Perplexity, однако предложенный подход не совпал с видением PM. После нескольких итераций карточка получилась информативной, но визуально лёгкой: ключевые данные, статус и тип заявки считываются за доли секунды, а структура экрана позволяет быстро обрабатывать большой поток обращений без потери контекста
Основной задачей этого экрана стало проектирование удобной работы с большой структурой меню. Интерфейс построен по принципу двойной группировки: сначала отображаются категории, затем блюда внутри выбранной категории, а справа — подробная информация и настройки выбранной позиции.
Отдельное внимание было уделено управлению блюдами для разных точек. Одно меню может использоваться сразу в нескольких филиалах, при этом настройки доступности отличаются. Чтобы переключение между точками было быстрым и наглядным, для них были предусмотрены отдельные вкладки в нижней части панели, без необходимости переходить в дополнительные разделы
Также были спроектированы сценарии создания и редактирования блюд, включая модальные окна для заполнения информации и управления настройками. Это позволило сохранить основной экран компактным, не перегружая его второстепенными действиями
Продукт позволяет настроить AI-ассистента под особенности каждого ресторана. Чтобы сделать этот процесс удобнее, все параметры разделены на четыре вкладки: персонаж, точки, база знаний и тестовый режим. В кейсе показана одна из них, так как остальные построены по тем же принципам
Основной интерфейс был спроектирован для экрана шириной 1920 px, но также адаптирован под 1280 px. На меньшем разрешении боковое меню открывается поверх интерфейса и частично перекрывает список заявок. Это осознанный компромисс: меню используется эпизодически, поэтому такой подход позволяет сохранить максимум пространства для основной рабочей области — диалога и информации по заказу