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

Покупателю набор кажется простым: «купите вместе и сэкономьте». Но в магазине он одновременно затрагивает цену, налоги, акции, себестоимость и склад. Если не прописать чёткие правила, вы получите корзину, которая выглядит правильно, а отчёты будут медленно уходить в сторону от реальности.
Обычно сначала ломаются две вещи: скидка выглядит непонятно, и остатки становятся ненадёжными. Покупатель может увидеть цену набора, а потом ещё промокод, «compare at»‑цену или скидки на отдельные позиции — и выгода становится непроверяемой. Внутренние системы могут не договориться, продан ли набор как единица или как несколько товаров.
Две главные риски, за которыми стоит следить:
Набор также может выглядеть прибыльным, но фактически убыточным. Так случается, когда вы учитываете выручку на уровне набора, а себестоимость отслеживаете по компонентам (или вовсе не отслеживаете). В отчёте может быть здоровая «маржа по набору», в то время как реальная стоимость одного дорогого компонента игнорируется, скидка применяется дважды или возвраты случаются чаще, чем ожидалось.
«Точно» значит четыре практические вещи:
Корзина совпадает с обещанием: покупатель видит цену набора и экономию одним согласованным способом.
Продажи можно объяснить: вы можете ответить «сколько единиц каждого товара мы реально сдвинули?» и «сколько скидки мы дали?».
Запасы честны: при отгрузке одного набора списывается правильное количество каждого компонента, даже если на сборке берут детали из разных ячеек.
Возвраты не портят данные: если покупатель возвращает один товар из набора, система знает, как скорректировать выручку, скидку и запасы без догадок.
Если начать с чёткой математики ценообразования наборов и одного правила по учёту запасов, все остальные решения по наборам значительно упрощаются.
Прежде чем применять математику ценообразования наборов, дайте названию тип набора. Тип определяет, что видит покупатель, как меряется маржа и как должны двигаться запасы.
Чистый bundle — это «эти товары обязательно покупаются вместе». Подумайте «корпус камеры + объектив + сумка», продаваемые как одно предложение. Обычно это требует единой понятной цены набора, описания скидки (в сравнении с покупкой по‑отдельности) и согласованного списания компонентов одинаково каждый раз.
Набор «mix‑and‑match» — «выберите любые 3 из этой группы». Ценообразование и учёт здесь сложнее, потому что компоненты разные. Часто нужны правила вроде «такая же цена независимо от выбора» (просто, но маржи могут сильно колебаться) или «цена зависит от выбранных товаров» (чётче по марже, но сложнее в реализации).
Киты, мультипаки и ассорти звучат похоже, но ведут себя по‑разному:
Набору нужен собственный SKU, когда вы хотите стабильную отчётность и простые операции. Общие причины:
Избегайте создания наборов, когда «набор» — это временная акция. Если товары продаются отдельно и состав меняется каждую неделю, лучше использовать промо (правило скидки в корзине): каталог будет чище и проблем со складом будет меньше.
Покупатели редко считают в голове. Они сравнивают, сколько стоит набор сегодня и сколько, по их мнению, стоили бы эти товары по‑отдельности. Ваша задача — сделать это сравнение простым и согласованным, чтобы скидка выглядела реальной, а правила ценообразования — устойчивыми.
Начните с определения двух цен для каждого набора:
Затем рассчитывайте скидку одним стандартным способом и придерживайтесь его:
Сумма скидки = Справочная цена - Цена набора
Процент скидки = Сумма скидки / Справочная цена
Это самая простая форма математики ценообразования наборов и она соответствует ожиданиям большинства покупателей.
Округления — место, где теряется доверие. Если в корзине показывается $79.99 и «скидка 20%», покупатель проверит. Выберите правила, которые избегают странных копеек.
Практичный набор правил:
Наборы с опциями требуют ещё одного решения: берёте ли вы за основу для сравнения самый дешёвый возможный состав или тот, что выбрал покупатель? Для «выберите 1 из 3» вычисляйте справочную цену по выбранному варианту, а не по среднему, чтобы отображаемая экономия оставалась честной.
Наконец, решите, что происходит при изменении цен компонентов позже. Самый чистый подход — считать цену набора самостоятельным решением: держите её фиксированной, пока не решите её изменить, а «compare at»‑справочную цену пересчитывайте из текущих цен компонентов. Если это вызывает слишком резкие колебания скидки, задайте триггер для пересмотра (например, при изменении скидки более чем на 5 процентных пунктов), чтобы вы могли скорректировать цену до того, как покупатели заметят.
Скидка по набору «хороша» только если вы всё ещё видите прибыль. Начните с точного определения COGS (себестоимость проданных товаров) на уровне компонентов. Каждому предмету в наборе нужен текущий себестоимости за единицу (что вы платите за его покупку или производство), плюс любые дополнительные расходы, относящиеся только к набору, например специальная упаковка.
Себестоимость набора проста: сложите себестоимость компонентов, умноженную на их количество в наборе, затем прибавьте упаковку и обработку.
Bundle COGS = Σ (component unit COGS × component quantity) + packaging + handling
Gross margin $ = bundle price - Bundle COGS - shipping subsidies
Gross margin % = Gross margin $ / bundle price
Пример: «Starter Kit» продаётся за $99.
Bundle COGS = 28 + 12 + 8 + 3 = $51
Gross margin $ = 99 - 51 - 6 = $42
Gross margin % = 42 / 99 = 42.4%
Это основа математики ценообразования наборов: скидка понятна покупателю, а маржа остаётся видимой для вас.
Для отчётности может потребоваться распределить выручку по компонентам (для категорий, комиссий или налогов). Частый подход — пропорциональное распределение на основе самостоятельной цены каждого предмета. Если A составляет 50% от общей стоимости по одиночным ценам, то ему отдаётся 50% выручки набора. Держите правило распределения постоянным, чтобы отчётность месяц к месяцу оставалась сопоставимой.
Прежде чем публиковать скидку, задайте ограничители, которые блокируют плохие наборы:
Эти мелочи кажутся незначительными, но они быстро масштабируются. Если набор требует особой упаковки, учитывайте это как реальную себестоимость, а не как погрешность округления.
Если цена — это обещание, то запасы — это правда. В момент продажи набора ваша складская система должна быстро ответить на вопрос: какие физические товары только что покинули полку?
Вы храните только компоненты на остатках. Когда продаётся набор, вы вычитаете нужное количество каждого компонента (например, 1 бутылка + 2 фильтра). Это самый чистый вариант, когда «набор» в основном концепт ценообразования.
Он лучше всего работает, когда сборщики формируют набор при выполнении заказа. Он также сохраняет честность математики наборов, потому что видно, оплачивается ли скидка за счёт дешёвой доставки, повышения конверсии или просто за счёт маржи.
Модель B считает набор реальным товаром с собственным остатком. Вы собираете наборы заранее и списываете по 1 на продажу. При этом нужен шаг сборки, который потребляет компоненты при сборке, иначе остатки компонентов будут неверными.
Модель C сохраняет виртуальный SKU набора для продаж и отчётности, но резервирует компоненты в момент заказа (а не при отгрузке). Резервирование предотвращает перепродажу, когда запас небольшой или платёж авторизован, но не захвачен.
Простой выбор:
Несколько складов добавляют ещё одно правило: списывайте там, откуда реально отгружают. В моделях A или C выбор компонентов должен быть специфичен для склада (на складе 1 может быть зарядное, на складе 2 его нет). В модели B нужно отслеживать остаток наборов по складам и делать перемещения или заказы на сбор, чтобы перемещать наборы между площадками.
Короткий пример: вы продаёте «Starter Kit» с кружкой и крышкой. Если на складе A есть кружки, но нет крышек, модель A может продать набор только если заказ маршрутизирован на склад с обоими позициями, или если вы готовы к разделённой отгрузке (и дополнительной доставке). Модель B избегает этой путаницы, потому что хранит готовые наборы там, где их действительно можно отправить.
Набор ведёт себя корректно только если каталог и склад согласованы, что именно продаётся: новый артикул или набор существующих товаров. Начните с решения, что нужно отслеживать, как ценообразовать и как возвращать.
Используйте этот поток для настройки одного набора (и повторяйте те же правила для следующих):
Вот короткий сценарий для проверки: вы продаёте «Starter Kit» с 1 кружкой и 2 пакетами кофе. Если кружки нет в наличии, витрина должна либо блокировать набор, либо явно пометить его как бэко́рд, а система никогда не должна списывать 2 пакета кофе без резервирования кружки.
Если вы создаёте кастомные рабочие процессы, инструмент вроде Koder.ai может помочь определить правила набора (SKU, BOM, время списания) один раз, а затем сгенерировать логику каталога и учёта последовательно для веба и бэкенда.
Наборы становятся болью, когда реальность вмешивается: одной позиции не хватает, покупатель хочет замену, или возврат частичный. Проще всего сохранять заказ на видимом уровне компактным (одна строчка «набор»), а на комплектации и учёте работать на уровне компонентов.
Если один компонент отсутствует, заранее решите, можно ли отгрузить частично или нужно ждать полного комплекта. Если допускаете частичную отгрузку, списывайте только то, что реально отправлено, а остальное держите в резерве, чтобы не перепродать. Строка заказа остаётся «частично выполнена», но учёт запасов остаётся корректным.
Разрешать замены можно, если это контролируемая операция, а не самовольное «делайте как хотите». Установите правила замены, которые сохраняют отчётность и маржу:
Возвраты делятся на два пути: возврат полного набора и возврат одного компонента. Пример: «Starter Kit» продан за $90 (со скидкой с $100). В него входят бутылка ($40 list) и щётка ($60 list). Если возвращается весь набор, верните оба компонента на склад и возместите $90.
Если возвращается только щётка, верните часть оплаченной цены набора, а не полную стоимость щётки как отдельного товара. Простая, оправданная методика — прoратировать по справочной цене.
Это сохраняет скидки понятными, не даёт «бесплатных» возвратов и не даёт запасам уезжать в сторону со временем.
Наборы обычно рушатся по банальным причинам: правила каталога не прописаны, и математику применяют дважды. Исправление сводится к выбору одного источника правды для цены, маржи и запасов.
Самая большая складская ловушка — списание в двух местах. Если у вас есть SKU набора для продажи, решите, виртуальный ли это SKU (без собственного запаса) или «готовый» SKU (с собственным остатком). Виртуальные наборы должны списывать только компоненты. Готовые наборы списывают только артикул набора, пока вы не распаковали один для сборки.
Скидки также могут выглядеть больше, чем есть, из‑за округлений. Цена набора $49.99 кажется аккуратной, но если каждая позиция округляется по‑разному, подразумеваемая скидка может сдвинуться на цент‑два в заказе. Со временем это создаёт вопросы в поддержке и грязную отчётность. Выберите правило округления и применяйте его один раз, к финальной цене набора.
Вот распространённые ловушки, которые бьют по марже и операциям, и простые исправления:
Если вы реализуете логику в коде, сначала пропишите правила до имплементации. В Koder.ai режим планирования правил для набора (списание запасов, округления, стэкинг скидок) поможет сохранить поведение при экспорте исходников или добавлении новых наборов.
Перед публикацией набора потратьте 10 минут на проверку согласованности правил. Большинство проблем проявляется позже в виде «почему мы потеряли деньги?» или «почему запасы неверные?» — и обе проблемы обычно сводятся к неясной математике.
Начните с цены, видимой покупателю. Если вы показываете «Сэкономьте 15%», убедитесь, что это число базируется на тех же справочных ценах, что и везде (ваши текущие розничные цены, а не старый MSRP). Именно здесь математика ценообразования наборов проходит испытание в реальности: отображаемая скидка должна совпадать с тем, что покупатель может проверить.
Затем проверьте прибыль, используя точные затраты, которые будут у вас по каждому заказу. Включайте работу по комплектованию, упаковку, платёжные комиссии и дополнительные расходы на доставку из‑за веса или количества. Если набор выдерживает целевую маржу только при идеальном исполнении, это рискованное предложение.
Запасы — вторая половина. Решите, имеет ли набор собственный SKU, как он списывает компоненты и что происходит в крайних случаях (аннулирование, возвраты). Если вы не можете объяснить логику списания одной фразой, она сломается под давлением.
Короткий пред‑запусковой чек‑лист:
Если вы автоматизируете это в инструменте типа Koder.ai, сначала пропишите правила, затем реализуйте их точно по документу, чтобы цифры оставались стабильными при масштабировании.
Представьте «Starter Kit» из трёх товаров, которые также продаются отдельно. Цель — сделать скидку очевидной, прибыль — легко проверяемой, а запасы — всегда корректными.
Допустим, компоненты и их цены/себестоимость такие:
Если продавать по‑отдельности, покупатель заплатил бы $20 + $12 + $18 = $50 (это ваша «сумма частей»).
Теперь установите цену набора $42. Скидка = $50 - $42 = $8. Процент скидки = $8 / $50 = 16%.
Это самый понятный способ представить математику ценообразования наборов: покажите сумму частей, затем цену набора и экономию.
COGS набора — сумма себестоимостей компонентов: $8 + $4 + $6 = $18.
Валовая прибыль = $42 - $18 = $24.
Валовая маржа = $24 / $42 = 57.1%.
Этого одного числа достаточно, чтобы сравнить набор с вашими обычными маржами. Если целевой уровень 60%, вы понимаете, что этот набор чуть уже, и решаете, стоит ли повышенная конверсия этих потерь.
Начальные остатки: бутылки 40, полотенца 30, шейкеры 25.
Продали 5 наборов. Остатки должны списаться на 5 единиц каждого компонента:
Бутылки 40 - 5 = 35, полотенца 30 - 5 = 25, шейкеры 25 - 5 = 20.
Теперь покупатель возвращает только полотенце из одного набора. Положите 1 полотенце обратно на склад (полотенца 25 + 1 = 26).
В денежном плане выберите ясное правило и придерживайтесь его: либо (a) полные возвраты наборов, либо (b) частичные возвраты по доле цены компонентов от стоимости набора, а не по их самостоятельной цене. Если вы возвращаете по одиночной цене полотенца ($12), вы можете случайно превратить прибыльный набор в убыточный.
Наборы остаются прибыльными и точными, когда все следуют одним правилам. Прежде чем масштабировать наборы по каналам, запишите простую «политику по наборам», к которой команда сможет вернуться при проблемах.
Включите три вещи простым языком: как вы ставите цену набора (и как показываете скидки), как списываются запасы (SKU набора, компоненты или оба варианта) и как работают возвраты (возврат по набору или по компонентам).
Хорошая политика умещается на одной странице. Используйте короткий чек‑лист, например:
Дальше тестируйте крайние случаи реальными заказами, а не только таблицами. Создайте тест‑заказ для каждого ожидаемого сценария: частичный возврат, замена, бэко́рд по компоненту, набор с разными налоговыми категориями и изменение цены в середине месяца. Сохраняйте скриншоты или заметки, чтобы повторять тесты после обновлений системы.
Назначьте ежемесячный обзор, чтобы ловить дрейф маржи. Себестоимости компонентов меняются тихо, и ваша «отличная» сделка может стать убыточной незаметно. 15‑минутное напоминание в календаре, чтобы просмотреть топ‑наборы, себестоимости компонентов и фактические маржи, обычно достаточно.
Если ваши инструменты не умеют выразить правила чётко, сделайте небольшое внутреннее приложение, которое будет выполнять только то, что вам нужно (настройка наборов, валидация и отчётность). С Koder.ai вы можете описать правила набора в чате и сгенерировать бэкофисный инструмент (React + Go + PostgreSQL), затем безопасно итеративно менять логику с помощью снимков и откатов.