План и факт FBS: какие SKU действительно стоит оставлять на этой схеме

План и факт FBS: какие SKU действительно стоит оставлять на этой схеме

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

Через месяц одних плановых цифр уже недостаточно. У бизнеса есть фактическая стоимость обработки, реальные возвраты и отмены, начисления площадки, движение товара и остатки. Теперь нужно понять, сколько конкретный SKU заработал на FBS и за счёт каких расходов результат отличается от плана.

Именно здесь возникает основная сложность. Сам расчёт юнит-экономики остаётся тем же. Но данные для него приходится регулярно обновлять.

После запуска прибыль SKU начинает расходиться с планом

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

Через месяц фактическая прибыль составила 200 ₽.

Это ещё не означает, что SKU нужно снимать с FBS. Если 200 ₽ укладываются в целевую прибыль компании, товар можно оставить на этой схеме. Но сначала нужно понять, откуда взялась разница в 45 ₽.

Фактическая обработка могла оказаться дороже, чем предполагалось. Могли добавиться дополнительные операции. Возвратов вышло больше, товар дольше лежал на складе, изменились начисления маркетплейса или скорость продаж.

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

Даже пять FBS-заказов в день приходится регулярно сверять с учётом

Сам расчёт юнит-экономики сложности обычно не создаёт. Основное время уходит на подготовку фактических данных.

В практике SoykaSoft был продавец Wildberries, который работал по FBS примерно с пятью заказами в день — около 150 заказов в месяц.

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

Появляются новые заказы — данные снова нужно обновлять.

При 150 заказах в месяц эту работу ещё можно вести вручную. Но уже и на таком объёме появляется постоянная учётная операция, которую кто-то должен выполнять.

С ростом количества заказов, SKU, кабинетов и площадок, растет объем данных, которые нужно собрать и сверить перед расчетом.

Средняя маржа магазина не показывает, что происходит с отдельными SKU

Средняя маржинальность кабинета может выглядеть нормально, хотя по отдельным SKU FBS уже даёт разный результат.

Для товара с высокой прибылью дополнительные 20–30 ₽ обработки почти незаметны. Для SKU с небольшим запасом маржи те же расходы уже подводят его к минимально допустимой прибыли. У товара с высокими возвратами или слабой оборачиваемостью FBS может оказаться хуже другой схемы.

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

У каждого SKU есть свой предел расходов на FBS

После того как FBS считают на уровне SKU, появляется более полезный ориентир — предельная стоимость обработки.

Допустим, после всех расходов кроме обработки у товара остаётся 350 ₽. Компания хочет сохранять минимум 240 ₽ прибыли.

350 ₽ − 240 ₽ = 110 ₽.

Значит, 110 ₽ — максимум, который этот SKU может отдать за FBS-обработку.

При обработке за 90 ₽ запас есть. При 108 ₽ товар почти упирается в предел. При 133 ₽ превышение составляет уже 23 ₽ — и нужно разбираться, что его дало: тариф, дополнительные операции, упаковка или другие расходы.

План — 245 ₽. Факт — 200 ₽. Важна причина разницы

Допустим, перед запуском SKU должен был приносить 245 ₽, а по факту осталось 200 ₽.

Отклонение от планаВлияние на прибыльОбработка дороже плана−23 ₽Возвраты выше заложенного уровня−8 ₽Расходы маркетплейса выше плана−12 ₽Хранение−2 ₽Всего−45 ₽

Эти 45 ₽ сами по себе ещё не подсказывают решение. −23 ₽ на обработке — повод проверить тариф и состав операций. −8 ₽ на возвратах — искать причину возвратов. −2 ₽ на хранении — смотреть запас и оборачиваемость.

Если после этого SKU всё ещё сохраняет целевую прибыль, его можно оставить на FBS. Если нет — пересматривать цену, запас, тариф или схему отгрузки.

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

В SoykaSoft фактическая экономика FBS обновляется автоматически

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

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

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

Если вы уже работаете по FBS или только переводите на него часть ассортимента, имеет смысл проверить не только плановую, но и фактическую экономику SKU. Приглашаем на демонстрацию SoykaSoft — покажем, как система собирает данные по FBS и помогает увидеть, какие позиции сохраняют прибыль после перехода.

Актуальные данные нужны, чтобы вовремя менять решение по SKU

Посчитать FBS заранее несложно. Сложнее после запуска постоянно видеть его фактическую экономику: с текущими заказами, возвратами, остатками, движением товара и расходами.

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

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

И уже на этом факте можно решать, какие товары оставлять на FBS, а по каким менять цену, запас, тариф или схему отгрузки.