Админка маркетплейса: заказы, склады, роли

Админка маркетплейса начинается не с таблиц и кнопок, а с вопросов: кто продаёт, кто принимает заказы, кто отвечает за доставку и кто платит продавцам. Если эти процессы не описаны, интерфейс получится красивым, но бесполезным.

Ниже — ключевые сущности и сценарии, которые стоит предусмотреть до разработки.

Чем админка маркетплейса сложнее магазина

• Несколько продавцов с разными правилами и комиссиями.
• Заказы могут состоять из товаров разных продавцов.
• Нужны выплаты, удержания и отчёты.
• Склады и остатки распределены между участниками.
• Модерация товаров и продавцов.
• Споры, возвраты и ответственность сторон.

Ключевые сущности

Заказы и статусы

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

• Статус заказа и статус позиции.
• Оплата, сборка, отправка и доставка.
• Отмена и возврат по позиции.
• Споры и претензии.
• История изменений и ответственные.

Склады и остатки

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

• Резерв при оформлении заказа.
• Списание после оплаты или сборки.
• Возврат на склад.
• Перемещение между складами.
• Массовая выгрузка и импорт.

Продавцы и выплаты

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

• Комиссия и правила расчёта.
• Начисления по заказам.
• Удержания и возвраты.
• Статусы выплат.
• Отчёты и документы.

Роли и доступ

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

• Роли сотрудников и продавцов.
• Ограничение по складам и заказам.
• Журнал действий.
• Двухфакторная аутентификация.
• Запрет на просмотр чужих выплат.

Отчёты и мониторинг

• Оборот, комиссия и выплаты.
• Заказы по статусам и продавцам.
• Зависшие заказы и споры.
• Остатки и резервы.
• Ошибки интеграций.
• Очередь и время обработки.

Как проектировать

Типичные ошибки

• Смешивать статусы заказа и позиции.
• Не резервировать остатки.
• Делать выплаты без истории.
• Давать продавцу лишние права.
• Начинать с выплат, не разобравшись в заказах.

Админка маркетплейса растёт вместе с бизнесом. Чем понятнее модель данных и правила, тем меньше ручной работы и споров между участниками.

Модерация товаров и продавцов

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

• Проверка продавца и документов.
• Правила публикации товаров.
• Автоматические проверки и стоп-слова.
• Очередь модерации и причины отказа.
• История решений и апелляции.

Правила должны быть опубликованы заранее. Продавец имеет право понимать, почему товар отклонён и что исправить.

Споры и возвраты

Споры — часть маркетплейса, а не исключение. Нужно понимать, кто отвечает за товар, доставку и возврат денег.

• Статусы спора и ответственные.
• Сроки ответа продавца.
• Возврат товара и денег.
• История переписки и доказательств.
• Правила блокировки продавца.

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

Интеграции

Маркетплейс обычно связан с 1С, складами, платежами, доставкой и бухгалтерией. Чем больше участников, тем важнее логи и повторные попытки.

• Обмен товарами и остатками.
• Заказы и статусы.
• Платежи и выплаты.
• Доставка и трек-номера.
• Очередь и мониторинг ошибок.

Масштабирование

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

• Индексы под заказы и выплаты.
• Очереди для тяжёлых операций.
• Разделение чтения и записи при росте.
• Кэш каталога и фильтров.
• Мониторинг очередей и ошибок.

Не пытайтесь сразу построить «второй Ozon». Начните с узкого контура, проверьте процессы и добавляйте сложность по мере роста.

Отчёты для продавцов

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

• Продажи и возвраты по периодам.
• Начисления и комиссии.
• Статусы выплат.
• Остатки и резервы.
• Выгрузка отчётов.

Безопасность и мониторинг

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

• Минимальные права и журналы.
• Двухфакторная аутентификация.
• Мониторинг очередей и выплат.
• Алерты на зависшие заказы.
• Резервные копии и проверка восстановления.

Что оставить на потом

• Сложную персонализацию.
• Многоуровневые акции.
• Автоматические споры.
• Продвинутую аналитику.

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

Как считать комиссию

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

• База расчёта: цена товара или итог заказа.
• Учёт доставки и скидок.
• Разные ставки по категориям.
• Округление и валюта.
• История изменений правил.

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

Возвраты и удержания

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

• Возврат до и после выплаты.
• Удержание комиссии и доставки.
• Возврат товара на склад.
• История операций для споров.

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

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

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

Начните с ручной сверки первых выплат. Это медленнее, но помогает поймать ошибки в правилах до того, как они станут системными.

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