Sell-through feedback от садового центра к теплице: какие числа просить еженедельно и как они меняют производство
Теплице мало знать, что садовый центр «продал хорошо». Нужен weekly packet по SKU и магазину: sold, on-hand, receipts, OOS, markdown и throw-outs. Только тогда sell-through превращается…
Оглавление статьи (16)
Sell-through feedback от садового центра нужен теплице не ради красивого еженедельного отчёта, а ради трёх решений: делать ли следующий repeat drop, какие позиции оставлять в ядре ассортимента и как пересчитать следующие волны производства. Если поставщик слышит только «продалось нормально», он не видит, что именно произошло на полке: быстрый уход, дефицит, промо-раскачка, поздняя уценка или списание.
Для живого товара это особенно дорого. Ошибка в интерпретации одной недели быстро превращается либо в пустую полку, либо в переизбыток, уценку и лишнее стояние товара. Поэтому теплице нужен не общий отчёт по выручке, а короткий weekly packet по магазину и SKU. Логику B2B-поставки и окна отгрузки полезно держать рядом со статьёй об оптовых продажах садовым центрам и озеленителям, а сезонную рамку спроса — со статьёй о помесячном календаре продаж растений.
Для теплицы weekly retail feedback полезен только тогда, когда в нём есть движение, остаток и трение. Продажи без остатка и контекста не объясняют ни реальный спрос, ни ошибку планирования.
Почему фраза «продалось хорошо» почти бесполезна для теплицы
Живой товар плохо переносит усреднение. Один и тот же сорт может уйти быстро в двух магазинах, зависнуть в третьем, а в четвёртом показать «нормальные продажи» только потому, что половину недели стоял пустой стол. Если теплица получает только итоговую продажу по сети, она не может отделить реальный спрос от недопоставки, ошибок выкладки, поздней уценки и списаний.
Это и есть разница между разговором «как вообще продаётся» и управляемым контуром обратной связи. Теплице нужен еженедельный сигнал, который переводится в операционное действие: увеличить повтор, оставить объём без изменений, перенести SKU в тест, сузить волну или не повторять её вовсе. Без этого еженедельный отчёт становится декоративным CRM-слоем, а не входом в допоставку и производственное планирование.
Weekly packet без on-hand, OOS и markdown не годится
Минимальный weekly packet для теплицы можно вести даже через Excel, CSV, Google Sheet или экспорт из POS. Но в нём должны быть поля, которые объясняют не только факт продажи, но и ограничители продажи. Особенно важны on-hand, OOS и markdown. Без них цифра sold units слишком часто врёт.
| Поле | Что именно просить | Зачем это теплице | Что сломается без поля |
|---|---|---|---|
| Магазин / кластер | Код магазина или хотя бы кластер похожих точек | Даёт разрез, где SKU действительно работает | Сеть в среднем прячет сильные и слабые магазины |
| Week ending | Одинаковая дата закрытия недели | Позволяет сравнивать динамику без сдвига периодов | Одна точка считает понедельник-воскресенье, другая среду-вторник |
| SKU | Точный артикул или единый код позиции | Исключает смешение сортов, размеров и серий | Теплица делает вывод по группе, а не по конкретной позиции |
| Sold units | Сколько единиц реально продано за неделю | Показывает темп ухода | Нет базового сигнала для пополнения |
| Receipts | Сколько единиц поступило в магазин за неделю | Отделяет продажу от эффекта свежего пополнения | Нельзя понять, был ли темп вызван новым приходом |
| On-hand end | Продажный остаток на конец недели | Показывает запас и риск OOS | Высокая продажа выглядит одинаково и при дефиците, и при избытке |
| OOS days / flag | Был ли нулевой остаток и сколько дней | Показывает упущенные продажи и ошибку пополнения | Теплица занижает потенциал сильного SKU |
| Promo / markdown | Была ли акция, скидка или forced clearance | Отделяет нормальный спрос от промо-разгона | Поставщик раздувает следующую волну на ложном успехе |
| Throw-outs / shrink | Сколько единиц списали, выбросили или уценили до нуля | Показывает цену ошибки на полке и в цепочке | Убыточный SKU выглядит «живым» только по продажам |
| Short notes | Погода, плохая выкладка, локальная акция, жалоба на качество, пересорт | Даёт причину, которую нельзя увидеть в цифре | Команда начинает гадать вместо диагностики |
Первый рабочий минимум для живого товара: sold units, receipts, on-hand, OOS flag, markdown flag и throw-outs. Уже на этом слое можно принимать более точные решения, чем по одной выручке.
Сначала согласуйте definitions, потом спорьте о выводах
У weekly loop нет одной магической формулы. Sell-through можно считать от прихода за период, от доступного к продаже объёма или через смешанную логику по остаткам. Weeks of supply тоже зависит от того, какой темп продаж берут в знаменатель и какая часть остатка реально доступна к продаже. Поэтому главный operational совет здесь простой: сначала договоритесь с садовым центром о составе KPI и формулах, а потом уже стройте выводы.
Для российского B2B это удобно делать без тяжёлой интеграции. Достаточно короткого совместного шаблона, где зафиксированы одинаковые definitions, дата закрытия недели, правило учёта списаний и единица измерения. Тогда даже выгрузка из 1С, POS или обычной таблицы начинает работать как репер, а не как набор спорных цифр.
Не вводите универсальный порог «хорошего sell-through» или одну норму покрытия запасом на все культуры и все магазины. Живой товар отличается по сроку товарного вида, скорости ухода, ритму поставок и цене ошибки. Полезна не догма, а согласованная система чтения сигнала.
Как читать weekly feedback: движение, остаток и трение
Оператору теплицы удобно читать weekly packet в три слоя. Первый слой отвечает на вопрос «двигается ли товар». Второй — «чем он был обеспечен». Третий — «какое сопротивление было на полке». Если читать только первый, выводы почти всегда будут слишком грубыми.
Движение: что реально купили
Смотрите sold units по каждой неделе и по магазину, а не только по сети. Для повторной поставки важен не сам факт продажи, а устойчивый темп ухода, который держится без экстренной уценки и без постоянного провала в OOS. Если один магазин продаёт ровно, а другой живёт от всплеска к всплеску, это уже два разных сценария управления.
Остаток: чем продажа была обеспечена
Продажа без остатка — это не всегда сильный спрос. Иногда это банально недокормленный магазин. Если sold высокие, on-hand низкий и в неделе были OOS-дни, позиция, вероятно, недопоставлена. Если sold умеренные, а on-hand всё ещё большой, скорее всего, товар не ускорился настолько, чтобы оправдать новый repeat drop.
Трение: что мешало чистой интерпретации
Здесь лежат markdown, throw-outs, жалобы, плохая выкладка, погодные всплески и локальные акции. Продажи, сделанные только через скидку, не равны здоровому спросу. Большой shrink после длинного стояния на полке может говорить о том, что товар пришёл слишком рано, магазин не держал ротацию или сам SKU плохо попал в своё окно продаж.
| Комбинация сигнала | Что это чаще всего значит | Базовое действие теплицы |
|---|---|---|
| Высокий sold + низкий on-hand + OOS | SKU сильнее, чем текущий объём поставки | Проверить repeat drop, lead time и окно следующего прихода |
| Высокий sold + markdown + высокий shrink | Спрос мог быть искусственно ускорен ценой, а не качеством матрицы | Не раздувать следующую волну автоматически |
| Низкий sold + высокий on-hand + без OOS | SKU идёт медленно или попал не в тот магазин/момент | Искать соответствие формату магазина, ценовой сигнал и окно продаж, а не сразу сеять больше |
| Нормальный sold + повторяющийся throw-out в конце окна | Есть спрос, но хвост волны слишком длинный | Сокращать поздний объём и ужесточать ритм дозавоза |
Decision tree: как переводить weekly feedback в пополнение
Ниже не математическая магия, а рабочий порядок чтения. Он нужен, чтобы не принимать решение о повторе по одной общей цифре по сети и не путать хороший товар с хорошей скидкой.
1. Сначала проверьте, не была ли продажа ограничена наличием
Если в отчёте есть OOS, низкий on-hand и высокий sold, сначала считайте это проблемой пополнения, а не пределом спроса. У живого товара это особенно критично: пустая полка быстро убивает и продажи, и визуальный сигнал категории. В таком случае repeat drop может быть оправдан раньше, чем кажется по чистым продажам.
2. Затем отделите обычный спрос от промо-события
Если неделя разогнана скидкой, акцией или локальным событием, не переносите этот темп прямо в production plan. Сначала посмотрите, удерживается ли движение без markdown. Иначе теплица начнёт выращивать объём под промо-исключение, а не под нормальный спрос.
3. Потом отделите сильный магазин от слабого магазина
Даже у одной сети разница между точками может быть больше, чем между двумя разными клиентами. Поэтому repeat drop лучше считать по магазину или хотя бы по кластеру похожих магазинов. Это же помогает не списывать сорт целиком, если он плохо пошёл только в одной локации с плохой выкладкой или слабым трафиком.
4. И только потом меняйте объём следующей волны
Когда данные очищены от OOS, markdown и шума от смешения магазинов, их уже можно переводить в действие: ранний repeat drop, удержание объёма, перевод в ограниченный тест или резку хвоста. Именно здесь помогает ABC/XYZ-анализ сезона: еженедельный сигнал показывает, что происходит сейчас, а постсезонная матрица — стоит ли SKU места в следующем цикле вообще.
Одна неделя редко достаточна для большого разворота плана волн, если внутри неё были receipts, акция или OOS. Weekly feedback нужен не для резких движений на эмоциях, а для раннего обнаружения повторяющегося паттерна.
Где кончается retail problem и начинается production problem
Самая дорогая ошибка теплицы — лечить производством то, что вызвано полкой, и наоборот. Weekly packet как раз нужен для разграничения ответственности. Ниже — рабочая схема, где не стоит прыгать к выводу раньше времени.
| Сигнал в еженедельном отчёте | Чаще проблема магазина | Чаще проблема теплицы | Что проверить до решения |
|---|---|---|---|
| Высокий sold, но частые OOS | Поздний reorder, слабая дисциплина пополнения, недогруженный магазин | Слишком редкий ритм отгрузки или слабый резерв по сильному SKU | Lead time, частоту поставок и фактический объём прихода |
| Низкий sold в одном магазине при норме в других | Выкладка, трафик, локальная цена, персонал, плохое место на полке | Редко, если жалоб на качество нет и другие точки продают нормально | Store split, фото полки, локальную цену и notes |
| Слабый sold по всем похожим магазинам без OOS | Возможно, окно спроса промахнулось или клиент ошибся с категорией | SKU не попал в матрицу, размер или стадия неудобны, окно поставки неверно | Сравнение с прошлым окном, формат растения, размер горшка и срок прихода |
| Продажа идёт только через markdown | Неверная полочная цена, поздняя реакция на slowdown | Переоценённый SKU, слабая ценность для формата магазина | Полную маржу, нормальную цену без скидки и динамику после акции |
| Большой shrink после долгого стояния | Плохой уход на площадке, слабая ротация, поздний reorder stop | Слишком длинный hold time до отправки, слабая кондиция к приходу, неверное окно поставки | Возраст партии на отгрузке, условия в магазине и timing прихода |
| Жалобы на качество повторяются в разных магазинах | Проблема магазина уже менее вероятна | Есть риск реальной production issue по партии или формату | Партию, дату отгрузки, фото, маршрут и повторяемость жалоб |
Эта граница особенно важна для разговора с клиентом. Если продавец сводит всё к «ваш товар не идёт», теплица теряет шанс улучшить реальное исполнение магазина. Если теплица в ответ автоматически обвиняет полку, она пропускает сигнал о неудачном размере, сроке или цене. Сильный контур обратной связи строится на цифре плюс коротком комментарии, а не на обмене взаимными ощущениями. Для дисциплины контактов и истории договорённостей полезно держать рядом статью о клиентской базе и повторных продажах, но weekly packet не должен растворяться в общей CRM.
Как weekly feedback меняет пополнение, ассортимент и план волн
У weekly loop три разных выхода. Первый — оперативный repeat drop. Второй — корректировка ассортимента по магазинам и кластерам. Третий — пересчёт следующей волны в теплице. Эти уровни не надо смешивать: то, что годится для дозаказа на следующей неделе, не всегда годится для расширения сезонного плана.
| Сигнал | Что делать в пополнении | Что делать в ассортименте | Что делать в производстве |
|---|---|---|---|
| Ровный sold без markdown, низкий on-hand, повторяемость по сильным магазинам | Подтверждать repeat drop и защищать окно поставки | Оставлять SKU в ядре для этого кластера магазинов | Поддерживать или слегка усиливать следующую волну под подтверждённый канал |
| Хороший sold только в части магазинов | Пополнять точечно, а не сетью целиком | Делить матрицу по форматам магазинов | Не расширять общий объём без подтверждения по кластерам |
| Продажи есть, но хвост заканчивается shrink и markdown | Сокращать поздний дозавоз | Переводить SKU в ограниченное окно или тест | Убирать поздний объём, а не растить его по инерции |
| Слабый sold без OOS и без жалоб, но с большим on-hand | Стоп по повтору, пока не понятен fit | Проверять store-fit, цену и место в матрице | Резать следующую волну или переносить SKU в тестовый режим |
| Повторяющийся OOS на сильных SKU | Ускорять repeat cadence и резерв | Укреплять статус якорной позиции | Повышать надёжность supply только после проверки реального store demand |
Именно здесь weekly feedback перестаёт быть «розничной статистикой» и становится входом в производственное планирование. Он помогает не только дозаказать сильную позицию, но и вовремя не повторять слабую волну, которая потом уйдёт в markdown и списание. Для годового горизонта это надо сверять с сезонным календарём продаж, а для структуры матрицы — с ABC/XYZ-разбором сезона.
Типовые ошибки, из-за которых weekly-контур не работает
- Просить у клиента только выручку или sold units и делать вид, что этого достаточно для repeat drop.
- Считать весь chain total по сети и не видеть, где SKU продаётся, а где просто умирает на полке.
- Не фиксировать definitions: одна сторона считает sell-through от прихода, другая — от остатка, и спор начинается ещё до вывода.
- Раздувать следующую волну после промо-недели, не проверив markdown, OOS и throw-outs.
- Путать store execution problem с production problem и лечить выкладку дополнительным объёмом.
- Оценивать SKU только по скорости продажи и не смотреть на shrink, позднюю уценку и длину хвоста.
- Пытаться построить весь контур через большую CRM-интеграцию, хотя для старта хватает короткого weekly packet в таблице.
Словарь терминов sell-through и weekly feedback
| Термин | Что это значит |
|---|---|
| Sell-through | Темп или доля ухода товара в продажу за выбранный период. Формулу нужно согласовать между поставщиком и ритейлером. |
| SKU | Отдельная товарная позиция, которую анализируют и пополняют отдельно от соседних сортов или форматов. |
| On-hand | Фактический остаток товара, доступный к продаже на момент отчёта. |
| Receipts | Приход товара в магазин за неделю или другой выбранный период. |
| OOS | Out of stock: ситуация, когда товар отсутствует в продаже или остаток обнулился. |
| Markdown | Скидка или уценка, которая может ускорить продажу, но не обязательно отражает нормальный спрос. |
| Shrink | Потери из-за списаний, выброса, гибели или другой неполной реализации товара. |
| Weeks of supply | Оценка, на сколько недель хватит текущего запаса при принятом темпе продаж. |
| Repeat drop / replenishment | Повторная поставка по работающему SKU, когда weekly data подтверждают необходимость пополнения. |
| Store cluster | Группа похожих магазинов, для которых допустимо принимать общее решение по ассортименту и пополнению. |