Многие представляют работу продавца как простую последовательность: выбрать товар, разместить его на площадке, получить заказ, отправить его и получить деньги.
Но тот, кто действительно занимается e-commerce, знает: с появлением заказа работа далеко не заканчивается. От решения продавать конкретный SKU до доставки товара покупателю и окончательного расчёта его фактической доходности проходит целая цепочка: закупка, выполнение заказа, учёт остатков, выплаты и аналитика.
Чем больше заказов, SKU и магазинов, тем больше моментов в этой цепочке приходится контролировать.
Поэтому, возможно, правильнее спросить не «сколько задач продавец выполняет за день?», а вот что: какие из этих процессов система должна постоянно фиксировать и синхронизировать сама, а где действительно требуется решение самого продавца?
До продажи: стоит ли ещё вкладываться в этот SKU?
Представим, что вы продаёте один и тот же товар на Ozon и Wildberries и сегодня собираетесь сделать новую закупку.Первый вопрос обычно не «сколько заказать?», а «стоит ли вообще продолжать вкладываться в этот SKU?».
То, что товар хорошо продавался раньше, ещё не означает, что сейчас его стоит снова закупать. Чтобы принять такое решение, продавцу приходится одновременно смотреть на несколько показателей: последние продажи, текущие остатки, скорость оборачиваемости, фактическую доходность SKU, себестоимость и расходы площадки.
Например, SKU продаётся за 1 200 ₽. Закупочная цена — 500 ₽, комиссии площадки и логистика вместе составляют около 300 ₽. После этих расходов остаётся примерно 400 ₽ с единицы. На первый взгляд товар прибыльный.
Но представим, что сейчас на складе уже лежит 600 единиц, а в среднем за месяц продаётся только 80. Получается, текущего запаса хватит более чем на семь месяцев.
В такой ситуации дальнейшие вложения в рекламу могут привести не к росту продаж, а к увеличению залежавшихся остатков и расходов на хранение.
Поэтому решение о закупке или продвижении товара нельзя принимать только по объёму продаж. Нужно одновременно учитывать SKU, остатки и фактическую экономику товара.
Именно поэтому аналитика начинается ещё до того, как товар превращается в заказ.
Товар превращается в заказ: начинается выполнение
Появился заказ — казалось бы, самое время радоваться. Но для продавца это означает не конец работы, а начало процесса выполнения заказа.Особенно это заметно при работе по FBS. После поступления заказа нужно проверить: обработан ли он вовремя, правильно ли подобран товар, корректно ли напечатана этикетка, передан ли заказ в соответствии с требованиями площадки и не превышен ли установленный срок обработки.
Ошибка на любом из этих этапов может привести к отмене заказа, дополнительным расходам или другим последствиям для продавца.
А когда магазинов становится несколько, сама обработка заказов постепенно превращается в отдельную нагрузку. Продавец, который одновременно работает с Ozon и Wildberries и управляет несколькими магазинами, вынужден постоянно переключаться между разными кабинетами: открыть один магазин, проверить и обработать заказы, затем перейти в другой и снова всё проверить.
Иногда больше всего времени занимает не сама обработка заказа, а постоянное переключение между кабинетами, необходимое для того, чтобы убедиться, что ни один заказ не пропущен.
В HiSeller FBS-заказы можно обрабатывать непосредственно в системе — от подбора товара до печати этикеток всё собрано в одном интерфейсе. FBO-заказы выполняются на складе маркетплейса, но продавец также может видеть их в системе.
То есть после выполнения необходимых действий продавцу не нужно отдельно заходить в каждый кабинет, чтобы проверить ситуацию по разным магазинам.
Заказ обработан — теперь нужно разобраться с остатками
После обработки заказа возникает следующий вопрос: остаток уже списался?Товар продался на Ozon — изменился ли остаток в других магазинах? Сколько товара реально осталось на складе? Сколько уже зарезервировано под заказы? Почему цифра в системе не совпадает с фактическим остатком?
В этот момент продавцу важно видеть не только текущее количество товара, но и весь процесс изменения остатка:
Исходный остаток → создание заказа → резервирование → отмена заказа → освобождение остатка → завершение заказа → списание
Если на любом этапе возникает ошибка, итоговая цифра может оказаться некорректной.
А ошибка в остатках может повлечь за собой целую цепочку проблем: товара уже недостаточно, но его продолжают продавать, реклама продолжает работать, в итоге возникает пересорт или пересамораспределение остатков, возможен оверселл, а заказ уже невозможно нормально выполнить. При этом рекламный бюджет тоже может быть потрачен впустую.
Поэтому учёт остатков — это не только вопрос «сколько товара сейчас есть?».
Есть ещё второй вопрос: почему остаток стал именно таким?
При обработке заказов в HiSeller система автоматически учитывает изменения остатков и обновляет их. Для Ozon и Wildberries можно синхронизировать остатки между магазинами, снижая риск расхождений между площадками.
Если однажды вы обнаружили, что какого-то SKU стало на 5 единиц меньше, не обязательно выяснять причину вручную. В истории движения остатков можно посмотреть, когда товар был добавлен или списан, какой заказ повлиял на изменение и связано ли оно с продажей или возвратом.
Только понимая, почему изменился остаток, можно определить, действительно ли товар был продан или проблема возникла на этапе синхронизации данных.
Заказ завершён: сколько на самом деле заработал этот SKU?
Товар доставлен покупателю, заказ завершён, деньги поступили. И только теперь появляется последний вопрос: сколько на самом деле принёс этот товар?Оборот сам по себе не отвечает на этот вопрос.
Чтобы понять фактическую экономику SKU, нужно учитывать закупочную стоимость, комиссии маркетплейса, логистику и другие связанные расходы.
В HiSeller в разделе Аналитика можно смотреть результаты по разным измерениям, в том числе по SKU и магазинам, и понимать, сколько фактически остаётся от проданного товара после основных расходов.
И здесь вся цепочка замыкается.
Анализ товара до продажи помогает принять решение о закупке, остатках и продвижении. Анализ после продажи показывает, какой фактический результат принёс этот SKU и что стоит изменить в следующем цикле.
Получается замкнутый процесс:
Аналитика → закупка → продажа → выполнение заказа → изменение остатков → завершение заказа → новая аналитика.
Что действительно стоит передать системе?
Когда заказов всего несколько десятков, многие процессы ещё можно выполнять вручную: открыть кабинет, скачать таблицу, проверить заказы, посмотреть остатки, ещё раз сверить данные и вручную разобраться с проблемами.Это не значит, что такой подход совсем не работает.
Проблема начинается тогда, когда одновременно растут количество магазинов, SKU и заказов. Количество проверок никуда не исчезает — наоборот, оно становится всё больше.
В итоге значительная часть времени продавца уходит на одни и те же вопросы: Обновились ли данные? Не пропущен ли заказ? Списался ли остаток? Почему изменилась эта цифра? Вернулась ли выплата по этому заказу? Приносит ли этот SKU деньги?
Сами по себе эти проверки не создают продажи. Но если их не выполнять, ошибки могут напрямую стоить продавцу денег.
Поэтому мы скорее воспринимаем HiSeller как систему, которая берёт на себя не решения продавца, а те процессы, которые система может постоянно фиксировать, рассчитывать и синхронизировать.
А продавцу остаётся больше времени на то, что действительно требует его решения: что продавать, сколько закупать, в какие SKU стоит вкладываться и как развивать бизнес дальше.
Когда эти базовые процессы стабильно фиксируются и связываются между собой, работа продавца постепенно меняется: вместо постоянной проверки того, что уже произошло, он может больше времени уделять тому, что делать дальше на основе данных.
А что вы проверяете первым, когда каждый день открываете кабинеты маркетплейсов?
Остатки, заказы, FBS, выплаты или доходность конкретного SKU?
