Bundles – package deals, value packages, savings packs, whatever you call them – are everywhere in the marketplace and are becoming an indispensable online merchandising tool. At their simplest, they are just a collection of products intended to be marketed and sold together. The upcoming platform release of EP (6.2) strives to provide flexibility and ease of use for you to incorporate bundling into your overall merchandising strategy. In advance of that release, over the course of the next few EP Insider posts, I want to discuss what they are and how they work in EP as well as the thinking behind our decisions – both technical and business.

There are lots of reasons for using bundles and you know them best for your market. Probably the most common is simply increasing average order size by offering savings across a group of items, for example, “Buy this Xbox 360 together with Halo 3 for $X”, where $X is just enough less than the combined price of the two items to encourage the shopper to spend more by buying them together. There’s also the ability to move less desirable surplus product by bundling it with other more desirable items, for example, “Buy this Xbox 360 together with Pong for $Y”, where $Y is sufficiently more than the price of the Xbox to yield an effective unit price for the Pong game that you’d never get selling Pong by itself. Or there’s the situation that I’m facing this Christmas since I’ve finally broken down and decided to buy a Wii for my kids. (I think I can safely assume they won’t be reading this post.) As a confused, middle-aged gaming newbie, I’m perfectly willing to pay a little bit more for a "pre-configured" bundle where everything is guaranteed to be compatible.

Regardless of the marketing motivation, bundles are essentially made up of two parts: the bundle itself and the collection of items inside it. So bundles contain products but are also products themselves. That is to say, in EP, we have modeled the bundle itself as a product, albeit a special kind. With this approach, basically anything you’re used to doing with a product, you can do with a bundle. You can manage it as a single entity in your catalog. You can give it a price (or prices). You can associate it with other products (upsell or cross sell). You can promote it, feature it, find it, etc. And in the storefront, just like any product can present itself via the basic template, any bundles will present themselves using a bundle-specific template. A bundle will show up in searches or other lists of products and its details can be viewed in the context of a product details page. If it’s what the shopper wants, they can add it to their cart with the click of a single button just like any other product. Additionally, your shoppers will find them first. If a shopper searches for “xbox”, the bundles containing Xboxes will be shown above the Xboxes themselves - the assumption here being that a larger order size is always a safe default goal.

Since bundles contain products but are also products themselves, guess what? Bundles can contain other bundles. We call these nested bundles. This provides significant flexibility in both offering and managing bundles. Smaller, foundational bundles can be re-used across many parent bundles. Think of the "gamer's accessory pack" that includes a game and extra controller. This pack could then be nested in various parent bundles that hold different models of the base gaming console. How far can you go with this? Well, theoretically the model supports infinite nesting, but for practical purposes, we have cut it off at three levels of nesting, which, when combined with the top level parent, allows for a total of four levels of bundles. Much beyond this and I think you're taxing anyone's mental model of something worth buying, let alone worth managing.

Earlier, I said that bundles are "marketed and sold together." I didn't include "delivered." This is key. A bundle is useful for defining a collection to be offered in a store, but the actual order and its subsequent fulfillment are more about the individual items. In the early stages of the ecommerce lifecycle (catalog management, display in the storefront, etc.) the emphasis is on the bundle that knows about its items. But in the downstream stages (order processing, fulfillment), the emphasis is on the items that know about their parent bundle.

There's always the special case of the "shrink-wrapped" bundle, but when you think about it, this is just a regular single product. If three things are managed, sold, processed, and delivered as a whole – a “shrink-wrapped” package - it's really no more a bundle than a shirt that is made up of a collar, two sleeves and some buttons. The shirt has to be kept together to be of any value but for a real bundle – say, the Xbox  and a downloadable game – the items have appeal when offered together, even though they’re ultimately split up for fulfillment. You explicitly create bundles if, at various points in the ecommerce lifecycle, your system is interested in the collection and at other points it’s more interested in the items.

That’s our view of bundles from the stratosphere. Over the next few blog posts, I'll drop down a few thousand feet and cover some of these sub-features...

• If the bundle means the shopper gets everything, it’s fixed but if you want to offer some choice for one or more of the items, then it's a Dynamic Bundle.
• If one or more of those choices is worth more than other choices, you may want to charge more - that's a Price Adjustment.
• If selling the bundle depends on the availability of the items then Bundles and Inventory become key.
• To be able to ship items separately and/or accept returns and exchanges, you need to have Apportioned Pricing for each item.