Your Upgrade Button Sends People to the Wrong Page: A Trial-to-Paid Case Study

The team had rewritten their pricing page twice. New feature bullets, a testimonial row, a "most popular" badge on the middle plan. Trial-to-paid didn't move.

Then they watched the session recordings of people who clicked Upgrade inside the app. Almost every one of them landed on the public pricing page — three columns, a marketing nav, a cookie banner — scrolled, clicked "Compare features," and left.

The copy was fine. The destination was wrong.

This is the teardown of the one change that fixed it. No fabricated benchmark at the end — you'll get the screens, the copy, the shipping order, and the measurement plan that tells you whether it worked on your traffic.

The leak you aren't instrumenting: what happens after the upgrade click

Your analytics almost certainly logs a pricing_page_view and files it under marketing. But when that view came from a logged-in user who clicked Upgrade, it isn't a marketing page view. It's the highest-intent event in your funnel: someone who has already used the product and is now trying to give you money.

And you hand them a page built for strangers.

What the public pricing page does that's wrong at this exact moment:

It re-asks who they are. No usage, no seats, no days left in trial. The user has to reconstruct their own context from memory.
It turns a decision into a comparison. Three plans, a feature table, a monthly/annual toggle. They arrived with one question and got handed a research task.
It offers nine exits. Marketing nav, docs, blog, changelog. Every one of them is a way to postpone the decision indefinitely.
It prices in the abstract. "Up to 50 invoices" means nothing until the screen also says they've sent 41 this month.
It doesn't answer "what happens Friday." The single most common unspoken question at trial end is never addressed.

This isn't a clarity failure. The page is clear. It's a hierarchy and guidance failure: the right content in the wrong order, for a user who is mid-decision rather than mid-shopping.

The before state: three plans, no memory, no context

Here's the flow as it shipped, and the friction at each step.

Before

Trial banner: Trial: 3 days left — Upgrade in red.
Click → public pricing page.
Three-column plan grid, annual toggle, feature comparison below the fold.
Click a plan → checkout, sometimes with a fresh form.
Confirmation email, no on-screen confirmation of the new limit.

Friction points, in order of cost:

Re-orientation: the user leaves the app and loses the task they were in.
Re-entry: any card or company detail already on file gets typed again.
Re-decision: they now have to compare plans they never intended to compare.
Silence: nothing on the page acknowledges the trial, the date, or the data they've accumulated.

After

Trial banner: Trial ends Friday · 3 days left · See my plan in neutral grey.
Click → in-app upgrade screen. No navigation change.
One plan card, populated with their own numbers.
One confirm step, card on file reused.
Confirmation screen shows the new limit already applied.

The routing change is the whole change. Everything else is copy.

The change: one in-app screen that answers three questions

The screen only has to answer three things, in this order:

What have I built here? Their invoices, their teammates, their projects. Live numbers, pulled from their account.
What do I lose on Friday? The one specific limit they'll hit, named, not the full feature matrix.
What does it cost, and when does it start? One price. One date. In the button, not in a footnote.

Then: one button. The comparison table goes behind a link below it, not above it. That's progressive disclosure doing real work — the full matrix is available, but it isn't the first thing a decided user has to wade through.

Trust here comes from using their data instead of your claims. "You've sent 41 invoices" is credible in a way "powerful invoicing tools" never will be, because they can check it.

If you're not sure which of your screens is leaking before you start rebuilding, run a free audit on your upgrade flow — it flags the routing problem before it flags the copy.

Before/after: the three lines that did the work

The layout change mattered. The words did the converting.

Header

Before: Choose the plan that's right for you
After: Your trial ends Friday. Here's what you'd lose.

Subhead

Before: Upgrade to unlock more features and remove limits.
After: You've sent 41 invoices and added 2 teammates this month. Pro keeps both and lifts your invoice limit to unlimited.

Primary button

Before: Upgrade now
After: Keep my account — $29/mo from Friday

Secondary action

Before: Compare plans
After: Not ready? Your data stays read-only for 30 days. Remind me.

Why each one earns its place:

The header names the date, which converts an open-ended nag into a deadline the user can plan around.
The subhead is a mirror, not a pitch — it repeats their usage back to them, which is the cheapest trust you will ever buy.
The button carries the price and the first billing date, so "when am I charged?" is answered before it's asked. The em dash beats a footnote every time.
The secondary link turns a hard no into a deferral instead of an exit. That's feedback, not pressure — and it keeps the account alive for one more week.

One rule: never use the word "Upgrade" as the button label. It describes your revenue event, not their outcome.

Ship it this week: a P0/P1/P2 playbook

P0 — the routing and the screen

Any upgrade click while authenticated lands on an in-app upgrade screen, never the public pricing page.
That screen shows three live values: usage this period, seats, days left in trial.
One recommended plan. Comparison table behind a link, below the fold.

P1 — the copy

Header names the trial end date.
Button names the price and the first billing date.
Secondary action offers a deferral, not a dead end.
One plain sentence about what happens to their data if they don't convert.

P2 — the edges

Card on file: skip the form, single confirm step.
Confirmation screen shows the new limit already active — that's feedback closing the loop.
Annual toggle defaults to monthly, with the annual saving shown as a line of text, not a tab war.

Keep the public pricing page. It's a comparison page for strangers, and it should stay that way. Just stop routing insiders to it.

What to measure, and the mistake that erases the lift

Instrument the click, not the page. upgrade_clicked → upgrade_screen_viewed → plan_confirmed → payment_started → paid. If you only track page views, the routing change is invisible in your own data.
Cohort by trial start date, not by calendar week. Trials straddle your ship date and will smear the result if you slice by week.
Watch the deferral rate. If "Remind me" spikes after the change, your price or your timing is wrong — not your copy.
One change per release. If you ship the new screen and a discount in the same week, you learn nothing and you'll be rewriting the pricing page for a third time.

The mistake that erases the lift is bundling. The routing fix and the copy rewrite belong in the same release because they're the same screen. Everything else — annual toggle, testimonials, a new plan tier — waits.

Trial-to-paid doesn't usually move because of a better argument. It moves because you stopped interrupting a decision with a comparison. More teardowns of this shape live on the blog if you want the pattern across other flows.

If your trial-to-paid number has stayed flat through two copy rewrites, the leak is probably upstream of the words. Start a free FlowAudit at /signup and you'll get a prioritized P0/P1/P2 fix list for your own trial-to-paid flow in minutes — routing first, screen second, copy third.