How Takealot bundles fix the per-unit fulfilment fee problem

TL;DR. In our post on Takealot fees, we identified the multi-unit trap: Takealot charges fulfilment per unit, so a single order containing 5 units of the same SKU costs you 5 fulfilment fees. The fix is structural — turn high-multi-unit-purchase SKUs into a single bundle SKU. Takealot has no special bundle category; a "5-pack" is just another listing that happens to dispatch 5 physical items in one box, paying one fulfilment fee regardless. Counterintuitively, don't discount the bundle. Sellers who price the bundle at full per-unit price still sell well, because the convenience of one click is the value — and the entire fulfilment-fee saving stays with you. The catch is operational, not commercial: one bundle SKU represents N physical units, so inventory maths gets harder until you set the translation up properly.

What's a Takealot bundle, really?

Nothing special. There is no "bundle product type" on Takealot, no separate category, no different fee schedule. A bundle is just a regular listing where:

• The title says it's a multi-pack ("Pack of 5", "Bundle of 3", "Family Size 6-Pack")
• The dispatched product is physically multiple units of the same SKU packed together as one item
• The inventory in Takealot's DC is recorded against this new SKU, separate from the single-unit version

That's it. You don't have to register it as a bundle anywhere. You don't unlock a special pricing rule. From Takealot's perspective, your "Pack of 5" listing is one product, dispatched as one item per order, charged as one unit.

The "bundle-ness" lives entirely in your title and your warehouse practice — i.e., that the box you ship to Takealot's DC contains 5 of the underlying product instead of 1.

Why the per-unit fulfilment fee is the central problem

A quick recap from the Takealot fees post:

• The fulfilment fee is charged per unit Takealot dispatches, tiered by size and weight band
• A customer order of 5 units of the same SKU costs 5 × the fulfilment fee
• On a low-priced SKU with a meaningful fulfilment band, the per-unit fulfilment fee can equal or exceed the unit margin

The post used the worked example of a R30 SKU with a R12 fulfilment fee. The unit margin stays at R15 if you've modelled fulfilment correctly. But the seller's problem is: the multi-unit orders that should be your most profitable customers (one logistics trip, one transaction, multiple items sold) are instead your most fee-burdened — because every additional unit triggers another fulfilment fee.

Bundling is the structural answer.

How a bundle fixes it

Compare the two paths for a 5-unit customer purchase:

Path A — Customer buys 5 × the single-unit SKU:

Line	Amount
5 × R30 sale	R150
5 × R3 Success Fee (10%)	−R15
5 × R12 fulfilment fee	−R60
Net to seller	R75

Path B — Customer buys 1 × the 5-pack bundle SKU (priced at R150 total):

Line	Amount
1 × R150 sale	R150
1 × R15 Success Fee (10% of R150)	−R15
1 × R12 fulfilment fee	−R12
Net to seller	R123

Same customer, same physical units delivered, same revenue. R48 better net. That R48 was wasted as fulfilment fees in Path A — and bundled into your margin in Path B.

This is the entire bundle play. The fulfilment fee is the saving. Everything else (Success Fee, customer experience, dispatch logistics) is identical between the two paths — only the per-unit fulfilment charge changes.

What about Success Fee and storage — do those save too?

Success Fee: no real saving. Takealot's Success Fee is a percentage of the sale price. Whether you sell 5 units at R30 each (R3 fee × 5 = R15) or one bundle at R150 (R15 fee × 1 = R15), the maths is the same. The Success Fee scales with revenue regardless of how the revenue is sliced.

Storage fee: usually negligible saving. Storage on Takealot is per unit per month, but a bundle box that physically contains 5 units takes roughly 5 × the space of a single unit. Takealot's per-unit storage charge applies to the bundle SKU as one unit, but the physical reality is that you're using 5 units' worth of DC space. Practically, storage on a bundle is a small saving on the per-SKU billing event, and roughly the same on the underlying space — depending on how Takealot's specific category-level storage rates work for bundle-size items.

Be honest with the maths. The fulfilment fee is the win. The other two are at best small wins. If you're modelling a bundle's profitability, model the fulfilment saving and treat Success Fee + storage as roughly flat.

The counterintuitive bit: don't discount the bundle

Standard ecommerce advice says: "Bundles should offer per-unit savings — 5 for the price of 4". That's the wrong instinct on Takealot for one reason: the fulfilment saving is already the value the bundle offers, and that saving belongs to you, not the customer.

Three pricing approaches:

Bundle pricing	What's happening
N × single-unit price (no discount)	Bundle costs the same per-unit as singles. Shopper buying N units sees no cost incentive — but gets the convenience of one click, one order, one dispatch. The fulfilment-fee saving stays with the seller as pure margin. This is the right default.
Small discount (5–10% per unit)	Bundle is cheaper per unit than singles. Drives bundle conversion harder, but you've given away part of the fulfilment-fee win as a shopper discount. Use when bundle conversion is the bottleneck.
Large discount (>10%)	You've given away most of the fulfilment-fee saving and probably some unit margin too. Only justifiable when bundle adoption is critical for category positioning, not for pure margin.

The mistake is reflexively discounting. Shoppers who want N units want the convenience. They don't always compare bundle-vs-single per-unit price — they see "5-pack" on the listing, calculate that 5 × the single-unit price is roughly the bundle price, and click. The bundle pays you better whether the shopper notices or not.

This isn't a free lunch — if your bundle pricing is higher than buying N singles, sharp shoppers will catch it and ding you in reviews. The rule is "don't discount" not "price above". Equal-or-slightly-below-equivalent works fine.

Which SKUs are bundle candidates?

The data is in your own sales: SKUs where customers already buy multiple units in a single order. Those shoppers are telling you, with their cart, that the bundle exists in their mind even if it doesn't exist in your catalogue.

Specifically, look at:

• Consumables — cleaning products, food, supplements, batteries, toiletries. Multi-unit consumption is baseline behaviour.
• Small parts in sets — cables, screws, hooks, candle sets, drinking glasses, anything where shoppers naturally buy in groups.
• Stationery / school supplies — pens, notebooks, files, where "I need 5 of these" is a normal sentence.
• Gift sets and party goods — pre-packaged for events.
• Anything with a current sales mix > 30% multi-unit orders — your sales data is the authoritative signal.

The pull-from-the-data move: for each of your top 20 SKUs, calculate the share of orders that included 2+ units of that SKU. Sort descending. The top 5 of that sort are your prime bundle candidates.

The gotcha: inventory management

This is the one real catch. A bundle SKU represents N physical units, but it shows up in your inventory as one stock unit. So:

• A bundle SKU with "10 in stock" actually represents 10 × N physical items — 50 units if it's a 5-pack
• When you replenish the bundle SKU, you're packing N units into each "stock-able unit" — your warehouse process is materially different from packing single units
• If the bundle and the single coexist (which they usually should — see next section), your physical unit inventory has to be allocated across two SKUs
• A returned bundle loses N units of physical inventory to a single return event — the return reason code is "one bundle returned", but it's 5 units that came back

Practically, this means you need:

1. A translation table somewhere: "Bundle SKU X = 5 units of single SKU Y" — visible to whoever does replenishment maths
2. A rule for inventory splits: which proportion of your physical units go into the bundle SKU vs the single-unit SKU. Start conservative; rebalance based on sales mix.
3. Awareness of the return-magnification: a bundle with a high return rate is N times more costly than a single with the same return rate. Tighten your bundle-candidate criteria for returns-prone SKUs.

The pain is real but managable. Most sellers solve it with a spreadsheet column and a habit.

Should the bundle replace the single, or coexist?

Coexist, almost always.

There's a category of shopper who wants exactly 1 of your product, and a category who wants 5. If you only list the bundle, you lose the 1-unit shopper to a competitor. If you only list the single, the 5-unit shopper triggers the multi-unit trap and you eat 5 fulfilment fees.

Both SKUs serving their natural shopper is the right setup. The two listings won't cannibalise as much as you'd expect — Takealot's search ranks on title relevance, and "Pack of 5" vs the single-product title compete on different queries.

The exception: SKUs where you only want to sell in multi-packs (low-margin items where single-unit sales are unprofitable even with the fulfilment correction). De-list the single, list only the bundle. Rare, but legitimate.

Frequently asked questions

Does Takealot have any special handling for "bundle" or "multi-pack" SKUs?

No. A bundle is a regular product listing. There's no bundle category, no special fee schedule, no separate listing type. The "bundle-ness" is in your title and what's physically inside the box.

Can I create a bundle listing from a single-unit listing automatically?

Not as a one-click operation in the Seller Portal — you create a new listing with new SKU, new title, new price, and new dispatch instructions. The underlying product is the same; the SKU is new.

How does Takealot handle a returned bundle?

A returned bundle counts as one return decision on one transaction, but the refund is the full bundle price, and the physical stock that comes back is N units. The Success Fee follows Takealot's normal rules — refunded on a full refund, generally not refunded on a repair/replacement.

What if a customer just wants 1 of the bundle's contents?

They can't buy 1 from the bundle — the bundle SKU dispatches the full N units. That's why you almost always want to keep the single-unit SKU live alongside the bundle. The two listings serve different shoppers.

Should the bundle title mention the saving / discount?

If you're not discounting (the default we recommend), no — there's no saving to advertise. The title should focus on the search-query keywords that signal "this is a multi-pack of X" (e.g., "5-Pack", "Bundle of 3", "Family Size 6 × 100ml"). Refer to the keyword research post for how to identify the right multi-pack search phrases.

What's a sensible bundle size — 3, 5, 10?

Match the customer's natural multi-unit cart. If your top multi-unit orders are mostly 3-units, build a 3-pack. If they're mostly 5+, build a 5-pack. Avoid arbitrary bundle sizes that don't reflect actual buying behaviour — a 4-pack of something usually-bought-in-3s sells worse than a 3-pack.

Does bundling work the same way for variant listings?

Yes, but more carefully. A bundle parent listing with multiple size/colour variants is legitimate, but the inventory translation gets twice as complex (bundle SKU + variant = N physical units of that specific variant). Usually safer to start with a non-variant bundle and add variants only after the base SKU is proven.

Can I automate finding bundle candidates from my sales data?

Yes. Gadjet's bundle-candidates skill scans your sales for SKUs where multi-unit purchase rates are high, ranks them by potential fulfilment-fee saving, and surfaces a prioritised list. The point is collapsing what's otherwise a 90-minute spreadsheet exercise into a one-screen output. See Gadjet.

What to do this week

If you've never considered bundling:

1. Pull your top 20 SKUs by sales volume from the Seller Portal
2. For each, calculate the share of orders that included 2+ units of that SKU
3. Sort descending — the top 5 are your prime bundle candidates
4. Pick the highest-leverage one (highest fulfilment fee × highest multi-unit share) and:
   • Create a new bundle SKU (pack of 3 or 5, whichever matches the typical multi-unit cart)
   • Price it at exactly N × single-unit price (no discount)
   • Update your warehouse process to dispatch N units per bundle-SKU order
   • List it alongside the single-unit version
5. Watch the sales mix shift over 30 days; bundle adoption typically lands at 20–40% of total units sold on the SKU

One bundle, one SKU, one month. The fulfilment-fee savings compound from the first sale.

The whole play is structural: change the way you list, not the way you sell. The customer experience is identical. The maths is just better for you.