Module 5 lesson

SELL

[drop_cap]F[/drop_cap]or the mover, the estimate is the sale. There is no separate close — the number on the page is the price, the proof, and the pitch, all at once. Your product doesn’t hand a document to a scared prospect standing in a driveway. It hands a pricing page to a trial user who has been using the thing for eleven days and is deciding, alone, at 11pm, whether to type in a card number. The page has to do everything the mover’s estimate does: name a price, prove you’re not hiding something, and answer the one question underneath every other question.

This is Stage 5 of the Convert band, and the pricing page is the hardest document in your product because it is read by people at wildly different points of understanding, all expecting the same three seconds to resolve into a decision. A trial user who activated on day one reads it differently than one who logged in twice. An operations lead comparing three tools reads it differently than the founder who just wants it to work. The page can’t ask who’s reading. It has to answer for all of them at once, or it loses the ones it doesn’t answer for.

The Question Every Pricing Page Has to Answer

Ask anyone who has abandoned a checkout on a SaaS pricing page what happened, and the honest answer is rarely “too expensive.” It’s “I couldn’t tell which one was for me.” Three tiers, a wall of checkmarks, a feature comparison table with forty rows — and the reader closes the tab not because the price was wrong but because the page made them do work it should have done for them.

Call this the “which plan am I” test, and most pricing pages fail it. The test isn’t whether the tiers are named clearly or the checkmarks are accurate. It’s whether a reader who has never used your product, skimming for four seconds, can point at a tier and say “that one, probably” without reading a single feature row. If they can’t, the page is asking the customer to price the product themselves — to reverse-engineer your segmentation from a feature list — and most people would rather leave than do that work.

Passing this test is mostly about picking the right variable to organize around, not about better copywriting. That variable is your value metric.

The Value Metric — What the Price Scales On

Every pricing page implicitly picks one thing to charge more for as the customer gets bigger: seats, usage, records stored, sites managed, API calls, active projects. That thing is your value metric, and picking the wrong one is why some SaaS companies grow revenue slower than their customers grow value from the product.

A good value metric passes three tests:

1. It grows as the customer gets more value.
   (If a customer who's getting 10x the value pays the same price,
   you've capped your own growth at their growth rate.)

2. The customer can predict their own bill before they hit it.
   (No metric they can't see, can't estimate, or that moves
   without their action — a surprise invoice is a churn event
   wearing an accounting label.)

3. It does not punish the behavior you want more of.
   (Charging per seat when you want teams to invite everyone;
   charging per API call when you want developers to integrate
   deeply — both tax the exact usage that makes the product sticky.)
</br>

Seats fail test three constantly — a team that wants to add a client to a shared workspace hesitates because it costs money to include them, so the product gets used by fewer people than it should. Usage-based metrics (API calls, records processed, emails sent) pass test three well because more usage is unambiguously more value delivered, but they can fail test two if the unit is invisible to the customer until the invoice arrives. The strongest metrics are the ones a customer already thinks in — a marketer already thinks in “contacts,” a support tool already thinks in “tickets resolved,” a scheduling tool already thinks in “bookings.” Find the noun your customer already uses to describe their own growth, and price on that noun.

Tier Design — Three, and the Middle One Is Not an Accident

Three tiers, not two and not five. Two tiers forces a binary decision with nothing to anchor against; five tiers turns the page back into the feature-list problem the “which plan am I” test exists to catch. Three lets you build the middle tier to be chosen, with the outer two doing the work of making it look right.

The cheap tier exists to make the page feel approachable and to capture the smallest real customer — not to be profitable on its own. The expensive tier exists mostly to anchor: next to it, the middle tier’s price looks reasonable, and a portion of readers who would have picked the middle tier on price alone upgrade because the expensive tier’s extra capability is visible and named. The middle tier is the one you actually built the product to sell, priced at what your median good-fit customer should pay, and named for what that customer is (not “Pro” — “Team,” “Growth,” “Studio,” whatever your ICP calls itself).

What goes in which tier is a decision with real consequences: features versus limits.

Features are capabilities — a certain report type, SSO, an integration, an API. Limits are quantities on your value metric — more seats, more contacts, more of the same thing the customer already has. The rule that keeps the “which plan am I” test passing: gate on limits within a tier’s core use case, and gate on features only when a feature genuinely changes who’s using the product, not how much. A solo founder and a five-person team both want the analytics dashboard — don’t put it behind a tier wall, because you’ll train customers to feel locked out of the product’s actual value rather than upgrade toward more of it. SSO, audit logs, and dedicated support belong behind a wall because they signal a different buyer (IT, procurement) is now involved, not because the vendor wanted another lever.

Fill in your own numbers:

[Tier 1 name][Tier 2 name — the one they should pick][Tier 3 name]
Price$X/mo$X/mo$X/mo (or “Contact us”)
Value metric limitX [units]X [units]Unlimited or custom
Core use case
[Feature that signals a bigger team]
[Feature that signals procurement — SSO, audit log]
SupportSelf-serve[X]Dedicated

A page with this shape passes the four-second test because the reader locates themselves by the row that describes their team, not by counting checkmarks.

Annual vs. Monthly — What the Discount Actually Buys

The annual discount (commonly 15-20% off the monthly rate) isn’t really a price cut. It’s a trade: the customer gives up monthly optionality, and in exchange you get cash up front and a customer who is structurally less likely to churn on a bad month, because leaving mid-year means eating the unused balance. State it that way to yourself when you set the discount — it’s priced against churn risk and cash flow, not against what feels generous.

The failure mode is presenting the annual plan as the “real” price and the monthly plan as the inflated one, with a crossed-out number designed to make monthly feel like a penalty. A trial user paying monthly for the first time isn’t being cheap — they’re hedging, because they don’t yet trust that the product will still matter to them in month four. Respect that hedge. Offer the annual discount plainly, let the customer choose the commitment level that matches their own confidence, and never make the monthly price look like it’s being charged a fee for existing.

The Upgrade Moment — Outgrowing, Not Being Held Hostage

The moment a customer hits their plan’s limit is the single highest-leverage moment in this whole stage, and it can go two ways that feel opposite to the customer even though the mechanism behind them is identical.

Done well, hitting a limit feels like outgrowing the plan — evidence that the product is working, that the customer’s own growth triggered the message, and that upgrading is simply catching the price up to the value already being received. Done poorly, the exact same limit feels like being held hostage — the product stops working at an inconvenient moment, the message reads as a threat rather than a milestone, and the customer’s first association with your billing is being blocked.

The difference is almost entirely in the paywall’s mechanics, and there are three shapes to choose from:

Hard limit. The product stops functioning the instant the limit is hit — no more contacts can be added, no more reports generated — until the customer upgrades. This teaches the customer that your product is unreliable at the exact moment they were relying on it most, and it is the shape most likely to read as hostage-taking, because it optimizes for your revenue over their workflow.

Soft limit. The product keeps working past the limit, but with a persistent, honest banner: “You’re at 120% of your plan — upgrade to keep this pace.” This teaches the customer that the product respects their momentum and trusts them to act on clear information, and it converts better precisely because it never interrupts the moment that proves the product’s value.

Grace period. A hard limit that doesn’t bite for a stated window — 7 days, one billing cycle — with the same honest messaging as the soft limit during that window. This is the middle path for value metrics where a hard stop is a real cost concern (heavy usage-based pricing) but you still don’t want the first hard block to arrive with zero warning.

Whichever shape you choose, the message at the limit has one job: name the plan the customer is now living in, not the one they signed up for. “You’ve sent 1,200 emails this month on a 1,000-email plan” describes reality; “Upgrade now to continue” describes a wall. Say the first thing, and let the upgrade follow from the customer recognizing their own growth, the same way the mover’s binding-not-to-exceed estimate builds trust by naming the mechanism instead of hiding it.

The Three Objections That Decide the Sale

“It’s too expensive.” Don’t discount blind — reframe against the value metric. If pricing is per-seat and the objection is price, the real question is often “am I paying for people who barely use it,” which is a tier-fit conversation, not a discount conversation. Ask what they’re trying to get done and point at the metric that would actually save them money — a smaller tier, a different plan, or confirmation that the price matches the value they described wanting.

“We’ll just build it ourselves.” Don’t argue that they can’t — they probably can. Name what they’re actually buying: the maintenance, the edge cases already handled, and the time between “we started building it” and “it does what your product does today,” which is rarely the estimate they made when the idea first sounded easy.

“Can you give me a discount, or let me pay annually up front for less?” Answer with your actual policy, not a negotiated number invented on the spot. If you offer an annual discount, it’s already on the page — point to it rather than inventing a bigger one, because an ad-hoc discount teaches this customer, and anyone they tell, that the sticker price is fiction.

AI Earns Its Place Here

Pricing-page structure is repeatable in a way copy generation usually isn’t — the shape (value metric, three tiers, feature-versus-limit split, upgrade-moment copy) is a known scaffold, and a model is genuinely useful for filling that scaffold once you’ve made the judgment calls above.

Feed the model your actual value metric, your actual tier limits and prices, and the two or three features that genuinely signal a different buyer — then ask it to draft the tier table copy, the upgrade-moment message for each paywall shape, and a first pass at the three objection scripts in your product’s own voice. It’s fast at holding a consistent structure across all three tiers so the reader’s eye doesn’t snag on an inconsistency between them.

Treat the draft as a first pass, not a published page. Verify every number against your actual pricing model before it ships — a mismatched limit between the tier table and the in-product paywall message is the exact kind of small inconsistency that makes a customer re-read everything else on the page with suspicion. The model can hold the shape of a page that passes the four-second test; only you know whether the numbers inside it are the ones you actually charge.