Give every tier a clear promise
Design paid tiers around differences a reader can explain: what they receive, what they do themselves, how much support they get, and how long the offer lasts. Add a tier only when it serves a different need or creates a different delivery obligation. A more impressive name is not a meaningful distinction.
For an author selling an applied version of a book's method, this usually means starting with one complete offer. A second option might add a genuinely different service, such as a bounded review of the reader's work. It should not be necessary to buy the expensive option to discover that the inexpensive one cannot perform its advertised task.
The worksheet below turns a benefits list into a clear purchase description. It also helps you see which promises would bring you back into the consulting business you may be trying to leave.
Write the reader's decision before choosing tier names
Imagine a reader asking: “Can I use this on my own, or do I need someone to review my attempt?” That is a useful distinction. “Am I Basic, Pro, or Elite?” tells you much less about the work.
Name the choice in ordinary language first. For example, a self-guided companion and a companion with one written review describe two different delivery arrangements. You can add brand names later, provided the explanation stays visible.
You do not need three options because a pricing-page template has three columns. Patreon's own membership guidance recommends starting with one tier for simplicity, then refining the offer as additional needs emerge. That is platform guidance, not evidence that one tier will maximize your revenue. Patreon membership guidance.
For an established nonfiction author, the relevant question is whether another tier would make the offer clearer or merely create another promise to maintain.
Compare two fictional designs
Consider Sophie, a fictional author whose book teaches managers to write useful project retrospectives. Her companion helps a manager turn notes about a completed project into a draft retrospective: observations, contributing conditions, open questions, and proposed follow-up actions. The manager remains responsible for checking the account with the team.
Here is a vague first design:
| Basic | Pro | Elite |
|---|---|---|
| Essential insights | Advanced insights | Transformational insights |
| Standard experience | Premium experience | VIP experience |
| Community support | Priority support | Direct author access |
The problem is not the vocabulary alone. Sophie has not decided what she owes a buyer. Does “advanced” mean more examples, a different workflow, or a better result? Does “direct access” mean one email or ongoing consulting? Is “priority” a response time or just an aspiration?
A clearer second design has two offers:
| Purchase detail | Self-guided retrospective companion | Companion plus one written review |
|---|---|---|
| Suitable reader | Manager who can check and revise a draft independently | Manager who wants Sophie to review one completed draft |
| Main deliverable | Guided draft using the book's method, with an example and checklist | Same companion, plus one written review of a draft up to 1,500 words |
| Reader inputs | Project purpose, timeline, observations, constraints, unresolved questions | Same inputs, plus the completed draft for review |
| Duration | Hypothetical 60-day access period | Same period; submit the review request within the first 30 days |
| Product help | Help with access and using the published workflow | Same product help |
| Author service | No personal review or consultation | One written review within five business days of a complete submission |
| Exclusions | No interviews with team members, investigation, or judgment about individual performance | Same exclusions; no meeting, rewrite, or second review |
Every term here is illustrative. These are not Skillfully prices, capabilities, or service commitments. Before selling this design, Sophie would need to confirm that her chosen delivery arrangement can support it and that she can honor the review timetable.
The improved table makes a real choice visible. It also reveals that the second tier includes a service business. If Sophie wants no additional client work, she should remove that tier rather than hide the labor behind “VIP.”
Use an offer contract to expose missing decisions
“Offer contract” here means a plain-language editorial worksheet, not a substitute for legal terms. Complete the following three columns for every benefit you plan to advertise.
| Promise readers see | What you will actually deliver | Boundary readers need before purchase |
|---|---|---|
| Apply my retrospective method | Guide readers through a draft based on their supplied observations | Cannot establish facts absent from those observations |
| Worked examples | Three completed examples covering specified project types | Does not include an example for every industry |
| Product support | Help locating materials and following the published workflow | Does not include personal advice about the team's dispute |
| Written review | One review of one eligible draft | Word limit, submission window, response time, and revision limit |
| Updates | The specific corrections or additions you commit to during the access period | No promise of indefinite new content unless that is truly the offer |
The third column often contains the most valuable work. It identifies assumptions that might otherwise become support requests after purchase.
A boundary should clarify the offer, not retract the headline. “Get a completed retrospective” cannot be rescued by tiny print saying that the product provides only questions. Rewrite the headline to match the actual deliverable.
Separate product help from personal application help
Authors often use “support” to cover three different things: access problems, questions about using the product, and advice about a buyer's situation. Each requires different effort and expertise.
Write them separately. An author can reasonably offer product help without offering unlimited case discussion. A reader should be able to discover that distinction before paying, without decoding a phrase such as “standard support.”
For Sophie's companion, product help might explain where the completed example is. Personal application help might involve a dispute about whether a team member caused the project's failure. The latter is outside the hypothetical offer even if the customer asks through the same inbox.
If you include a response-time promise, define when the clock starts and what counts as a response. “Within five business days of a complete submission” is clearer than “priority.” It still requires an operational plan: someone must check submissions, request missing material, and handle absences.
Do not publish response times that exist only in your intentions. Start with the service you can consistently deliver, then describe it accurately.
Count the work created by each tier
A creator asking about a third Patreon tier wrote: “And now that I look at it, I'm wondering whether I even need the third tier and should just keep it at $5 and $10.” The surrounding post describes concern about the labor attached to premium benefits. This is one creator's account, not a pricing benchmark for authors. Original post by u/EHypnoThrowWay.
For each proposed benefit, record whether delivery happens once, periodically, or separately for every buyer. Then ask what happens if purchases arrive together.
In Sophie's fictional review offer, six submissions requiring 40 minutes each create four hours of review work before administration. That is arithmetic under an assumption, not a measured delivery time. If she has only two hours available that week, the offer needs a smaller capacity, a longer promised turnaround, or removal of the review service.
Do not use a capacity limit as decoration. If you say there are six review places, there should be a real reason you can deliver six and a process for closing that option. A self-guided product does not acquire legitimate scarcity merely because another tier contains manual work.
Make benefits visible before the buying decision
One prospective Patreon member explained their frustration plainly: “I'd like to know how much I want to pay for the benefits they give before actually paying”. Their post concerned trouble viewing a creator's tier page; replies suggested an error. It should not be treated as a statement about how Patreon currently works. The useful point is the buyer's desire to compare benefits before paying. Original post by u/Kaincee.
Your offer page should answer the purchase questions together: deliverables, exclusions, payment frequency, access duration, and any separate service. Avoid making readers assemble the answer from a sales email, a checkout note, and a support article.
Keep wording consistent wherever the offer appears. If the comparison table says “one written review,” the checkout should not say “author coaching.” Those phrases invite different expectations even if you intended them to describe the same item.
Check the design with three reader scenarios
Before publishing, walk through cases that put pressure on the boundaries. This is an editorial check, not a reported user test.
- The independent reader: Can they buy the self-guided option and complete the advertised task without discovering that a required step belongs to another tier?
- The reader seeking judgment: Can they tell whether the author will examine their specific work, what they must submit, and what the response includes?
- The reader with an unsuitable case: Can they recognize that the product does not investigate disputes, certify accuracy, or replace a different kind of professional help?
Ask a prospective reader to explain the offer in their own words if you have the opportunity. Do not ask merely whether the page looks clear. A mistaken explanation identifies something concrete to revise.
The underlying workflow also needs to perform as described. Use the separate guide to testing an agent skill to examine whether realistic inputs produce acceptable outputs. A clear comparison table cannot compensate for a product that fails its basic task.
Choose the smallest complete structure
Keep the core offer complete. Add another tier when it serves a distinct reader need, has a defensible boundary, and fits the business you want to run. Remove a tier when you cannot explain its difference without status language or an expanding list of obligations.
For an author who wants readers to apply a method without booking more consulting, a single well-defined companion can be a coherent starting point. A service tier is optional, not the inevitable destination of every buyer.
When your offer worksheet is clear, visit Skillfully and choose Book onboarding. Bring the table, one example of the reader's task, and the obligations you intend to retain. That makes it possible to discuss the product around an actual reader promise.