The Upgrade Button Isn't the Problem — the Line Under It Is: A Trial-to-Paid Case Study

Most teams spend their copy budget on the pricing page and about four minutes on the upgrade screen. That's backwards.

The pricing page is where people decide. The upgrade screen is where they commit. Those are different jobs, and they need different words. In the upgrade flow — the screens between "I'll take it" and "payment succeeded" — the user has already made the emotional call. What's left is a four-second scan for a reason to stop.

Here's a case where two lines on that screen did more than a redesign would have.

Why trial-to-paid leaks at the commit step, not the pricing page

On the commit step, users are quietly asking three questions:

What exactly am I buying, and what gets charged when?
What happens to the projects, seats, or data I already have?
If this is wrong, how do I get out — specifically?

If any of those goes unanswered, the user does the safest thing available: opens a new tab, goes back to your /pricing page, re-reads, and often never returns. Back-navigation to pricing is the quietest leak in most upgrade flows, because it doesn't look like a bounce. It looks like a thoughtful buyer.

The heuristics in play here are boring and they're the whole game: clarity (can they tell what the button does), trust (will this be a surprise charge), and feedback (does the screen tell them what just happened). None of that is about button color.

The case: two lines, one screen, no redesign

A two-person B2B SaaS with live traffic and trials that expired without converting. Their upgrade screen was unremarkable:

Three plan cards at the top
A button reading Upgrade to Pro
A gray line under it: "You will be charged $29/month. Cancel anytime."

What they actually looked at before touching anything:

Cancellation reasons and support tickets. The recurring phrase wasn't price. It was some version of "I wasn't sure what I'd get" and "I didn't know if my projects would carry over."
The drop-off pattern: people entered the upgrade screen, then went back to the pricing page. Re-reading is a symptom, not a habit.
Session recordings of the commit step, mostly to see whether anyone read the gray line. They didn't.

Then they changed two lines. Same layout, same plan cards, same price. If you want that same read on your own flow before you rewrite anything, run a free audit on your upgrade flow at /signup — it will tell you which lines are doing work and which are decoration.

Before and after: the button and the line under it

Before

[ Upgrade to Pro ]
You will be charged $29/month. Cancel anytime.

After

You're on Trial: 3 projects, 1 seat.
Pro adds: unlimited projects, 5 seats, priority support.

[ Start my Pro plan — $29/mo ]
Billing starts today. Cancel in two clicks: Settings → Billing.

Why each piece earns its space:

The button names the object and the price. "Upgrade" describes your billing event. "Start my Pro plan — $29/mo" describes theirs. A user should never have to guess what happens when they click.
The delta line answers "what changes." Current state, new state, in the user's words. "3 projects" beats "Tier 2" every time — this is the guidance heuristic applied to a single sentence.
The reassurance line answers when you're charged and how you get out. Note the actual path: "Settings → Billing." "Cancel anytime" is a promise. A path is a fact, and facts survive scrutiny.
The in-flight state got copy too. The button now reads "Setting up your Pro plan…" instead of spinning silently. That's feedback, not decoration.

What they deliberately did not add: urgency, a countdown, a testimonial carousel above the button. The commit step is not the place for persuasion. It's the place for confirmation. Persuasion that shows up after someone has decided reads as pressure, and pressure on a billing screen costs trust you already paid for.

On results: I'm not going to hand you a fake-precise percentage. The exact movement depends on your baseline, your price point, and how bad the old copy was. What mattered here is that the change held across two full trial cycles and that "what am I actually buying" tickets dropped off. Copy that removes a question is usually the cheapest fix on the table.

The 30-minute playbook: audit your upgrade flow's commit step

P0 — ship this week, no design work required

Button label includes the plan name, the price, and what starts now.
One line under it answers: what you get, when you're charged, and the exact cancel path.
One line above it shows current plan vs. new plan in the user's own units (projects, seats, exports — not tier names).
Error state says what failed and what to do next, in plain language.

P1 — next sprint

Billing toggle labels say "Billed monthly" / "Billed yearly" instead of leaning on "Save 20%" alone.
Loading and success states carry copy: "Setting up your Pro plan…" → "You're on Pro. Here's what's new."
Trial or proration wording is explicit — say what happens to the unused days.
Strip competing exits from the commit screen: nav links, footer, and any "compare plans" link that sends people back to /pricing.

P2 — test later, one variable at a time

Social proof, but only if it's real, specific, and from a customer like this one.
Annual upsell — placed after commit, never before it.
A/B on the button label alone, once the P0s are live and settled.

How to know it worked, without kidding yourself

Measure the commit step, not the funnel. Sessions that reach the upgrade screen vs. sessions that complete payment. If you only watch trial-to-paid, you can't tell a copy problem from a traffic problem.
Segment by trial day. The copy that converts a day-1 power user is not the copy that converts someone on day 13 who forgot your product exists. Two different screens, ideally.
Treat back-navigation to pricing as a failure signal. If people keep bouncing to /pricing from the commit step, your screen isn't answering the three questions.
Read for "I didn't know…" in tickets and cancellation reasons. That's a copy bug, not a pricing bug, and it's fixable this week.
Write the hypothesis down before you ship. Otherwise you'll credit the copy for a seasonal bump and learn nothing.

Why "Upgrade" is the wrong word — and three other traps

"Upgrade" is your billing event, not the user's job. It tells them a state change happened to your database. It says nothing about what they get.
Urgency on the commit step costs trust. Countdowns are a pricing-page tactic, and even there they're expensive. On a billing screen they read as manipulation.
Marketing copy in the reassurance slot. The line under the button is closer to a contract than a headline. Keep it factual, specific, and boring.
Copy can't fix a missing feature. If your cancellation reasons are feature-based, rewriting the button buys you one cycle and nothing more. Fix the product first, then the words. We've written more of these teardowns on the /blog if you want the pattern across other flows.

The upgrade screen isn't a place to be clever. It's a place to be unambiguous. Two lines, rewritten, usually beat a redesign — and they ship in an afternoon.

If your trial-to-paid number is soft and you're not sure which part of the upgrade flow is responsible, stop guessing. Start a free FlowAudit at /signup and you'll get a prioritized P0/P1/P2 fix list for your own flow in minutes — button copy, reassurance line, error states, and the leaks in between.