У маркетплейса проблемы редко начинаются с каталога. Витрина обычно выглядит прилично, оплата проходит, первые заказы есть. Дальше менеджеры вручную меняют статусы, продавцы отправляют акты на почту, покупатели пишут «где заказ?», а бухгалтер ведет выплаты в файле на 600 строк. Формально запуск состоялся. По сути это еще не платформа, а набор ручных операций.
Если упростить, личные кабинеты - это место, где маркетплейс либо начинает масштабироваться, либо тихо нанимает себе лишний штат. Ошибка здесь дорогая: через 8-12 месяцев приходится переделывать уже не интерфейс, а ядро процессов.
Кабинеты - это операционная модель, а не раздел сайта
У маркетплейса почти всегда три слоя: витрина, транзакции и операционный контур. Покупатель видит первый. Бизнес живет во втором и третьем: в заказах, возвратах, документах, выплатах, ролях сотрудников.
На одном B2B-проекте витрина заняла 18 экранов, а кабинет покупателя, кабинет продавца и backoffice вместе - 43 экрана. В таких местах и скрывается реальная стоимость разработки.
Покупателя и продавца опасно проектировать как два отдельных мира. У них один и тот же заказ, просто разные права и действия.
created -> confirmed -> packed -> shipped -> delivered -> completed
\-> returned
\-> disputed
Если такой модели состояний нет в первый месяц, дальше начинаются исключения в коде и ручная магия в админке. Мы обычно сразу закладываем RBAC (ролевую модель доступа): покупатель, продавец, менеджер продавца, бухгалтер, оператор, администратор. На Laravel 11 или Node.js 20 + NestJS это лучше делать в начале, а не после первых конфликтов по доступам.
Покупателю нужен контроль над сделкой
Хороший кабинет покупателя - это не профиль с аватаркой. Человеку нужно понимать, где заказ, кто отвечает за следующий шаг, как вернуть товар, где чек и как повторить покупку.
У нас был проект в нише товаров для ремонта. Курьерская интеграция работала нормально, но люди все равно писали в поддержку. Причина оказалась простой: статус был, а следующего понятного действия не было. Мы переделали карточку заказа: добавили окно доставки, документы, историю событий и кнопку обращения. Через 6 недель тикеты «где мой заказ?» упали на 34%.
Для MVP кабинета покупателя я обычно оставляю только то, что снижает нагрузку на поддержку и помогает повторному заказу:
- история заказов и понятные статусы;
- возврат, спор или обращение;
- адреса, оплаты, повтор заказа;
- уведомления по email, SMS, push.
Ориентир простой: 70-80% типовых действий должны проходить без менеджера. Если без оператора нельзя узнать статус или скачать чек, это пока декоративный кабинет.
Кабинет продавца сильнее влияет на маржу
С продавцом логика жестче. Ему нужен не красивый dashboard, а рабочее место: товары, остатки, цены, проблемные заказы, возвраты, выплаты, документы. Если этого нет, платформу быстро заменяет команда в чатах и таблицах.
В B2B и полупрофессиональных сегментах это видно особенно быстро. Один аккаунт почти всегда делят несколько людей: владелец, контент-менеджер, логист, бухгалтер. Если роли внутри кабинета не предусмотрены, ошибки по ценам и документам начинаются очень рано.
На маркетплейсе промышленного оборудования подключение нового продавца занимало 9 дней. Карточки заводили вручную, документы сверяли по почте, бухгалтерия ждала конец месяца. После нормального кабинета продавца срок сократился до 3 дней, а ручных операций стало меньше примерно на 40%.
Если продавец не может сам загрузить товар, увидеть проблемный заказ и понять дату выплаты, у вас сервисная команда с витриной.
Где мы сами ускорились и потом переплатили
Несколько лет назад мы тоже решили, что сначала быстро запустим витрину, а кабинеты оставим на потом. Взяли коробочное решение для нишевого маркетплейса и сделали витрину за 14 недель. На старте это выглядело разумно.
Через несколько месяцев появились новые роли продавцов, верификация продавцов (KYC), акты, возвраты и автоматические выплаты. Выяснилось, что у платформы слишком грубые права и нет нормальной событийной модели заказа. Переделка стоила еще 1,8 млн ₽ поверх исходного бюджета. По факту мы заплатили почти вдвое.
Ошибка была не в том, что выбрали шаблон. Ошибка была в другом: шаблоном закрыли витрину, а операционную модель оставили на потом. С тех пор я к коробкам отношусь спокойно: они полезны, если заранее понятна цена ограничений.
Что фиксировать до разработки, чтобы MVP не поплыл
На discovery я обычно спрашиваю не «какие функции нужны», а «какие 5-7 сценариев должны проходить без ручного вмешательства». Это быстро убирает лишнее.
| Подход | Когда годится | Где упретесь |
|---|---|---|
| Шаблон | проверить спрос за 2-3 месяца | роли, статусы, выплаты |
| Кастомный MVP | есть процесс и первые продавцы | выше стартовый бюджет |
| Полный кастом | понятен план на 12 месяцев | легко переусложнить старт |
До начала разработки полезно зафиксировать короткий чеклист:
- 3 ключевые роли в системе;
- 10-15 сущностей данных;
- 2-3 интеграции первой очереди;
- единые правила статусов, возвратов и выплат;
- один реальный путь заказа - от создания до закрывающих документов.
В ближайшие 6-12 месяцев рынок будет сильнее давить на самообслуживание и прозрачность выплат, особенно в B2B. Если продавец и покупатель все еще зависят от менеджера в базовых действиях, вы строите не маркетплейс, а дорогой ручной бизнес под видом платформы.
