# How to ask for feedback after an upgrade or downgrade

> After an upgrade, ask what made the higher plan worth it. After a downgrade, ask what would have kept them on the higher plan. Store the old and new plan as metadata, send the downgrade reason from your backend, and read downgrade answers alongside cancellation reasons.

Source: https://escutaproduto.com/resources/feedback-after-plan-change
Last updated: 2026-10-11

## Why a plan change is a different moment

A plan change is one of the few moments when a customer has made a clear, paid decision about your product. Upgrading means they found enough value to spend more. Downgrading means something stopped being worth the money, or their needs shrank. Both moves carry information, but the two directions answer different questions, so they need different prompts.

The mistake most teams make is to send the same generic "how did we do?" message after either change. An upgrade needs a question about what tipped the decision. A downgrade needs a question about what would have kept the customer where they were. Asking the same question for both wastes the moment.

## What should you ask after an upgrade?

After an upgrade, ask what made the decision worth it. The customer just paid more, so they are the best person to explain the value. Ask one question, in a text box, and keep the reply optional. Good copy is short: "You moved to the larger plan. What made it worth it for you?"

The answers tell you which features people pay for, which is different from which features they use most. Some of the most useful answers name a limit they hit, such as a number of projects or a team size. Those limits are good candidates for your pricing page, and the [pricing page guide](/resources/pricing-page-feedback) covers how to read those objections without changing prices on instinct.

Do not ask for a rating or a review after an upgrade. A customer who just paid is not a neutral observer, and a rating at that moment will read higher than the product deserves. Let the text answer stand.

## What should you ask after a downgrade?

After a downgrade, ask what would have kept them on the higher plan. This wording invites a concrete answer, such as a missing feature, a limit that was too low or a feature that moved to another tier. It also avoids sounding like an accusation. A question such as "why did you leave?" asks for an excuse, and an excuse is rarely useful.

Keep the downgrade question to a single field, placed in the confirmation step rather than on a separate screen. The customer has already decided, and a long form will feel like a barrier to leaving. If the field is empty, let the change go through anyway.

## How do you store the plan as metadata?

Your app should tell the widget which plan the user is on. The `identify` call accepts a `plan` key, and every other key is stored as metadata on each message the user sends. Call it again after the plan changes, so reports sent afterwards carry the new plan.

```js
window.EscutaProduto = window.EscutaProduto || { q: [] };
(window.EscutaProduto.q ||= []).push([
  "identify",
  [{ id: user.id, email: user.email, plan: "team", planChangedAt: "2026-10-11" }],
]);
```

For the downgrade reason, send the answer from your server, not the browser. The customer may close the tab right after confirming, and the server already knows the old and new plan. Use the REST API with the public key, a message, the kind `other`, and metadata that records the direction.

```js
await fetch("https://escutaproduto.com/api/v1/feedback", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    key: process.env.ESCUTA_PUBLIC_KEY,
    kind: "other",
    message: downgradeReason,
    email: account.ownerEmail,
    metadata: {
      event: "plan_downgrade",
      fromPlan: "team",
      toPlan: "starter",
      accountId: account.id,
    },
  }),
});
```

Skip the request when the reason is empty or shorter than two characters, because the API requires at least two characters in the message.

## How do you read downgrade reasons next to churn?

A downgrade is often the step before a cancellation. The customer reduces the price first, then leaves a few months later. Reading the two together shows you the path. Filter the inbox to the product, then search the messages for the words your downgrade prompt used, and group the answers by reason in a spreadsheet.

Use the CSV export for the spreadsheet. Count distinct accounts for each reason, not individual messages. If twelve accounts downgraded because a reporting feature moved to the higher plan, that is a pricing signal you can test. If the same reason appears in cancellation reasons six weeks later, the downgrade was not the end of the story.

Set aside the downgrades from accounts that have been customers for less than a month. Early downgrades often reflect a plan chosen by mistake, and that is an onboarding problem, not a pricing one. The [cancellation feedback guide](/resources/cancellation-feedback) shows how to read the same kind of answers when the customer leaves completely.

## What to do with upgrade and downgrade answers

Upgrade answers tell you which value to promote. Put the most common phrases into your product pages and onboarding copy, using the customer's own words. Downgrade answers tell you where the boundary between plans should move, or which feature needs a clearer explanation. A downgrade reason that names a missing feature belongs in the planned queue with a note linking to the feedback items.

Share a monthly summary with the team, with the number of upgrades, the number of downgrades and the top three reasons for each. Keep the summary to the reasons, not the names of customers. The [weekly review template](/resources/weekly-feedback-review-template) can hold the same summary if you already run a regular review.

## Setting this up in Escuta Produto

Create the product, copy its public key, and add the widget to your settings and billing pages. Call `identify` with the plan whenever the page loads, so the metadata stays current. Keep the server call for downgrade reasons in the code path that confirms the change, and check the setup by downgrading a test account and watching the item arrive with the event name in its metadata.

The [widget docs](/docs/widget) describe the identify call and the metadata options. The [API docs](/docs/api) list the fields and the error codes, including the rate limit, which a single account change will never reach.

## Frequently asked questions

### What should you ask after a customer upgrades their plan?

Ask what made the higher plan worth it, in a single optional text field. The customer just decided to pay more, so their answer names the value they see. Avoid rating questions at that moment, because they tend to read higher than a neutral customer would give.

### What should you ask after a customer downgrades?

Ask what would have kept them on the higher plan. That wording invites a concrete answer, such as a missing feature or a limit that was too low, and it avoids the excuse-making that a question about why they left usually produces.

### How do you record the plan in feedback?

Pass the plan to the identify function of the widget, which stores every key other than email and name as metadata on later messages. Call it again after a change, and send server-side downgrade reasons with the old and new plan in the metadata object.