# See who is still on old pricing and migrate them safely

> Browse your billing catalog by price point, see the customers and revenue sitting on each one, and move a group to new pricing with a preview first.

- Workflow type: app
- Services: Chargebee, Google Sheets, Slack Bot
- Categories: Finance, Product
- Published: 2026-08-16

## What it does

- Lists your product catalog by family, item and price point, and shows next to every price point how many active subscriptions sit on it and how much recurring revenue that represents.
- Click any price point to see exactly which accounts are grandfathered on it, with the customer behind each subscription and what they currently pay.
- Create a new price point right on the same screen, then build a migration to it, previewing every account's new charge and proration before anything changes.
- Applies only the accounts you accept, either immediately or at the end of each term, then writes a run log to Google Sheets and posts a summary of accounts moved and revenue impact to Slack.

## What you'll need

- A Chargebee account using the current catalog model of item families, items and price points, rather than the older plans and addons model.
- A Chargebee API key that can read your catalog and subscriptions and update subscriptions.
- A Google account, so the console can create and update the migration run log spreadsheet.
- A Slack workspace and a channel where the migration summary should be posted.

## Prompt

Build me a price book console for our Chargebee catalog that answers "who is still on our old pricing?" without exporting anything. Finance and product reopen this at every pricing review, so it needs to be a screen we work in, not a report we run.

The main view is the price book. Load our catalog with List Item Families, List Items and List Item Prices, and present it grouped by family, then item, then the price points under each item. Every price point row shows its external name and id, currency, amount, and billing period, and next to that two numbers that are the whole point of the console: how many active subscriptions sit on that exact price point, and how much recurring revenue that represents. Both come from List Subscriptions.

How you count matters. Do not fire a subscription lookup per catalog row. Page List Subscriptions in batches using the maximum page size and the next_offset token, filtered to active subscriptions, and in a single pass build an index of subscription items keyed by item price id, accumulating both a count and a revenue total per key. Cache that index for the session and have every price point row read from it. Chargebee live sites allow roughly 150 API calls per minute, so a large catalog must not turn into a call per price point. Show when the numbers were last refreshed and give me a refresh control to rebuild the index on demand.

Amounts are integers in the currency's smallest unit, so divide before displaying and format per currency. Group counts and revenue by currency and never sum across currencies into one total. This is Product Catalog 2.0 only. Work entirely in item families, items and item prices, and never reference legacy plans or addons.

Clicking a price point drills into the accounts sitting on it. List the subscriptions on that price point, and for each one enrich with Retrieve Subscription and Retrieve Customer so the table shows the company or customer name, email, subscription id, status, quantity, what the account currently pays, the next billing date and the current term end. This is the view where finance and product can see exactly who is grandfathered, so make it sortable by revenue and filterable, and let me search it.

From that drill-in I select a cohort and build a migration. I choose the accounts, pick the destination price point, and choose whether the change applies immediately or at the end of each account's term. Before anything is applied, the console previews each selected account with Update Subscription Estimate For Items and shows me a per account row with the current charge, the new charge, the proration and any credits, what would be charged now, the next renewal amount, and the difference. Preview before apply is a hard requirement. Never apply a cohort without a per account confirmation step, so each previewed row is individually accepted or skipped, and any account whose estimate fails shows the error inline and is excluded from the apply.

Applying runs Update Subscription For Items for the accepted rows only, honouring the immediate or end of term choice. Throttle the calls rather than firing them all at once, show progress and a per account result as it goes, and let a single failure fail just that account without stopping the rest of the run.

Every applied migration writes a run log to Google Sheets. Create the log spreadsheet with Create Spreadsheet the first time and remember its id afterwards, then use Append Values to add one row per account with the timestamp, who ran it, the subscription id, the customer, the price point moved from and to, the old and new amounts, the proration, the timing choice, and the result. Then post a summary to Slack with Send a Message to a channel I pick, covering how many accounts moved, how many were skipped or failed, the revenue impact by currency, the price points involved and a link to the log spreadsheet.

The console should also let me create a new price point in place with Create Item Price, on an existing item, taking the name, external id, currency, amount in the smallest unit, and billing period and unit. A new price point appears in the price book immediately and is selectable as a migration destination straight away, so a pricing change and the migration that follows it happen on one screen.

Remember my chosen Slack channel and the run log spreadsheet across sessions, and keep the history of past migration runs so I can open a previous run and see which accounts were moved and what the revenue impact was.

## How to customize

- Choose whether an approved migration takes effect immediately or waits until each customer's current term ends.
- Pick which Slack channel receives the summary and which spreadsheet keeps the running log of every migration.
- Narrow the account list before building a cohort, for example only annual customers or only accounts above a revenue threshold, so you can migrate in waves.

## FAQ

### Will this change anyone's billing without asking me first?

No. Every migration is previewed account by account before anything is applied, and you accept or skip each account individually. Only the accounts you accept are changed, and anything you skip is left exactly as it was.

### Can I move customers at their renewal instead of charging them right away?

Yes. When you build a migration you choose between applying it immediately, which prorates the current term, or scheduling it for the end of each customer's term so nobody is charged mid cycle.

### Does it work if we bill customers in several currencies?

Yes. Subscription counts and revenue are grouped by currency and shown separately for each price point, so amounts in different currencies are never added together into a misleading total.

### Will it be slow if we have a large catalog and thousands of subscriptions?

The console loads your subscriptions in batches and reuses them while you work, instead of asking your billing system about every row separately. That keeps it comfortably inside the request limits on a live billing site, and there is a refresh control when you want fresh numbers.

### Can I create the new price before I migrate anyone onto it?

Yes. You can add a new price point to an existing item without leaving the console, and it becomes immediately available as the destination for the migration you build next, so a pricing change and the move that follows it happen on one screen.

Use this prompt in General Input: https://www.generalinput.com/prompts/see-who-is-still-on-old-pricing-and-migrate-them-safely