Поляна

B2B-маркетплейс для закупки агросырья

Product discoveryUX/UI Design

Платформа с публичной витриной, личными кабинетами и полным циклом сделки: от поиска поставщика до оплаты по расчётному счёту и доставки.

Контекст

Поляна задумывалась как B2B-маркетплейс для сельскохозяйственного сектора. По логике это был маркетплейс с привычными для e-commerce сценариями, но адаптированный под крупные закупки, работу по расчётному счёту и более строгий контроль сделок между продавцом и покупателем.

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

Роль предпринимателя

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

Моя роль в разработке продукта

Я отвечал за UX/UI ключевых частей платформы: публичной витрины, сценариев покупателя и продавца, а также личных кабинетов. Прорабатывал структуру экранов, пользовательские сценарии, логику сделки и интерфейсы для дальнейшей разработки.
Проект
B2B-маркетплейс для закупки агросырья
Метод
Product discovery + UX/UI дизайн
Год
2023-2024
Технология
Web platform | Marketplace
Главный экран и интерфейс маркетплейса Поляна

Пользователи и роли

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

Покупатель

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

Задачи в продукте:

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

Продавец

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

Задачи в продукте:

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

Оператор

Оператор помогает пользователям и следит за качеством контента на платформе.

Задачи в продукте:

  • модерировать товары и контент;
  • быстро принимать решения по карточкам товаров;
  • помогать продавцам и покупателям;
  • работать с обращениями и спорными ситуациями;
  • поддерживать качество каталога.

Проблема

Проблемы

Обычный e-commerce-сценарий не закрывал реальные потребности этого рынка. Здесь покупка — это не «добавил в корзину и оплатил картой», а процесс с юридическими лицами, крупными объёмами, расчётным счётом, контролем сроков и прозрачностью каждой стадии сделки.

Задача

Задача была в том, чтобы сохранить понятную маркетплейсную механику, но адаптировать её под B2B: упростить поиск товара и поставщика, дать покупателю уверенность в сделке, а продавцу — инструменты для сопровождения заказов и управления ассортиментом.

Сравнение обычного маркетплейса и B2B-закупки агросырья с выводом о необходимости отдельного сценария сделки

Цели продукта

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

Циклическая схема целей продукта: поиск товара, доверие к поставщику, сценарий сделки, контроль статусов и привлечение аудитории

Proxy-метрики

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

Proxy-метрики продукта: CTR каталога, споры и возвраты, SEO-регистрации и completion rate
Интерфейс сценария предпринимателя на платформе Поляна

Путь пользователя

Обзор

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

Решения

Публичная витрина и первое касание

Обзор

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

Каталог, поиск и выбор поставщика

Обзор

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

Сделка как основной B2B-сценарий

Обзор

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

Личный кабинет продавца

Обзор

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

Ограничения и особенности

Интерфейс ограничений и особенностей B2B-сделки

Обзор

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

Ограничение 1 - трекинг доставки

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

Ограничение 2 - возвраты и качество

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

Итог

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

Следующий проект

Иллюстрированная карта развития предпринимателя

Геймифицированная система развития предпринимателя — от базовых знаний до зрелых бизнес-компетенций