Автоматизация корпоративных заказов продуктов

Содержание

О клиенте

К нам обратилась крупная российская сеть супермаркетов. Отличительная черта бренда — акцент на свежести, сервисе и тщательно подобранном ассортименте, включая фермерскую продукцию, гастрономические деликатесы и эксклюзивные товары. Сеть активно развивается, охватывая не только офлайн-точки, но и цифровую среду: от интернет-магазина до мобильных приложений и программ лояльности.

О проекте

Помимо офлайн-сети и интернет-магазина у компании работает направление корпоративных продаж — сервис, ориентированный на обслуживание B2B-клиентов. Заказы в нём делятся на три типа:

эпизодические (несколько раз в год);
регулярные (1–2 раза в месяц);
VIP-заказы (от 2 раз в месяц на суммы от 500 тыс. рублей).

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

Компания решила автоматизировать процесс и разработать сервис, через который корпоративные клиенты смогут:

быстро оформлять заказы без участия менеджера;
видеть индивидуальные условия (скидки, договоры);
управлять бюджетами, лимитами и учётными записями сотрудников;
просматривать историю заказов и выгружать документацию.

Проект создавался в формате MVP с ориентиром на последующее масштабирование и интеграцию в экосистему.

Задача

Перед нашей командой стояла комплексная задача:

исследовать действующие процессы корпоративных продаж;
выявить требования бизнеса и ограничения ERP-системы;
продумать архитектуру нового сервиса;
спроектировать ключевые пользовательские сценарии и интерфейсы личного кабинета;
обеспечить полноту и читаемость документации для команды разработки.

Из ограничений стоит отметить: кастомную ERP-систему, параллельную работу трёх команд (аналитика на нашей стороне, дизайн-команда клиента, разработка — сторонний подрядчик) и частое изменение требований.

Погружение в бизнес и кастдев

Для понимания бизнес-процессов и требований клиента мы провели серию из четырёх интервью. Каждое было посвящено отдельной теме: бизнес-процессы, ERP (система для автоматизации бизнес-процессов компании), техническое задание. Отдельно поговорили с системным аналитиком — обсудили интерфейсы и техническую часть проекта.

Собранная информация помогла понять логику заказов, этапы согласования, внутренние ограничения и боли. Например:

проблемы ручного ввода информации;
сложности в сегментации клиентов (от студий до гигантов типа Сбера);
необходимость разных сценариев оплаты: предоплата, постоплата, аванс;
особенности юридического оформления заказов (договоры, допсоглашения, шаблоны), включая необходимость специальных договоров для алкогольной продукции;
важность роли персональных менеджеров.

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

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

Конкурентный анализ

В рамках анализа изучили российские сервисы доставки продуктов и обедов для B2B-аудитории: Яндекс.Еда для бизнеса, Утконос для бизнеса, OZON, Ашан, Обеды Смайл и др.

Анализ строился на сравнении пользовательских сценариев, входа в систему, каталога, корзины, оформления заказа, оплаты, поддержки и документооборота. Также были рассмотрены особенности авторизации, работа с корпоративными счетами, возможности настройки шаблонов и повторных заказов, подписки на товары, интеграции с ЭДО и управление сотрудниками.

По итогу анализа были выделены лучшие решения, а также обнаружены слабые места в текущем UX-ландшафте рынка. Это позволило зафиксировать конкурентные преимущества проекта и заложить обоснованные требования к функциональности и пользовательским сценариям нового сервиса.

Анализ ERP-системы и технических ограничений

Серьёзным вызовом стало взаимодействие с внутренней ERP-системой клиента (на базе Navision). Система была глубоко кастомизирована, с уникальной логикой синхронизации заказов, статусов, логистических слотов и документов.

Например:

изменение времени доставки требовало подтверждения и цепочки действий от менеджеров;
автоматизация расчётов и статусов заказов ограничивалась логикой ERP;
доступность продуктов зависела от складских остатков и логистических окон;
обновление данных в реальном времени усложнялось интеграцией с разными сервисами компании;
модификация ERP требовала сложных процедур и угрожала стабильности системы.

Наши аналитики изучили архитектуру ERP-системы, чтобы понять, как данные о заказах, товарах и договорах могут быть интегрированы в новый сервис. Выявленные ограничения определили подход к проектированию: предстояло создать сервис, который адаптировался к существующей инфраструктуре, минимизируя изменения в ERP.

Информационная архитектура

На основе интервью начали проработку архитектуры сервиса. Помимо карты личного кабинета на этом же этапе продумали и зафиксировали в требованиях:

Процесс регистрации и онбординга B2B-клиентов.
Механику создания и управления договорами и их статусами (на рассмотрении, заключён, просрочен).
Наличие контактных данных персональных менеджеров по каждому договору.
Вариативность ролей: администраторы и сотрудники. Администратор управляет сотрудниками внутри компании, ограничивает ассортимент, устанавливает лимиты на заказы и контролирует загрузку подразделений.
Особенности обработки заказов по различным схемам (кейтеринг, подарки, алкоголь, регулярное питание).
Лимиты по подразделениям, историю заказов и аналитику по SKU.
Подсказки и уведомления по шагам взаимодействия.

Пользовательские сценарии (use case)

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

роли и доступы,
возможные состояния и ошибки,
логику отображения и редактирования.

В дополнение к use case создали разбивку по сущностям с привязкой к макетам.

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

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

Проектирование и функционал сервиса

Проектировали основные интерфейсы MVP:

регистрация и вход;
личный кабинет с разделением юридических и персональных данных;
управление договорами (таблица статусов, шаблоны, уведомления);
история заказов (с фильтрацией, выгрузкой документов, повтором заказов);
лимиты по отделам и сотрудникам;
механика создания подарочных корзин и специальных заказов.

Часть прототипов была визуализирована, часть — описана текстово с включением скриншотов, состояний элементов и логики отображения. Дополнительно мы разрабатывали мини-кейсы, объясняющие типовые действия пользователя, что значительно облегчило работу разработчиков.

Регистрация и авторизация

Корпоративные клиенты могли зарегистрироваться только по приглашению (по ссылке из письма), что обеспечивало контроль доступа и соответствие договорным обязательствам.

Работа с договорами

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

Оформление заказов

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

Каталог и карточки товаров

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

История покупок

Раздел позволял клиентам отслеживать заказы, проверять их статус и наличие товаров. Если товар отсутствовал на складе, система уведомляла об этом на этапе модерации.

Подарочный сервис

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

Интеграция с ERP

Данные о заказах и товарах синхронизировались с ERP, что обеспечивало актуальность информации.

Админ-панель

Позволяла менеджерам утверждать списки доступных продуктов, задавать лимиты для сотрудников и отслеживать расходы по отделам.

Синхронизация с дизайн-командой

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

Особенно активно взаимодействие шло при:

адаптации стиля под основной интернет-магазин;
интеграции в каталог товаров;
разработке элементов личного кабинета.

Работа шла итерационно: команде дизайна отправлялись технические комментарии, рекомендации, списки доработок — с учётом найденных функциональных дыр и потребностей реальных пользователей.

Формат работы включал:

регулярные синхронизации с командами дизайна и разработки;
участие в планёрках и демонстрациях макетов;
составление детальных комментариев к каждому макету;
контроль за актуализацией всех изменений.

В Фигме использовали определённые правила нумерации, чтобы всем участникам было проще ориентироваться в макетах и их изменениях.

Этот подход позволил наладить коммуникацию между всеми сторонами: дизайнеры, аналитики, заказчики и команда разработки действовали в рамках единой продуктовой логики.

Передача материалов в разработку

Особое внимание уделили формату передачи требований в разработку. Список материалов включал:

полное описание пользовательских сценариев (use case);
карту бизнес-процессов;
визуальные схемы взаимодействия с системой;
требования к каждому элементу интерфейса.

Юз-кейсы подробно описывали:

функционал каждого элемента интерфейса (например, кнопок, полей ввода);
логику взаимодействия (например, как отображается статус заказа, как пользователь редактирует время доставки);
источники данных для каждого элемента (например, откуда берётся информация о наличии товаров).

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

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

Запуск MVP

MVP-версия сервиса была запущена для тестирования на реальных пользователях.

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

На момент запуска сервис уже покрывал основные бизнес-потребности: автоматизацию оформления заказов и управление договорами.

Результат

Автоматизация процессов: личный кабинет позволил корпоративным клиентам самостоятельно оформлять заказы, что сократило нагрузку на менеджеров и ускорило обработку. Первый заказ сопровождался менеджером, что упростило адаптацию клиентов к сервису.
Улучшение пользовательского опыта: интуитивный интерфейс и упрощённая регистрация снизили барьеры для новых пользователей. Функционал управления лимитами позволил менеджерам контролировать расходы отделов.
Гибкость управления договорами: клиенты могли отслеживать статусы договоров (черновик, подписан, расширен) и использовать шаблоны для ускорения согласования.
Стабильная интеграция с ERP: сервис был адаптирован под ограничения кастомной ERP-системы, что обеспечило корректное обновление данных о заказах и товарах.
Подготовка к масштабированию: Заложена архитектура для будущих функций, таких как подарочный сервис и расширенные аналитические отчёты.