Software companies interrogate their churn and ignore their upgrades. Cancel a subscription and you'll get a reason list, an exit survey, sometimes a retention offer and a follow up email from a founder. Move up a tier and you get a receipt.
Which is odd, because the person who just upgraded has told you something much clearer than the person who left. Leaving has a dozen possible causes, half of which have nothing to do with you. Paying you more money means the product did something valuable enough to justify a bigger line on a card statement, and they know exactly what that something was. Right now, for about a week, they can tell you. After that the memory fades into a general sense that the product is useful.
The question to ask first
What changed?
Not "why did you upgrade," which invites people to describe your feature list back to you. What changed. Upgrades are almost never caused by the customer discovering a feature. They're caused by something happening in the customer's world: they hired someone, they landed a client that pushed them past a limit, a busy season started, a process they'd been doing in a spreadsheet finally broke.
That answer is the single most useful piece of marketing information in your business, because it describes the moment your product becomes worth paying more for. Collect thirty of those and you'll notice they cluster around two or three situations. Those situations are what your upgrade prompts should be about, and they're rarely what the pricing page currently says.
A worked example of the difference. A pricing page that says "Pro includes unlimited locations" is describing a limit. A prompt that says "adding a second site? Pro handles multiple locations" is describing the moment. Same feature, and the second one lands because it names the thing that just happened to them.
The second question: what nearly stopped you
Upgrades have friction, and the customer who pushed through it remembers what it was. Sometimes it's price, and often it's uncertainty: they weren't sure the higher tier included the thing they needed, they couldn't tell whether their existing data would carry over, they didn't know whether they could go back down if it didn't work out.
Every one of those hesitations is being felt right now by people who didn't upgrade, and you can't ask them because you don't know who they are. The customer who hesitated and then went ahead is the only person who can describe the objection and confirm which part of your page failed to answer it. That's a much better source than guessing at why your conversion rate is what it is.
Ask it plainly. Was there anything that made you hesitate? Was there anything you couldn't work out from the pricing page? People are surprisingly candid about this, partly because they've just committed and they're feeling positive, and partly because nobody usually asks.
When to ask
Two windows, and they answer different things.
Within a day or two of the upgrade, ask about the decision. What changed, what nearly stopped you. This is fresh and it's about the purchase, not the product.
Then again at three or four weeks, ask whether the upgrade did what they hoped. This is the one that predicts whether the upgrade holds. Someone who moved up for a specific reason and hasn't achieved it yet is on a slow path back down, and a month is early enough that you can help. Someone who got what they came for is a good candidate for a public review, and that's a fair thing to ask at that point rather than at random.
Don't ask both at once. A form landing the day after the upgrade that asks whether the new tier has delivered value is asking a question the customer cannot answer, and it comes across as either careless or as a satisfaction survey with a bow on it. The same timing logic applies to the early lifecycle, which what to ask new users in the first week covers for the signup end.
What to do with a downgrade
Handle the reverse case at the same time, because downgrades get even less attention than upgrades and they're the cheapest early warning you have.
A downgrade is a customer who has decided you're worth keeping but not at the price they were paying. That's a narrower and more useful complaint than a cancellation, and it's usually specific: they stopped using the one feature that justified the tier, or the team that needed it shrank, or the value was real for a project that ended. Ask which of those it is. A downgrade explained is often a re-upgrade later; a downgrade ignored is a cancellation with a delay on it.
If most of your downgrades and cancellations cite cost, read that pattern carefully rather than acting on it directly, and when every churn reason says "too expensive" goes into why the reason list misleads.
Reading upgrade answers next to everything else
The reason this information gets lost is that it arrives in small quantities, spread across months, in a different place from your other feedback. Five upgrade responses in a quarter don't feel like data, and they never get read against the rest of what customers are telling you.
They're more useful in context. When the same phrase shows up in an upgrade response, a support ticket, and a review, you're looking at the thing your product is actually for, stated three times in customer language. Qria keeps structured responses and public reviews in one place and summarises what keeps coming up across the lot, and that's how a handful of upgrade answers stops being anecdotes and starts being the basis for how you describe the higher tier.
There's a difference, too, between what upgraders say they wanted and what the product turned out to be worth to them. Both matter and they're often not the same sentence, the territory what users ask for vs what they need covers. For the wider set of lifecycle moments, the SaaS feedback guide has the full sequence.
Most teams can name their top three churn reasons and not one of their top three upgrade triggers. The second list is shorter, more actionable, and sitting in the inbox of people who'd be pleased to be asked.
