> For the complete documentation index, see [llms.txt](https://docs.roadmap.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roadmap.so/subscriptions/getting-started/schedule-product-changes-across-billing-cycles.md).

# Schedule product changes across billing cycles

Use the Subscription Schedule to change what a subscriber receives on a given cycle: a different product after the first delivery, or a curated rotation across several cycles.

A subscription does not have to send the same product every time. **Subscription Schedule** on a subscription plan lets you change what the customer receives from a chosen billing cycle onward.

Two patterns cover most uses:

* **Start different, then settle.** The first delivery is a full kit, and every delivery after that is a refill.
* **Curate a rotation.** Each stage of the subscription sends something different, like a tasting series.

Find it in **Subscriptions → Plans**, on the plan you want to edit.

#### How cycles are numbered

**Cycle 1 is the first renewal after the initial purchase**, which the modal states as you fill it in. The initial delivery is whatever you set as the plan's subscription products.

So a change scheduled on cycle `1` takes effect on the customer's second delivery, not their first.

<figure><img src="https://393112916-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJ8asLD4FVCFagK40xEr4%2Fuploads%2FN6Yq5b3tKG6S0x2pRFiu%2FScreenshot%202026-09-24%20at%208.51.33%E2%80%AFPM.png?alt=media&amp;token=9e13704c-d241-422c-9546-efe4377b55b1" alt="" width="563"><figcaption></figcaption></figure>

#### A scheduled change carries forward

A scheduled change is not a one-off swap. It applies from its cycle onward, and stays in place until another scheduled change takes over.

This is what makes the starter-then-refill pattern a single scheduled change rather than one per cycle.

#### Add a scheduled change

{% stepper %}
{% step %}

### Open the plan

Go to **Subscriptions → Plans** and click the plan you want to change.
{% endstep %}

{% step %}

### Click Add scheduled change

Find the **Subscription Schedule** card. It reads *Schedule automatic product changes to the subscription. Useful for creating subscriptions with a different initial product.*
{% endstep %}

{% step %}

### Fill in the modal

* **On this billing cycle...** the cycle the change takes effect on. Defaults to `1`.
* **Change to this product** search for a variant, or click **Browse**.
* **Quantity** how many of that variant to send. Defaults to `1`.

Click **Add scheduled change**.

You can schedule any variant in your store. It does not have to be one of the plan's **Subscription Products**, so the product a customer switches onto never needs to be subscribable on its own.
{% endstep %}

{% step %}

### Check the schedule

The card now lists each change under **Cycle** and **Scheduled change**, for example `1` and `1 × Labs Face Cream - 500ml`. Use the pencil icon to edit a row or the bin icon to remove it.

Repeat for as many cycles as your sequence needs.
{% endstep %}
{% endstepper %}

#### Example: full size first, refills after

A soap sold as a 500ml bottle with presentation packaging, then topped up with a 1 litre refill pouch.

* Put the **500ml bottle** on the plan as the subscription product. That is what the customer buys initially.
* Add one scheduled change on cycle `1` for the **1 litre refill**.

The customer receives the bottle first, then the refill on every delivery after that. You only need the one scheduled change, because it carries forward.

The refill does not need to be on the plan. It can stay a product customers cannot subscribe to directly.

#### Example: a curated rotation

A coffee tasting subscription that moves through three styles, two deliveries each.

* Put the **dark roast** on the plan, so the initial purchase and cycle `1` are both dark roast.
* Add a scheduled change on cycle `2` for the **fruity** roast. Cycles `2` and `3` are now fruity.
* Add a scheduled change on cycle `4` for the **single origin**. Cycle `4` onward is single origin.

Because each change carries forward until the next one, you only add a change where the product actually switches.

{% hint style="info" %}
The last scheduled change continues indefinitely. Repeating a curated sequence back to the start is on the roadmap and is not available yet, so a rotation currently ends by holding on its final product.
{% endhint %}

#### Things worth knowing

* Editing a plan does not rewrite existing customer subscriptions. Scheduled changes apply to subscriptions created after you save.
* The **Billing Cycles Preview** on the plan form shows what each cycle delivers, including your scheduled changes. Check it before saving.
* Scheduled changes set the product. Cadence and discount still come from your delivery options.
* **Subscription Products** still controls what customers can swap to themselves from their account page. Scheduling a variant does not add it to that swap pool.

#### Related guides

* [Subscription plan settings, field by field](/subscriptions/getting-started/how-to-set-up-a-subscription-plan.md)
* [Adjusting an upcoming subscription order](/subscriptions/managing-subscriptions/adjusting-an-upcoming-subscription-order.md)
* [Realigning existing subscriptions to current prices (Price Sync)](/subscriptions/pricing-and-billing/realigning-existing-subscriptions-to-current-prices-price-sync.md)
* [The Subscription Activity Timeline](/subscriptions/managing-subscriptions/the-subscription-activity-timeline.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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.roadmap.so/subscriptions/getting-started/schedule-product-changes-across-billing-cycles.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.