> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/using-peakcommerce/products-and-bundles/creating-a-product-bundle.md).

# Creating a Product Bundle

A **bundle** is a catalog product (Type: **Bundle**) that groups two or more products so customers buy them as a single item. Bundles matter most for **trial → paid** offers: you combine a trial product and a paid product into one purchasable thing, then control *when* each member activates — so the trial starts now and the paid plan kicks in later, without maintaining a separate "bundle code" in the billing system.

## Build a bundle

1. Go to **Commerce → Product Catalog** and click **Create Product**.
2. Set **Product Type** to **Bundle**.
3. Give the bundle a **name**, **SKU**, and **category**.
4. Under **Select Products for Bundle**, check the **member products** to include. Members can be Internal or Synced products (a bundle can't contain another bundle).
5. For each member, set its **Activation Timing** (see below).
6. Save, then set the bundle **Active** when it's ready to sell.

You can revisit a saved bundle to add or remove members and adjust each one's timing from the **Bundle Products** section.

## Activation timing (the trial → paid model)

Each member product carries its own activation rule, so the bundle can stage a lifecycle rather than activating everything at once:

* **Immediate** — the member activates with the bundle (typical for the trial member).
* **Delayed** — the member activates after a set **delay** (a value plus **days**, **weeks**, or **months**). Use this to start a paid plan a fixed time after purchase.
* **Triggered** — the member activates when another **trigger product** in the bundle activates or ends — e.g. the paid plan begins when the trial completes.

Delays and triggers are evaluated against the contract/service dates in your billing system, so activation offsets depend on the [Zuora tenant timezone](https://gitlab.com/peak-hercules/peak-help-docs/-/blob/main/integrations/zuora-integration/zuora-billing-integration.md) being set correctly — otherwise an offset can land a day early or late.

## How pricing works

A bundle has no single "bundle price" field. Its price comes from its members' charges (and any **Pricing Tiers** you define), so a delayed or triggered paid member is billed only when it actually activates. Mark trial members **non-renewable** in their **Plan presentation** so they don't appear as a renewing Current plan in the Change-Plan journey.

## Gotchas

* A bundle won't sell until its **Status** is **Active** — and neither will an inactive member inside it.
* Set **trigger products** carefully: a member can't trigger itself, and removing the trigger product later leaves the dependent member without an activation rule.

## Related

* [Product Bundles Overview](/product/using-peakcommerce/products-and-bundles/product-bundles-overview.md)
* [Products Overview](/product/using-peakcommerce/products-and-bundles/products-overview.md)
* [Commerce actions in journeys](/product/journeys-and-pages/journey-steps/commerce-actions.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.peakcommerce.com/product/using-peakcommerce/products-and-bundles/creating-a-product-bundle.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.