# PDP Bundle Concepts — Reasoning & Recommendations

**Companion to:** [USAClean_Sitemap_Recommendations.md](USAClean_Sitemap_Recommendations.md)
**Live preview:** https://demo.thecxlabs.com/pdp.html (scroll past the product detail block)
**Date:** May 2026

This document explains the two bundle/kit concepts now carried in the PDP prototype, the BigCommerce app patterns each one is modeled on, and the trade-offs to consider before sequencing them. A third concept (Concept B — Service-Day Kit) was explored during initial prototyping and retired at stakeholder review; it's noted in passing where the original three-way comparison is referenced.

---

## TL;DR

We prototyped two distinct PDP bundle patterns on `pdp.html` so the team can compare them side by side. Both meet the four functional requirements (max 3 items, per-item qty, bundle savings, add-all-or-selected-to-cart) and are stylistically grounded in the existing design system tokens.

| Concept | Pattern | Best for | Implementation effort |
|---|---|---|---|
| **A. Frequently Bought Together** _(Phase 1)_ | Stacked product cards with `+` operators | Highest reach / lowest friction; algorithmic recommendations | Lowest — most apps support out-of-box |
| **C. Build Your Bundle** _(Phase 2 — data-gated)_ | Slot configurator with swappable companions | B2B purchasing managers who want choice; high-AOV custom kits | Highest — needs alternates picker UI |

**Decision: start with Concept A as a low-risk pilot, then evaluate Concept C as the data warrants.** Stakeholder review (May 2026) retired the previously-explored Concept B (curated "Service-Day Kit") in favor of focusing on these two patterns. Rationale at the end of this doc.

> **Decision of record:** [PD-001](decisions.md) — the PDP ships Concept A; Concept C is deferred (data-gated). Reflected in `v2/pdp.html`. See the [decision log](decisions.md) for the revisit triggers.

---

## What BigCommerce gives us (and doesn't)

BigCommerce has a native "bundle" capability but it's limited — it ties multiple SKUs to a single virtual SKU at a fixed price, doesn't support per-item quantity within the bundle, and doesn't show component products on the PDP. For everything in our requirements, we'll need a marketplace app. The relevant categories:

### "Frequently Bought Together" / cross-sell apps

- **[Smart Bundles AI](https://smartbundlesai.com/)** — AI-suggested bundles with virtual-bundle technology (no fake SKUs in the catalog). Vendor claims "+35% AOV" but the relevant capability is the FBT widget on PDPs. Supports per-item checkbox + qty, "add selected to cart," and discount via the BigCommerce Promotions API.
- **[Frequently Bought Together by IntuitSolutions](https://www.bigcommerce.com/apps/ultimate-upsell-cross-sell-suite-by-intuitsolutions/)** — manual or rule-based recommendations. Each item is a separate cart line item; bundle discount is applied at cart via promotion rule.
- **Pattern constraints they impose on us:**
  - Each item adds as a separate cart line, not as a single bundled SKU. (This is actually preferable for B2B reorder flows — line-item history stays intact.)
  - Discount is applied via promotion rule at cart, not as a "bundle price." UI on PDP can show the savings, but the actual discount is computed by the cart engine.
  - No native UI for "swap this item for that one" — that pattern requires a custom UI on top.

### Curated kit apps

- **[Kit Builder](https://www.bigcommerce.com/apps/kit-builder/)** — admin curates the kit, sets fixed bundle price or % discount, marks items as required vs optional. Source pattern for Concept C's slot configurator.

### Generic constraints to design within

1. **3-item maximum is a sweet spot,** not a technical limit. Most apps support 2–10 items in a bundle, but Baymard's research shows >3 items in a PDP bundle widget reduces conversion because users can't process the comparison.
2. **Per-item qty controls are not universal** — Smart Bundles AI and Kit Builder support them; some FBT apps default to qty 1. The prototype demonstrates qty stepping as a hard requirement.
3. **Bundle discount UI is decoupled from the discount engine.** The PDP shows "Save $X" copy; the actual discount comes from a cart-level promotion rule keyed on SKU combinations. This is fine — it just means the UI math and the cart math have to agree.
4. **Inventory** — apps handle this differently. Some show "low stock" warnings on individual items inside the bundle (Smart Bundles AI does this); others fail silently at checkout. The prototype shows in-stock badges per-item to demonstrate the pattern.

---

## Concept A — Frequently Bought Together

**Pattern:** [Smart Bundles AI](https://smartbundlesai.com/) / [Intuit FBT](https://www.bigcommerce.com/apps/ultimate-upsell-cross-sell-suite-by-intuitsolutions/) / Amazon's classic "Frequently bought together" widget.

**Visual:** Three product mini-cards laid out horizontally with `+` operators between them and a `=` total card on the right. Each card has its own checkbox (top-right) and quantity stepper. Subtotal recalculates live as items are toggled or quantities change.

**Why this pattern:**
- Lowest cognitive load. Users have seen this on Amazon for two decades.
- Lowest editorial overhead — pairings can be algorithmic (co-purchase data) or manual.
- Works equally well for the 2-item case (just one companion) without redesign.
- "Add selected to cart" is the proven default behavior; "Add all" is a single click via a small `Select all` action.

**Trade-offs:**
- Visually busiest of the three concepts at desktop widths because of the operator characters and 3 stacked cards. Can feel cramped on smaller viewports — the prototype stacks vertically below 1100px.
- Doesn't give the bundle a *narrative*. It's product math, not a use case.
- Bundle discount is conditional ("save 10% when 2+ selected"), which means users who deselect items see savings disappear — could feel punitive.

**Best when:**
- The bundle is generated algorithmically from co-purchase data.
- The companion items are commodity-ish (i.e., the user knows they need them; we don't have to sell them).
- We want to ship to every PDP without curation effort.

---

<!--
Concept B (Service-Day Kit) was explored during the initial round of bundle
prototyping but retired at the May 2026 stakeholder review. The team chose to
focus on Concept A as a low-risk pilot (Phase 1) and hold Concept C as a
data-gated follow-up (Phase 2). The "service-day kit" framing — naming a
bundle around a job-to-be-done — remains a useful merchandising lens and may
inform copy on Concept A pairings, but the dedicated curated-kit pattern is
no longer part of the recommended path.
-->

## Concept C — Build Your Bundle (slot configurator)

**Pattern:** [Kit Builder](https://www.bigcommerce.com/apps/kit-builder/) advanced mode with substitutable items, plus B2B-specific configurators like Grainger's "Configure & Buy" and McMaster-Carr's compatible-parts pickers.

**Visual:** Three numbered "slots." Slot 1 is locked to the current PDP product. Slots 2 and 3 are pre-filled with recommended companions but each has a `Swap →` action that opens an inline picker showing 2–3 alternates with prices and stock state. A sticky summary panel on the right shows the running bundle: items, subtotal, savings, total. CTA at the bottom of the summary.

**Why this pattern:**
- Matches the **B2B purchasing manager's mental model**: "I want this bundle, but with the bigger size of the cleaner and the kit version of the squeegee." The configurator gives them control without making them rebuild from scratch.
- Slot framing makes "this bundle has 3 items" explicit and visual — fewer items can be removed via the per-slot Remove button, but the structural max is fixed at 3.
- Sticky summary is the strongest CTA placement. It mirrors the cart drawer pattern users already know.
- Higher AOV potential because alternates can include "kit version" or "4-pack" upsells (the prototype demonstrates this with the cleaner 4-pack and the squeegee front+rear kit).

**Trade-offs:**
- The most complex of the three to build. The alternates picker requires a curated list of compatible substitutes per slot per primary product — significant taxonomy work.
- Visually denser. The summary sidebar takes 320px of width; below 1100px it stacks below the slots.
- Risks decision paralysis if we offer more than ~3 alternates per slot.

**Best when:**
- The user is an experienced B2B buyer who knows their preferences (volume, brand, OEM vs aftermarket).
- We have clean compatibility data to offer real alternatives, not just "anything similar."
- The category supports meaningful upsells (e.g., 4-packs, bundled kits-within-kits).

---

## How each concept satisfies the requirements

| Requirement | Concept A | Concept C |
|---|:---:|:---:|
| Max 3 items (this + 2 related) | ✅ | ✅ |
| Product card style + qty stepper per item | ✅ | ✅ |
| Bundle pricing with optional savings display | ✅ tiered | ✅ tiered |
| Add all OR add selected | ✅ explicit | ✅ per-slot |
| Per-item stock indicator | ✅ | ✅ |
| Substitution / "swap" capability | ❌ | ✅ |

---

## Recommendation

### Phase 1 — Pilot

**Ship Concept A as the default PDP bundle.** Reasons:
1. It works on every PDP without merchandising effort, so we can launch broadly and gather data.
2. It's the most familiar pattern, lowest cognitive load, lowest implementation effort.
3. It satisfies all four hard requirements with the simplest UI.
4. Most BigCommerce FBT apps render this pattern out of the box; we can validate the technical integration quickly.

**What "winning" looks like:** measurable AOV lift on PDPs that have the bundle vs. control, plus a leading "swap intent" signal — users clicking through to alternative items from the related-products row, or removing the second/third bundle items and adding different ones from the same category. That signal is what justifies moving to Concept C.

### Phase 2 — Configurator (data-gated)

**Concept C is the aspirational pattern.** Stakeholder review (May 2026) flagged it as the most exciting of the three explored, but also the most expensive to build. We're holding it for a follow-up release once Phase 1 data tells us whether the additional effort earns its keep.

It requires:
- Compatibility data (which SKUs can substitute for which) — overlaps with Find by Machine work in the IA roadmap.
- A curated alternates list per slot per primary product.
- More design polish and QA than Concept A.

**Triggers to graduate from A to C:** AOV lift on PDPs with the bundle, observable "swap intent" via clicks/changes, and a meaningful subset of users completing the FBT add-all flow. If those signals are present, the configurator's higher-AOV upside (4-pack and kit-version upsells inside the alternates picker) becomes the natural next step.

---

## Implementation notes

### Data we need
- **For Concept A (Phase 1):** A pairing table — for each SKU, a ranked list of 2 companion SKUs. Algorithmic (co-purchase frequency), manually curated, or hybrid.
- **For Concept C (Phase 2):** Slot definitions — for each primary SKU, two slot positions with 2–4 alternate SKUs each, plus a category label per slot ("Cleaner," "Squeegee parts," etc.). The alternates list overlaps with the compatibility data needed for Find-by-Machine.

### Discount mechanics
Both concepts assume the actual discount is applied via a BigCommerce Promotion API rule that fires when the cart contains the right SKU combination. The PDP UI just shows what the user *will* save — the cart engine is the source of truth. This is how every BC bundle app works.

### Cart line-item behavior
Items add as **separate line items** with the bundle promotion applied at cart. This is preferable to a single bundled SKU because:
- Returns and reorders work per-line, matching B2B expectations.
- Inventory deducts naturally per SKU.
- Order history shows the items the user actually bought, not an opaque "Bundle 4271."
- The Concept C summary copy ("Items add as separate line items with bundle promo applied at checkout") sets that expectation.

### Mobile behavior
- Concept A stacks vertically below 1100px (operators hidden, cards full-width).
- Concept C stacks the summary below the slots below 1100px (the sticky behavior is desktop-only). Below 700px the slot thumb hides and slot-actions move below the content.

### Accessibility considerations not yet addressed
The prototype uses `<div>` checkboxes for the toggle interactions. Production should wrap each as a real `<input type="checkbox">` with proper labels so screen readers announce the toggle state and keyboard users can tab through. Same for the slot Remove buttons and the swap picker — those need keyboard handlers and `aria-expanded`.

---

## Sources

- [Smart Bundles AI](https://smartbundlesai.com/) — AI-driven FBT for BigCommerce
- [Frequently Bought Together by IntuitSolutions](https://www.bigcommerce.com/apps/ultimate-upsell-cross-sell-suite-by-intuitsolutions/) — manual rule-based FBT
- [Kit Builder on BigCommerce Apps](https://www.bigcommerce.com/apps/kit-builder/) — used as the source pattern for Concept C's slot configurator
- [BigCommerce Apps marketplace](https://www.bigcommerce.com/apps/) — full bundling category
- [BigCommerce native bundled products docs](https://support.modernretail.com/hc/en-us/articles/360053361993-Bundled-Products-in-BigCommerce) — what's in core
- [USAClean_IA_Search_Roadmap.md](USAClean_IA_Search_Roadmap.md) — informs the alternates / compatibility data shared with Concept C