01TL;DR
Two PDP bundle patterns prototyped on pdp.html. 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.
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 below.
Decision of record: PD-001 — the PDP ships Concept A; Concept C is deferred (data-gated). Reflected in v2/pdp.html.
| Concept | Pattern | Best for | Effort |
|---|---|---|---|
| A. Frequently Bought Together Phase 1 | Stacked product cards with + operators |
Highest reach, lowest friction; algorithmic recs | Lowest — most apps support out of the 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 + compatibility data |
02What 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.
"Frequently Bought Together" / cross-sell apps
- Smart Bundles AI — 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 — manual or rule-based recommendations. Each item is a separate cart line item; bundle discount applied at cart via promotion rule.
Pattern constraints they impose
- 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 shows the savings; the cart engine is the source of truth.
- No native UI for "swap this item for that one" — that pattern requires a custom UI on top.
Curated kit apps
- Kit Builder — admin curates the kit, sets fixed bundle price or % discount, marks items as required vs optional. Renders as a kit-level PDP-like experience.
- BundleBees — themed kits with discount via the BigCommerce Promotions API (currently Beta). Supports basic kits with required + optional items.
- Integer Bundle Buddy — focuses on bundle merchandising and reporting.
Generic constraints to design within
- 3-item maximum is a sweet spot, not a technical limit. Most apps support 2–10 items, but Baymard's research shows >3 items in a PDP bundle widget reduces conversion because users can't process the comparison.
- Per-item qty controls are not universal. Smart Bundles AI and Kit Builder support them; some FBT apps default to qty 1. Our requirements treat qty as mandatory.
- 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.
- Inventory handling varies. Some apps show "low stock" warnings on individual items inside the bundle; others fail silently at checkout. Our prototype shows in-stock badges per item to demonstrate the pattern.
03Concept A — Frequently Bought Together
Frequently Bought Together
Stacked product cards with mathematical operators
Pattern source: Smart Bundles AI / Intuit FBT / 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 allaction.
Trade-offs
- Visually busiest of the three concepts at desktop widths because of the operator characters and 3 stacked cards. 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"). Users who deselect items see savings disappear — could feel punitive.
The bundle is generated algorithmically from co-purchase data, the companion items are commodity-ish (the user knows they need them), and we want to ship to every PDP without curation effort.
04Concept C — Build Your Bundle
Build Your Bundle (slot configurator)
Three slots with swappable companions and sticky summary
Pattern source: 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 — items can be removed, but the structural max is fixed.
- 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.
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, and the category supports meaningful upsells (4-packs, kits-within-kits).
05Requirements coverage
How each concept satisfies the four hard requirements:
| Requirement | A | 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 | — | ✓ |
06Recommendation
Ship Concept A as the default PDP bundle.
- It works on every PDP without merchandising effort, so we can launch broadly and gather data fast.
- Most familiar pattern, lowest cognitive load, lowest implementation effort.
- Satisfies all four hard requirements with the simplest UI.
- Most BigCommerce FBT apps render this pattern out of the box; we can validate the technical integration quickly and de-risk the bundle promo wiring before investing in anything more involved.
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.
Concept C is the aspirational pattern. Stakeholder review (May 2026) flagged this 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 directly with the Find-by-Machine work in the IA roadmap, so the underlying data investment serves both features.
- Curated alternates per slot per primary product — typically 2–4 substitute SKUs each.
- More design polish and QA than A: alternates picker, sticky summary, swap-state UI, mobile collapse.
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.
07Implementation 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
All three 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 explicitly.
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.
The prototype uses <div> elements for checkbox 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.