Переключение между кабинетами Ozon, Wildberries и Яндекс.Маркета съедает время и порождает ошибки: разные интерфейсы, разные сроки, разная логика сборки. RetailCRM собирает заказы всех площадок в одну воронку, где операторы работают по единым статусам, а рутину берут на себя триггеры.
Почему нужно единое окно
Продавец на трёх-четырёх площадках вынужден держать открытыми столько же кабинетов. У каждого свой интерфейс, свои названия статусов и свои дедлайны сборки. Оператор постоянно переключается, часть заказов теряется, а сроки срываются просто потому, что о заказе вовремя не вспомнили.
- Разные интерфейсы — на переучивание уходит время, растёт число ошибок.
- Разные SLA — легко пропустить окно сборки на одной из площадок.
- Нет общей картины — сколько заказов в работе суммарно, непонятно.
Общая воронка и группы статусов
В RetailCRM заказы всех маркетплейсов попадают в единый список заказов вместе с заказами сайта и телефонии. Чтобы не смешивать логику разных каналов, используются группы статусов и признак площадки/канала.
- Канал/площадка у каждого заказа показывает, откуда он пришёл — Ozon, WB, Маркет.
- Группы статусов отражают этапы: новый, на сборке, собран, отгружен, доставлен, отменён.
- Фильтры и сегменты позволяют собрать, например, все несобранные заказы FBS по всем площадкам к отгрузке сегодня.
Оператор видит один список, но понимает, к какой площадке относится каждый заказ, и работает по общей понятной ему логике вместо трёх разных кабинетов.
Маппинг статусов площадок
Каждая площадка живёт в своих статусах, и задача настройки — сопоставить их со статусами RetailCRM в обе стороны. Тогда смена статуса в CRM отражается в кабинете площадки и наоборот.
| Этап | Статус RetailCRM | Смысл для площадки |
|---|---|---|
| Приём | Новый | Заказ принят продавцом |
| Комплектация | На сборке | Товар собирается |
| Готовность | Собран | Этикетка/стикер напечатан |
| Отгрузка | Отгружен | Передан в доставку/поставку |
| Завершение | Доставлен | Заказ вручён |
Автоматизация сборки триггерами
Главная ценность единого окна раскрывается через триггеры RetailCRM — правила «если произошло событие, выполни действие». Они снимают рутину и страхуют от просрочек.
- Новый заказ → поставить задачу сборщику и уведомить менеджера.
- Приближается дедлайн сборки → оповестить оператора, подсветить заказ.
- Напечатана этикетка → автоматически перевести заказ в статус «собран».
- Отмена/возврат → создать задачу на разбор и учесть в аналитике потерь.
Триггеры работают одинаково для всех площадок, поэтому оператору не нужно помнить особенности каждого кабинета — система сама подсказывает следующий шаг и не даёт заказу «потеряться».
Печать документов и сборка
Для схем FBS и DBS сборка идёт прямо в карточке заказа RetailCRM. Оператор комплектует товар и печатает нужные документы, не заходя в кабинет площадки:
- Ozon — этикетка и лист отгрузки для FBS/realFBS.
- Wildberries — стикер WB, без которого товар не примут.
- Яндекс.Маркет — ярлык-наклейка для FBS.
Возможность собрать заказ и распечатать документы в одном месте — то, ради чего единое окно и внедряется. Сборщик работает по одному сценарию независимо от того, на какую площадку уходит товар.
Аналитика по площадкам
Раз все заказы в одной системе, RetailCRM считает сквозную аналитику по каналам. Видно, какая площадка приносит больше выручки и маржи, где выше доля возвратов и отмен, кто из операторов быстрее обрабатывает заказы.
- Выручка и число заказов по каждой площадке.
- Доля отмен и возвратов как индикатор проблем с остатками или логистикой.
- Скорость обработки — от приёма до отгрузки.
Эти данные помогают принимать решения: где расширять ассортимент, какую площадку подтягивать, где теряются деньги на штрафах.
Итог
Обработка заказов маркетплейсов в едином окне RetailCRM убирает переключение между кабинетами и превращает разрозненный поток в управляемую воронку. Заказы всех площадок идут по общим статусам, триггеры страхуют от просрочек, документы печатаются из карточки, а сквозная аналитика показывает картину по каналам. Опоры настройки — маппинг статусов в обе стороны, продуманные группы статусов и триггеры под сроки сборки.
Мы настраиваем единое окно обработки заказов под ваш набор площадок: выстраиваем статусную модель и маппинг, подключаем печать документов для FBS и DBS, автоматизируем сборку триггерами и собираем аналитику по каналам. В результате операторы работают в одном интерфейсе, а просрочки и штрафы уходят.
Частые вопросы
Что даёт обработка заказов в одном окне?
Заказы всех маркетплейсов собираются в единую воронку RetailCRM с общими статусами, что убирает переключение между кабинетами и снижает риск просрочек и штрафов.
Как отличить, с какой площадки заказ?
У каждого заказа есть признак канала или площадки — Ozon, Wildberries, Яндекс.Маркет. Списки можно фильтровать и сегментировать по площадкам и статусам.
Зачем нужен маппинг статусов?
Чтобы смена статуса в RetailCRM отражалась в кабинете площадки и наоборот. Без сопоставления заказ повиснет как необработанный на стороне маркетплейса.
Как автоматизировать сборку?
Через триггеры RetailCRM: постановка задачи сборщику при новом заказе, напоминание о дедлайне, автосмена статуса после печати этикетки. Правила работают для всех площадок.
Можно ли печатать документы площадок из CRM?
Да. Для FBS и DBS этикетки, стикеры WB и ярлыки Маркета печатаются из карточки заказа, что позволяет собирать заказы, не заходя в кабинеты площадок.
Считается ли аналитика по площадкам?
Да, RetailCRM ведёт сквозную аналитику: выручка, число заказов, доля возвратов и скорость обработки по каждому маркетплейсу.
Подходит ли единое окно для схемы FBO?
Да. Заказы FBO обрабатывает сама площадка, но в RetailCRM они учитываются для аналитики и списания остатков наравне с остальными.
Как обрабатывать много заказов к отгрузке?
Настройте фильтр по несобранным заказам с отгрузкой на сегодня по всем площадкам и обрабатывайте их пакетно, печатая документы списком.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.