On the site, a bundle is a hero module: camera, case, card, a nicer price than buying them apart. In the warehouse, three SKUs have to leave together, or the order is a lie.
Most bundling programs start with the module. They end in support tickets: the kit sold, one component was already gone, the price of the set did not match the parts, the B2B customer needed a different pack inside the same "kit."
The commercial benefits people cite — higher order value, attach, completeness, moving slow stock with fast — are real when the relationship is operationally true. They are merchandising fiction when only the storefront knows the grouping.
Bundle Versus Kit Is Not Vocabulary. It Is Inventory.
A bundle is a commercial grouping. The items can be sold alone. The value is convenience or a deal. Inventory still lives at the component. Selling the bundle must decrement each child, across every channel, at the moment of promise.
A kit is completeness. A brake job, a maintenance set, a fastener assortment for an application. The customer is buying a solution. Missing one child is not a backorder of an accessory. It is a failed job. Kits often have a BOM in ERP already. Commerce that sells a kit SKU without exploding to components will show stock that does not exist, or fail to show stock that does.
Product content needs those relationships as data, not as a sentence ("also sold with"). Complex catalog search needs them to retrieve a solution, not eight near-miss SKUs. Agents recommending "the set" will invent one if you do not model it.
Pricing is the second relationship. Set price, component list, contract on the parent, discount on the children — pick the rule and execute it. Do not let a merchandiser type a bundle price that finance cannot explain and the warehouse cannot pick as a set.
Variants make it worse. A kit that includes "a hose, size as required" is not a SKU. It is a configuration. Treat it as quoting, or explode it to real children with ATP.
ATP on the parent is a derived number: the limiting child, in the right unit, in the promising location. If you show parent quantity as if it were a bin, you will sell sets you cannot complete. Multi-location and B2B allocation make the derivation mandatory, not clever.
Fulfillment Is Where the Page Meets the Bin
Pre-kitting common combinations is a warehouse choice, not a theme choice. If you pre-build, the kit location is inventory. If you pick-to-order, the pick path must guarantee all children, not a checklist on paper. Substitutions inside a kit have to be allowed in the BOM, not improvised because aisle 12 was empty.
Labor math belongs here. Pre-kitting pays when the combination is stable. Pick-to-order pays when the mix changes weekly. Merchandising should not force pre-kits for a promotion that lasts ten days unless the warehouse agrees. The page does not pay the overtime.
Returns reverse the explosion. Did the customer return the set or a child? Does the component go back to sellable? Does the kit SKU resurrect? Get this wrong and you either strand parts or sell a kit you just dismantled.
B2B completeness kits — everything to finish a spec — are where this is not optional. A manufacturer or distributor who cannot promise the set should not merchandize the set. Inside sales already knows which combinations are legal. Encode that, or keep kits off the site.
Dealers assembling kits for the floor have the same requirement with POS in the loop. If the register sells a kit SKU that commerce does not explode, channels will disagree on what left the building. Publish the same parent-child object everywhere you sell the set.
Price the Set as Policy
If the kit is cheaper than the sum of parts, say why: completeness, pick cost, or a promotion with a date. If a customer can game the set by buying children separately, either stop selling children, or stop pretending the kit is a deal. Finance will find the leak.
Contract accounts that have a price on the parent and a different price on children need a single rule at quote time. Quoting owns authorization. The kit object has to be visible there, not only on a PDP.
Do Not Start With AOV
Start with a combination you already ship correctly. Model parent and children in PIM and ERP. Price the set as a rule. Promise ATP on children, not on a phantom parent. Pick it. Invoice it. Then put it on the page.
Seasonal bundles and promotional sets can follow the same object with a date range. They should not be a CMS group with no inventory effect.
Attach and "complete the job" merchandising should reuse the same relationships. If search, recommendations, and the kit page each invent a different grouping, the customer and the warehouse will disagree. One graph of product relationships, many surfaces.
Moving slow stock by bolting it onto a fast SKU only works if the child is actually in the bin and the price still makes sense after the fee of picking two lines. Otherwise you have hidden a dead SKU in a popular one and trained customers to return the extra.
If the website can sell a grouping the warehouse cannot complete today, you do not have a bundling strategy. You have a display. Leadership should treat kit and bundle work as product-relationship architecture — the same family as BOM, substitution, and attach — not as a conversion widget to be A/B tested in isolation.
When the object is true, AOV and attach become available as consequences. You can promote the set, let search retrieve it, and let an agent recommend completeness because completeness is data. Until then, turn the hero module off. Selling a picture of a kit is how you buy returns and dealer distrust in one click.