Pricing Page Reference Card
Paid community pricing page — three-element checklist, outcome specificity templates, access-structure components, risk reduction selection, and failure mode diagnosis
This page is a structured reference card for paid community operators writing or auditing their pricing page. It covers: a three-element checklist table (what each element is, what it must include to work, what the failure version looks like, and the prospect’s question it answers); an outcome specificity template table by community archetype (three archetypes with the right prospect stage descriptor, specific metric to name, credible timeframe, falsifiability test, and an example outcome statement); an access-structure description component table (five components each with what to include, what to avoid, and poor-vs-good examples); a risk reduction selection table (three structures with when to use each, conversion rate ranges for qualified traffic, required conditions to offer without adverse-selection risk, and the specific language pattern); and a failure mode diagnosis table (three failure modes with what each looks like on the page, the prospect’s internal monologue, the signal from the prospect-legibility test, and the specific element to fix first). For the conceptual framework — why feature-list pricing pages fail, how the three-element structure works causally, and how to run the prospect-legibility test — see the companion post: Paid community pricing page: the three elements that convert. This card is for the operator who understands the reasoning and needs the templates, decision criteria, and reference tables in quick-reference form.
TL; DR
A paid community pricing page converts when it answers three questions in sequence: “Does this result apply to my situation?” (outcome specificity), “What exactly am I buying?” (access-structure framing), and “What happens if it doesn’t work out?” (risk reduction). Most pricing pages skip the first question entirely and lead with a feature list that answers no question the prospect is actually asking. Use Table 1 to audit which element your current page is missing or failing. Use Table 2 to write or rewrite the outcome statement. Use Table 3 to write or rewrite the access-structure description. Use Table 4 to select the right risk reduction structure for your community model. Use Table 5 to diagnose which failure mode is operative if your page is not converting. If you can only do one thing: run the prospect-legibility test (five ICP-matched readers, one question: “can you tell me specifically what you would be buying and whether it applies to your situation?”) before changing any copy.
Table 1 — Pricing page element checklist
The three elements that a paid community pricing page must contain, in the order they must appear. The sequence is not arbitrary: a prospect who cannot identify whether the outcome applies to them will not read the access-structure description; a prospect who understands the outcome but cannot visualize what they are buying will not commit; a prospect who understands both but perceives the commitment as irrecoverable will defer. Missing any one element does not produce a page with two-thirds of the conversion power — it produces a page with a specific failure mode that frustrates conversion at a specific stage of the prospect’s decision process. The “prospect’s question it answers” column identifies the decision-stage where each element does its work.
| Element | What it is | What it must include to work | What the failure version looks like | The prospect’s question it answers |
|---|---|---|---|---|
| 1. Outcome specificity | A single, falsifiable, stage-specific result that the right prospect recognizes as exactly their situation — not an aspiration, not a category of benefit, not a list of possible outcomes. The outcome statement is the opening claim of the pricing page and is the filter that tells the right prospect “this is for you” and tells the wrong prospect “this is not for you.” Both functions are necessary: a statement that attracts everyone converts no one. | Three properties must all be present. Falsifiable: the outcome names a specific metric and threshold the prospect can check at a specific date (“reduce 90-day churn rate below 10%” is falsifiable; “improve your retention” is not). Stage-specific: the outcome is accurate for the prospect’s current stage, not for a more advanced or earlier stage (“operators who have crossed 100 paying members and are losing 15%+ in the first 90 days” is stage-specific; “community operators” is not). Single: one primary outcome, not a list (“retain more members, grow faster, and build a stronger community” forces the prospect to self-identify which of three outcomes applies, which produces a cognitive cost that reduces conversion). | A list of outcomes (“grow your community, increase engagement, and drive more revenue”). A category descriptor instead of an outcome (“the community for serious community operators”). An aspirational state with no mechanism (“become the kind of community operator who never loses sleep over churn”). Any outcome that passes without the prospect knowing their specific stage: if a prospect at 50 members and a prospect at 1,000 members could both read the statement and think “yes, this applies to me,” the statement is not stage-specific and will not convert either prospect effectively. | “Does this result apply to my specific situation right now?” This is the primary screening question every prospect runs on a paid community pricing page, and it runs before any other question. A prospect who cannot answer yes to this question with confidence does not proceed to read the access-structure description, regardless of how good the access description or risk reduction offer is. Outcome specificity is the gate; it does not close the sale, but it determines whether the prospect reaches the rest of the page. |
| 2. Access-structure framing | A description of what the price buys in terms of specific people, interactions, and first-30-days experience. The access-structure description is not a feature list and is not a platform tour. It is a narrative answer to the prospect’s primary purchase question: “will the specific people in this community be relevant to my situation?” A feature list (monthly calls, Slack channels, resource library) cannot answer this question. Only a description of the peer group, the interaction format, and the first-30-days experience can answer it. | Five components must be present. Peer group descriptor: the member count in the relevant segment and the career or business stage range (not a count of all members — a count of the members who are at the right stage for this prospect). Format of interaction: the primary mechanism for peer exchange, with frequency and structure. First-30-days action sequence: the named actions a new member takes in their first month, stated specifically enough that the prospect can decide whether they want to take those actions. Body of knowledge: the accumulated resource the community has built (AMA archive, playbook library, deal-flow log) that the prospect cannot build alone. First-month success condition: the operator’s stated definition of a successful first month — what the member should be able to say they have done or received by day 30. | A feature list with platform attributes (“24 channels, 4 live calls per month, a resource library with 200+ templates”). A testimonial section that quotes members on how valuable the community is without describing what specifically made it valuable. A tour of the platform interface rather than a description of the people in it. Any description that would be equally true of a community with no members at the prospect’s stage as of a community where they are well-represented: “members from 40 countries in every stage of their journey” is the failure version because it answers “is this community diverse?” rather than “are there people like me in it?” | “Will the specific people in this community be relevant to my situation, and what will my first month actually look like?” This is the question the prospect is asking when they have already decided they want the outcome but have not yet decided whether this specific community will produce it for them. Feature lists answer a different question (“what are the community’s capabilities?”) that most prospects are not asking at this stage of the decision. Access-structure framing answers the question the prospect is actually asking and moves them from “interested” to “ready to commit if the risk is manageable.” |
| 3. Risk reduction | A structure that converts deferred intent into immediate action by addressing the prospect’s residual concern: “what if this specific community doesn’t work out for me, even though the outcome seems right and the access structure seems relevant?” Risk reduction is not a discount and is not a free trial. It is a commitment structure that lowers the perceived cost of being wrong: the prospect is not choosing between joining and not joining, but between joining with the right to evaluate and joining without it. The three appropriate structures differ by community model and have meaningfully different conversion rates and adverse-selection risks. | Specificity on three dimensions: the evaluation period (not “the first month” as a vague sense but a specific number of days); the evaluation criteria (the specific outputs or interactions that, if they occurred, would demonstrate that the membership delivered on its core promise — stated with enough precision that the operator can reasonably commit to them); and the relief available if the criteria are not met (a specific refund amount, access to the next cohort at no additional cost, or a specific pre-purchase interaction that answers the relevance question before payment). Generic risk reduction copy (“cancel anytime,” “30-day money-back guarantee,” “no commitment required”) converts at 2–8% of qualified traffic. Specific risk reduction copy converts at 25–40% for defined-criteria evaluation structures with well-specified criteria. | “Cancel anytime” with no evaluation criteria. A generic money-back guarantee with no specification of what would trigger the refund. A free trial that gives full access for 14 days without a structured evaluation framework (produces high trial signups and low conversion because members do not know what they are evaluating during the trial). A refund offer that is self-assessed by the member without any external check (“if you don’t feel you got value” invites adverse selection from members who join with the intention of consuming resources and cancelling, because the refund criteria cannot be contested). Risk reduction that is vague enough that the member must trust the operator’s future judgment to honor it — which requires a level of trust the pricing page has not yet earned. | “What happens if I pay and it doesn’t work out for me specifically?” This is the question that holds back a prospect who has already decided the outcome applies to their situation and the access structure seems relevant. Without a risk reduction element, the decision the prospect is making is: “pay $X and hope this community is what it seems.” With a specific risk reduction element, the decision becomes: “pay $X and evaluate whether [named criteria] happened by day [N] — and if they did not, recover [specific amount].” The second decision is structurally easier to make, which is why defined-criteria risk reduction consistently produces higher conversion rates on qualified traffic than any alternative copy change. |
The most common audit finding is a pricing page that has risk reduction (a generic money-back guarantee or “cancel anytime” line) but does not have outcome specificity or access-structure framing. This produces a page where the prospect can see that joining is low-risk but still cannot tell whether the community is right for them. Low risk of a bad fit and high confidence of a good fit are different things. Risk reduction only converts when the prospect already believes the community will deliver the outcome they need — which requires the first two elements to have done their work first. Add risk reduction last, not first.
Table 2 — Outcome specificity template by community archetype
Three community archetypes that represent the most common paid Slack community models, each with the template components needed to write an outcome statement that passes the falsifiability, stage-specificity, and single-outcome tests from Table 1. The archetype determines what kind of outcome is credible (what the community’s mechanism is designed to produce), which determines what metric the outcome statement can name, which determines what timeframe is defensible. Use the archetype that matches your community’s primary mechanism, then fill in the specific numbers and stage descriptors that are accurate for your membership.
| Community archetype | Right prospect stage descriptor | Specific metric to name | Credible timeframe | Falsifiability test | Example outcome statement |
|---|---|---|---|---|---|
| Retention-focused (peer-learning community where the primary value is operator-to-operator knowledge transfer on running the community itself) | Operators who have crossed a specific member count threshold and are experiencing a specific retention problem. The stage descriptor must name both the scale point (number of paying members) and the problem metric (the specific churn rate or activation rate that is below the benchmark for that scale). A descriptor that is accurate for a 50-member community and a 500-member community simultaneously is not stage-specific. | Reduction in 90-day churn rate, improvement in first-month activation rate, or improvement in month-6 retention. The metric must be one that the community’s mechanism directly addresses — if the community’s primary mechanism is peer critique of onboarding sequences, the outcome metric should be activation rate, not revenue growth (which is too far downstream of the mechanism to be credible in 90 days). | 60–90 days. Shorter timeframes are not credible for operational changes in community management (the mechanism requires implementation time plus a member cohort to run through the new process). Longer timeframes (6 months+) reduce conversion because the prospect is making a near-term budget decision and a 6-month promise is cognitively distant. | The prospect can look at their cohort retention data at day 90 and check whether their churn rate is below the promised threshold. The test fails if the metric is not one the prospect can measure (requires access to data they do not have), if the threshold is not specific (requires a judgment call about what “improved” means), or if the timeframe is ambiguous (90 days from when?). A passing falsifiability test means the prospect can mark a date on their calendar and check whether the outcome happened. | “Paid community operators with 100–500 paying members and a 90-day cancellation rate above 15% reduce that rate to below 10% within 90 days of implementing the three-touch onboarding sequence their cohort peer-reviews and adapts together. 23 of the last 28 operators in this stage bracket who completed the 90-day cohort reached that threshold.” |
| Activation-focused (skills-based or practice community where the primary value is completing a specific deliverable or crossing a specific capability threshold through structured peer accountability) | Practitioners who have been doing the relevant work for a specific number of years (not beginners, not advanced practitioners who have already crossed the threshold the community produces) and who have not yet crossed a specific measurable threshold. The stage descriptor must exclude the wrong stages: a beginners-welcome framing undercuts credibility for practitioners who have been working for 2–3 years and are evaluating whether this is the right level; an advanced-practitioners framing undercuts credibility for people at the target stage who do not yet self-identify as advanced. | A specific deliverable completed, a specific capability demonstrated, or a specific threshold crossed. The metric must be the direct output of the community’s mechanism (what the peer accountability structure is designed to produce), not a downstream business result. If the community’s mechanism is structured peer critique plus accountability partnerships, the metric is a completed deliverable or a milestone crossed — not the revenue that follows from the deliverable (which the community does not control). | 30–60 days for deliverable-based outcomes. 60–90 days for capability or threshold-based outcomes. The timeframe is set by the mechanism’s design: how long does the program or accountability structure run before the deliverable is due? The timeframe must match the program structure exactly — if the program is 8 weeks, the outcome timeframe is 8 weeks, not 6 weeks (shorter produces anxiety about the deadline) and not 12 weeks (longer is not credible as the mechanism produces the outcome faster than that). | The member can check whether they completed the deliverable or crossed the threshold on the specific date the program ends. The falsifiability test fails if the deliverable is subjectively defined (“a polished newsletter” is subjective; “a newsletter with 500 subscribers and a 4-week backlog of scheduled posts” is objective), if the threshold requires external validation the member does not control (“get accepted to a program” depends on the program’s decision, not the member’s work), or if the completion criteria are set by the member rather than the community structure. | “Paid newsletter writers who have been publishing for 12–36 months and have not yet crossed 1,000 subscribers launch their first paid referral program within 60 days of completing the 8-week cohort — and the cohort’s peer review process produces a referral program structure that gets them to their first 50 referred subscribers before the cohort ends.” |
| Acquisition-focused (network or deal-flow community where the primary value is specific introductions or opportunities that the operator curates and routes to members based on their stated goals and stage) | Operators or founders at a specific stage who are actively working on a specific type of goal that requires a specific type of connection. The stage descriptor must be precise enough that the operator can verify whether an applicant is in the right stage before granting access: if anyone at any stage of fundraising or sales could say the stage descriptor applies to them, the outcome statement will attract wrong-stage prospects and produce poor reviews from members who joined at the wrong stage and did not get relevant introductions. | Number of relevant introductions or opportunities surfaced in the first 30 days. The metric must be within the operator’s control (the operator curates and routes introductions) and must be specific enough to count (not “warm intros” as a vague concept but “introductions to [specific type of investor, operator, or partner] who [specific qualification that makes them relevant to this stage]”). The metric cannot be the downstream result of the introduction (whether the introduction converts to a deal or investment), because that is outside the operator’s control. | 30 days. Network communities produce introductions in the near term or not at all — a 90-day timeframe for a network introduction is not credible because the mechanism is event-based (the operator makes the introduction when a relevant match exists in the current membership) and does not require 90 days to operate. A 30-day timeframe is short enough to be action-forcing and long enough for the operator to source and route the relevant introductions. | The member can count the number of introductions they received in their first 30 days and check whether each introduction met the specificity criteria stated in the outcome statement. The falsifiability test fails if the introduction quality is subjectively assessed by the member (“warm and relevant” is subjective), if the number promised is conditional on factors the member controls (“up to 5 introductions depending on your availability” shifts responsibility to the member), or if the stage descriptor is broad enough that wrong-stage members can meet the criteria and then reasonably claim the introductions were not relevant. | “Founders actively raising a Seed round with an existing product and 3+ months of user data receive an average of four warm introductions to angels or pre-Seed funds who have invested in the relevant sector in the past 18 months, in their first 30 days. Introductions are initiated by the operator after a 20-minute intake call — you do not cold-message other members.” |
The most common error in outcome statement writing is confusing the archetype. A skills community (activation-focused) often writes an outcome statement that sounds like a network community (acquisition-focused) because the operator believes that the introductions members make through the community are the primary value. But if the community’s mechanism is structured peer critique, not curated operator-routed introductions, then the introductions are a side effect, not the mechanism — and an outcome statement that promises introductions on a network community schedule will not be delivered by a skills community structure. Match the outcome statement to the mechanism that actually produces it. See paid community value proposition for the framework for identifying which mechanism your community’s value proposition is built on before writing the outcome statement.
Table 3 — Access-structure description components
The five components that the access-structure description must contain to answer the prospect’s question “will the specific people in this community be relevant to my situation, and what will my first month actually look like?” Each component addresses a different sub-question the prospect is running. Missing any one component produces a description that is persuasive in general but fails to provide the specific information the prospect needs to make a confident purchase decision. The “poor example” and “good example” columns show the structural difference — the difference is usually specificity at the stage level, not copywriting quality.
| Component | What to include | What to avoid | Poor example | Good example |
|---|---|---|---|---|
| 1. Peer group descriptor | The member count in the relevant stage segment (not total community membership), the career or business stage range of members in that segment (not the aspirational stage they are working toward), and one or two specifics about what they are working on now that would be recognizable to the right prospect. The peer group descriptor is answering: “are there people like me in here — specifically, people at the same stage doing the same kind of work I am doing right now?” | Total member count presented without a stage breakdown. Descriptions of member backgrounds that emphasize where members have been (“formerly at Google, Stripe, and Notion”) rather than what stage they are working at now. Member counts that include all tiers of membership if different tiers have meaningfully different stages. Stage language that is too aspirational to be credible as a current description (“some of the most successful community operators in the world”). | “Over 300 community operators from around the world, including operators from some of the fastest-growing communities in the industry.” | “87 paid community operators actively running communities with 100–800 paying members in the SaaS, creator, and professional-development categories. Most are solo operators or two-person teams; 60% crossed 100 members in the past 18 months and are working on the month-two retention problem.” |
| 2. Format of interaction | The primary mechanism for peer exchange: whether it is async (thread-based discussion in Slack), synchronous (live calls, office hours, or workshops), structured cohort (a fixed group of 10–15 working through a defined program), or a combination. The format description must include the frequency (how often does the primary interaction format run) and the structure (what does a typical interaction look like, and what is the prospect’s role in it). The format is answering: “how does the community actually work, and what would I be doing in a typical week?” | Listing all the formats the community offers without indicating which is the primary one. Format descriptions that are accurate but do not indicate participation expectation (“weekly live calls” does not tell the prospect whether the calls are attend-or-watch-replay, whether they involve prepared presentations or open discussion, or whether participation is expected or optional). Any format description that requires the prospect to infer how the community works rather than stating it directly. | “Weekly live calls, an active Slack community, and a library of resources including recordings of all past sessions.” | “The primary format is a weekly 60-minute async thread prompt posted Monday mornings — every member responds with their current situation in three sentences, and the thread generates 30–50 peer replies by end of week. One live call per month, attendance optional, recordings indexed by topic. You participate at your own pace; most active members spend 20–30 minutes per week.” |
| 3. First-30-days action sequence | The named actions a new member takes in their first 30 days, stated as a specific sequence (not a list of options). The sequence should answer: what happens on day 0 (the first DM or welcome sequence), what the member is expected to have done by the end of week one (an intro post, a stated goal, a channel subscription), what the week-two touchpoint is (the conditional nudge or async challenge), and what the first-month milestone is (the specific thing the member should have done or received by day 30 that marks a successful first month). The action sequence is answering: “do I know exactly what I would be doing if I joined, and can I decide whether I want to do those things?” | A first-30-days description that uses event language rather than action language (“you’ll be welcomed by the community and have access to all our resources” is event language; “you post a three-sentence intro in #introductions naming your community size, your current retention rate, and the one thing you are trying to fix this quarter” is action language). A first-month description that is conditional on whether other members respond to the new member (the prospect needs to know what they will do, not what they hope will happen). Any description that would be consistent with any member getting any experience depending on how active they are. | “When you join, you’ll be welcomed into the community and can start engaging with other members immediately. There’s a lot of great content to explore and plenty of members who are happy to connect.” | “Day 0: a DM from the operator with a 3-step checklist (post your intro in #introductions with your community size, current activation rate, and one fix you are working on this quarter). Day 3: if you haven’t posted yet, a one-question nudge: ‘what’s the one thing holding you back from posting your intro?’ Week 2: an async challenge prompt matched to the fix you named in your intro. Day 30: a short check-in from the operator asking whether you received peer input on your challenge — if you did not, they introduce you to three members who are working on the same fix.” |
| 4. Body of knowledge descriptor | The accumulated resource the community has built that the prospect cannot build alone. This should specify: the type of resource (AMA archive, playbook library, deal-flow log, swipe file), the volume (approximate number of items or hours of material), the stage-specificity of the content (whether the resource is specifically relevant to the prospect’s stage or covers a broader range), and the specific thing a new member can do on day 1 with the existing resource base that they could not do before joining. The body of knowledge is answering: “what is already in here that I can use immediately, before I have built any peer relationships?” | Body of knowledge descriptions that are accurate but do not indicate stage-relevance (“200+ resources” tells the prospect nothing about whether any of the 200 resources are relevant to their stage and situation). A resource library described in platform terms (“a searchable knowledge base”) rather than content terms (“47 playbooks written by operators who crossed the 200-member threshold in the past 24 months”). Any body of knowledge description that requires the prospect to explore the resource base before they can assess its relevance — because a prospect cannot explore the resource base before joining, and the description must proxy for that exploration. | “Access to our full resource library, including recordings of all our past calls and a collection of templates shared by community members.” | “38 playbooks written by members who solved specific retention problems (each one names the community’s size, the specific problem, the intervention, and the outcome at 90 days). 14 AMA session recordings with operators who crossed 300 paying members, indexed by the retention question each operator was working on at the time of the call. A Day 3 audit template used by 22 operators in this community — the most-downloaded resource, with a 90-day churn reduction average of 3.2 percentage points among the operators who reported back.” |
| 5. First-month success condition | The operator’s stated definition of a successful first month: the specific thing the member should be able to say they have done or received by day 30 that demonstrates the membership is delivering on the core promise. The first-month success condition is the internal commitment the operator is making to the new member about what will happen, stated explicitly so the prospect can evaluate whether they want that specific outcome from their first month. It is also the basis for the risk reduction element in Table 1: the defined-criteria evaluation offer is the first-month success condition with a refund attached. | A first-month success condition that is defined by member effort rather than operator delivery (“you will have made meaningful connections if you show up actively” is member-effort-dependent; “you will have received direct peer input on the specific challenge you named in your intro post” is operator-delivery-dependent in the sense that the operator has committed to making it happen). A success condition that is too aspirational to be plausible in 30 days (transformation language: “you will see your community with new eyes”). A success condition that is not specific enough to be checkable (you can’t determine whether “meaningful connections” happened; you can determine whether a specific peer introduced you to their playbook for reducing month-two churn). | “By the end of your first month, you should feel like a valued member of the community and have found at least one thing that was worth the cost of membership.” | “By day 30, you will have: (1) received direct peer input from at least two members who have solved the specific retention problem you named in your intro post; (2) reviewed at least one playbook from the library that is specifically relevant to your community’s size bracket; and (3) participated in at least one weekly async thread prompt. If you have not met all three conditions by day 30, contact us and we will personally introduce you to the three most relevant members for your situation — or refund your first month.” |
The five components of the access-structure description are the foundation for the risk reduction offer. An operator who has written a clear first-month success condition (component 5) already has the evaluation criteria they need for a defined-criteria evaluation offer. An operator who cannot write a specific first-month success condition cannot write a credible defined-criteria evaluation offer — because the criteria are vague in both cases. Write component 5 before writing the risk reduction copy; the risk reduction offer is the success condition with a refund attached.
Table 4 — Risk reduction selection
Three risk reduction structures appropriate for different paid community models. The selection criteria are community model (what the community’s primary mechanism is and whether intake is cohort-based or always-open), conversion rate range for qualified traffic (prospects who have engaged with the outcome statement and access-structure description and are in the decision stage), and the conditions required to offer the structure without adverse-selection risk (the risk that the structure attracts members who intend to consume and cancel regardless of quality). The specific language pattern column provides the sentence structure to follow when writing the copy — fill in the brackets with the specific numbers and criteria for your community.
| Structure | When to use (community model) | Conversion rate range for qualified traffic | Required conditions to offer without adverse-selection risk | Specific language pattern |
|---|---|---|---|---|
| Defined-criteria evaluation | Always-open communities (non-cohort intake, members can join at any time) where the community’s primary mechanism produces a specific, operator-controlled outcome in a defined window of 30 or 60 days. The community must be able to commit to the evaluation criteria with reasonable confidence: if the outcome depends heavily on which other members happen to be active in a given month, the criteria will be inconsistently met and the refund rate will be unpredictable. Best for communities where the operator has a structured first-month experience (a Day 0, Day 3, Day 7 onboarding sequence) that produces the evaluation criteria reliably across new-member cohorts. | 25–40% conversion from qualified prospects in the decision stage (prospects who have read the outcome statement and access-structure description and are evaluating whether to commit). Compares to 2–8% for generic money-back guarantees or no risk reduction offer. The conversion uplift is highest when the evaluation criteria are specific and operator-controlled, lowest when the criteria are vague or member-effort-dependent. | Two conditions required. First, the evaluation criteria must be specific enough that the operator can distinguish between a member who did not meet them (because the community did not deliver) and a member who did not meet them (because the member did not participate in the structured first-month experience). Generic criteria (“if you don’t find value”) cannot make this distinction and will produce refund requests from members who joined and did not engage with the onboarding sequence. Second, the operator must have a refund policy in their billing system that they can honor without dispute: if the billing platform does not support first-month refunds, the offer cannot be delivered. | “If by the end of your first [30/60] days you have not received [specific criterion 1: e.g., direct peer input from at least two members on the specific challenge you named in your intro post] and [specific criterion 2: e.g., reviewed at least one playbook from the library relevant to your community size], we will refund your first month’s membership in full, no questions asked. Email us at [address] within 5 days of the end of your evaluation period.” |
| Cohort deadline | Cohort-based communities (intake happens on specific dates, members join a defined cohort of 10–20 people who move through the program together) where the natural intake structure creates a real deadline. The next cohort starts on a specific date, intake closes before that date, and a prospect who misses the deadline must wait for the next cohort. The mechanism is that deferred intent (“I might join later”) has a real cost: missing this cohort means waiting for the next one, which may be 4–8 weeks away, and the prospect who is already working on the problem now will be further along (or further stuck) by then. | 40–60% conversion lift on fence-sitters (prospects who have expressed interest but not committed) within the 7-day window before the cohort deadline, compared to the conversion rate for the same prospect segment more than 7 days from the deadline. The lift is driven by the deadline being real, not manufactured — which means the prospect who has verified that the deadline is real (by checking whether prior cohorts actually closed) converts at the higher rate, while the prospect who suspects the deadline is manufactured does not. | One required condition: the deadline must be real. A manufactured deadline (“this cohort closes at midnight on Friday” that reopens Monday morning with a new cohort) converts at the generic rate on repeat visits once prospects discover the rolling cycle. The adverse-selection risk for a cohort deadline structure is not a member profile problem (cohort members self-select for the right stage because the cohort program has defined prerequisites) — it is a credibility problem. An operator who manufactures deadlines trains their audience not to trust their pricing page, which reduces conversion on all subsequent cohorts, not just the one where the deadline was discovered to be fake. | “The [cohort name or number] cohort starts [specific date]. Intake closes [specific date, typically 3–7 days before start]. The next cohort opens [specific date, typically 6–8 weeks later]. If you are working on [the problem the cohort addresses] now, waiting for the next cohort means [specific cost: e.g., 6 more weeks with the retention problem you named, plus missing the peer group who will be working on exactly this stage in the same period]. [CTA button: Reserve your spot before [intake-close date].” |
| Value-before-commitment | Communities where the prospect’s primary purchase barrier is the question “will the specific people in this community be relevant to my situation?” — a question that the pricing page description alone cannot answer because the prospect has not yet interacted with the membership. Appropriate when the community’s ICP is narrow enough that stage-relevance is a real variable (some prospects will be a strong fit for the current membership; others will not) and when the operator can offer a curated pre-purchase interaction (a single call, a 48-hour Slack preview with specific active members, or a recorded AMA from the most relevant cohort) that answers the relevance question directly before payment. | 15–25% conversion from prospects who participate in the pre-commitment event to paid membership. Lower than defined-criteria evaluation because the conversion happens after an additional step (the pre-commitment event) rather than at the pricing page itself — but the absolute conversion rate on the pre-commitment event participants is typically higher than on qualified pricing-page visitors who are offered no risk reduction, because the event answers the relevance question that the pricing page cannot. Appropriate when the CAC of a non-converting qualified prospect is high enough that the pre-commitment event is worth the operator’s time per prospect. | Two conditions required. First, the pre-commitment event must be curated: a public preview open to all current members will not answer the “will these specific people be relevant?” question if the participants are not representative of the community’s core active membership. The operator must select which members participate in the preview to ensure that the prospect sees the membership at its most relevant for their stage. Second, the event must not deliver the community’s full value in one session: a single curated AMA that answers every question the prospect has removes their reason to join. The event should demonstrate that the community has what the prospect needs without delivering all of it upfront. | “Before you decide, [choose one]: (A) Join us for a 45-minute session with [2–3 member names and their stage descriptors] who are working on [the same problem the prospect named]. No sales pitch — just a conversation about what they have found that works. [Date/time + RSVP link]. OR (B) Watch the recording of [specific AMA or session] with [member name] who crossed [the specific threshold the prospect is working toward] in [timeframe]. [Link.] After either, if you want to join, the door is open. If not, you have still gotten something useful.” |
The selection between defined-criteria evaluation and cohort deadline is determined by whether your community has a fixed intake structure, not by which conversion rate looks higher. An always-open community that manufactures a cohort deadline produces the adverse-selection and credibility risks described in row 2 without the structural benefit (the deadline is only conversion-forcing when it is real). An operator with an always-open community who sees the cohort deadline conversion rate and tries to replicate it by creating artificial scarcity will typically see lower conversion within two or three cycles once the audience learns the pattern. Select the structure that matches your community’s actual intake model.
Table 5 — Pricing page failure mode diagnosis
Three failure modes that produce low conversion on paid community pricing pages, each with a distinct pattern on the page and a distinct internal monologue for the prospect. The prospect-legibility test identifies which failure mode is operative faster than conversion rate analysis: five readers who match your ICP description, one question after reading the page (“can you tell me specifically what you would be buying and whether it applies to your situation?”), and the pattern in their answers maps directly to one of the three failure modes below. Run the test before changing any copy; the wrong fix for the wrong failure mode does not improve conversion and may reduce it. The “specific element to fix first” column identifies which element from Table 1 is the highest-leverage change for each failure mode.
| Failure mode | What it looks like on the page | The prospect’s internal monologue | Signal from prospect-legibility test | Specific element to fix first |
|---|---|---|---|---|
| Features-first | The pricing page leads with a feature list or platform description: number of calls per month, channel count, types of content available, platform capabilities (searchable library, Zapier integrations, mobile app). The outcome statement, if present, appears after the feature list or is embedded in it as one item in a bulleted list of benefits. The page answers “what is in this community?” accurately and in detail, but does not answer “what result will I get and does it apply to my situation?” before asking the prospect to evaluate the features. | “I can see what’s in here. There’s a lot of stuff. But I can’t tell if any of it is specifically for someone at my stage doing what I’m trying to do right now. It looks like it could be for anyone. Let me think about it more before paying $150 a month.” The “let me think about it more” response is the conversion failure — the prospect is not opposed to the community, they are just not yet convinced it applies to them, and they do not have enough specific information to convince themselves. | The reader can accurately describe what the community includes (number of sessions, types of content, platform features) but cannot answer whether the community is designed for their specific stage. When asked “is this for someone at your stage?” they say “I think so? But I’m not sure. It seems like it might be for people who are a bit further along, or maybe earlier.” The stage ambiguity is the signal: the page did not filter for the right prospect, so the right prospect does not know whether they are the right prospect. | Fix outcome specificity first (Table 1, element 1). Reorder the page to lead with the outcome statement rather than the feature list. The feature list can remain, but should appear after the outcome statement and access-structure description, positioned as evidence for the outcome claim rather than the claim itself. Do not remove the feature list: some prospects at the decision stage use the feature list to confirm that the community has the specific capabilities they need. Move it, don’t delete it. See paid community value proposition for the framework that produces the outcome statement before the feature list is written. |
| Outcomes-without-proof | The pricing page has an outcome statement, but the statement is generic: aspirational language that is true of many communities and does not give the prospect a basis for evaluating whether the claim is credible for their situation. Common forms: “grow your community,” “accelerate your growth,” “connect with the best operators in the space,” “become the operator you want to be.” The outcome is identifiable (unlike the features-first failure mode, the prospect can see that the page is making an outcome claim) but unverifiable (the prospect has no basis for distinguishing this community’s outcome claim from any other community making a similar claim). Often accompanied by testimonial quotes that use the same generic language (“this community changed my business”) without the specificity that would make the testimonial credible as evidence. | “That’s what I want. But everyone says that. I’ve joined three communities in the past two years that all promised basically the same thing. How do I know this one is different? I’d need to see something more specific before I pay $200 a month.” The “I’ve seen this before” response is the conversion failure — the prospect is in the right category but cannot distinguish this community from prior experiences that did not deliver on similar promises. | The reader recognizes the outcome language as something they want but when asked “can you tell whether this community would produce that result for you specifically?” they say “No — it sounds right, but I have no way to tell whether this is real. It’s the same language every community uses.” The “same language every community uses” signal indicates that the outcome claim has the right category but fails the falsifiability test: it could be true of any community in the space, which means it is not evidence of anything specific about this community. | Fix the outcome specificity content (Table 1, element 1 and Table 2). The structural fix is to replace the generic outcome statement with a specific member result: one operator who was at the stage descriptor, joined, did the specific thing the community facilitated, and reached the metric at the timeframe. One specific example that passes the falsifiability test (“Sarah, at 200 members with a 22% 90-day churn rate, reduced that rate to 9% within 90 days of implementing the Day 3 conditional nudge her cohort designed”) is more credible than five generic claims. See paid community member acquisition for the member story collection process that produces the specific examples needed to replace generic outcome language. |
| Risk-without-specificity | The pricing page has an outcome statement (possibly specific) and an access-structure description (possibly complete) but the risk reduction element is generic: “cancel anytime,” “30-day money-back guarantee,” “no long-term commitment,” or no risk reduction element at all. The prospect understands what the community is and believes it may apply to their situation, but the decision they face is still: “pay $150 a month and hope it works out.” Generic risk reduction language does not reduce the perceived cost of being wrong because it does not specify what “wrong” would look like or what the prospect can recover if it happens. “Cancel anytime” is true of every subscription; it does not tell the prospect anything about what happens if they pay for a month and the community does not deliver on the specific promise of the outcome statement. | “I get it. I think this might be what I need. But $150 a month is not nothing. What if I pay and it doesn’t turn out to be as relevant as it looks? Cancel anytime doesn’t help me — I’m still out $150. I want to join but I need to be more sure before I commit.” The “I want to join but” response is the closest prospect to conversion among the three failure modes: this prospect has passed the outcome-specificity and access-structure tests and is stuck only at the commitment threshold. A specific risk reduction offer converts this prospect; generic risk reduction language does not. | The reader says “I think I would join if I knew what would happen if it didn’t work out for me.” When asked what would make the commitment feel right, they describe something like a defined evaluation period or a specific criterion for success — which is precisely what a defined-criteria evaluation offer provides. The reader is telling you what risk reduction structure would work for them; the page is not providing it. The signal is “I want to but” rather than “I’m not sure” (features-first) or “I’ve seen this before” (outcomes-without-proof). | Fix the risk reduction element (Table 1, element 3, and select from Table 4). Rewrite the risk reduction copy using the defined-criteria evaluation structure if the community is always-open: name the evaluation period, the specific criteria that constitute success, and the specific refund available if the criteria are not met. The first-month success condition from Table 3 component 5 provides the evaluation criteria — the risk reduction sentence is the success condition with a refund attached. Do not add the risk reduction offer in isolation without first confirming that the outcome specificity and access-structure elements are complete; risk reduction on a page that still has the features-first or outcomes-without-proof failure mode will produce higher trial signups with the same or lower conversion to long-term membership. See Foothold community health check for the Day 0, Day 3, and Day 7 onboarding sequence that produces the structured first-month experience required for a credible defined-criteria evaluation offer. |
The prospect-legibility test consistently surfaces one of these three failure modes when conversion is below expected rates. The test works because it surfaces the operative failure mode at the decision stage where it matters, not in a post-hoc survey. Five readers is the minimum for a valid test; below five, a single reader’s response can skew the pattern. Above ten, the pattern stops changing materially. Five to seven readers who match the ICP stage descriptor produces a clear signal in under two hours, which is faster and more actionable than waiting for another 100 visits of conversion rate data.
Frequently asked questions
What should a paid community pricing page include?
A paid community pricing page needs three elements in a specific sequence: outcome specificity, access-structure framing, and risk reduction. Outcome specificity is a single, falsifiable, stage-specific result the right prospect recognizes as exactly their situation. Access-structure framing describes what the price buys in terms of specific people, interaction format, first-30-days action sequence, and body of knowledge — not a feature list. Risk reduction addresses the prospect’s residual concern about what happens if the community does not deliver, with one of three structures: defined-criteria evaluation (for always-open communities), cohort deadline (for cohort-based communities), or value-before-commitment (for communities where the prospect’s primary question is whether the specific members are relevant). The sequence matters: a prospect who cannot identify whether the outcome applies to them will not read the access-structure description, and a prospect who understands the outcome and access structure but perceives the commitment as irrecoverable will defer. Table 1 in this reference card covers all three elements with what each must include to work, what the failure version looks like, and the specific question each element answers. For the strategic reasoning behind the three-element structure, see the companion post: Paid community pricing page: the three elements that convert.
How do you write pricing copy that converts for a paid community?
The outcome statement for the first element follows this formula: [member stage descriptor] who [specific situation description] will [specific metric outcome] within [credible timeframe]. The stage descriptor must match exactly the stage the prospect is at now, not the stage the community’s most successful members are at. The metric must be specific enough to fail the falsifiability test: “grow your community” does not pass; “reduce 90-day churn rate to below 10%” does. The timeframe must match the community’s mechanism. For the access-structure description, name five things: the peer group with member count and stage range, the primary interaction format and frequency, the first-30-days action sequence, the body of knowledge and what a new member can use on day 1, and the first-month success condition the operator will commit to. For risk reduction, the defined-criteria evaluation sentence names the evaluation period, the specific criteria, and the specific relief available. Table 2 provides the outcome specificity template for three community archetypes (retention-focused, activation-focused, and acquisition-focused) with the right metric and timeframe for each. Table 3 provides the five access-structure components with poor-vs-good examples for each. Use both tables together when rewriting pricing copy from scratch.
What is the best trial offer structure for a paid community?
The best risk reduction structure depends on the community model. Defined-criteria evaluation is appropriate for always-open communities: “if by the end of your first 30 days you have not received [specific criteria], we will refund your first month.” This structure converts 25–40% of qualified prospects in the decision stage, versus 2–8% for generic money-back guarantees, when the criteria are specific and operator-controlled. The required condition is that the evaluation criteria are specific enough that a member who did not engage with the onboarding sequence is distinguishable from a member who engaged and did not receive the promised outcome. Cohort deadline is appropriate for cohort-based communities where the next cohort starts on a specific date: the deadline is real, not manufactured, and the conversion lift of 40–60% on fence-sitters within the 7-day deadline window depends entirely on the deadline being verifiable as real. Value-before-commitment is appropriate for communities where stage-relevance is the primary purchase barrier: a curated pre-purchase interaction that answers “will the specific people in this community be relevant to my situation?” produces 15–25% conversion from event participant to paid member. Table 4 in this reference card covers all three structures with the specific language pattern for each. See paid community pricing tiers for the three-tier pricing model that sets the price points the risk reduction offer is attached to.
How do you diagnose why a paid community pricing page is not converting?
The prospect-legibility test identifies the operative failure mode faster than conversion rate analysis: find five readers who match your ICP stage descriptor, have them read the pricing page, then ask one question: “Can you tell me specifically what you would be buying and whether it applies to your situation?” Three distinct answer patterns map to three failure modes. Features-first failure: the reader can describe what is in the community but cannot connect any feature to an outcome that applies to their stage — the page did not filter for the right prospect. Fix: reorder to lead with the outcome statement. Outcomes-without-proof failure: the reader recognizes the outcome language as what they want but cannot assess whether the claim is credible for their situation — the outcome statement is generic and passes no falsifiability test. Fix: replace generic outcome language with one specific member result that names the member’s stage, the metric that changed, and the timeframe. Risk-without-specificity failure: the reader is interested and believes the outcome applies to them but says “I want to but I need to be more sure before I commit” — the risk reduction element is missing or generic. Fix: add a defined-criteria evaluation sentence that names the evaluation period, the specific criteria, and the refund available. Run the test before changing any copy: the wrong fix for the wrong failure mode does not improve conversion. Table 5 in this reference card covers all three failure modes with the specific legibility-test signal for each and the element to fix first.