Design paid tiers from benefit cost and delivery capacity

Start with the reader's job, then price the obligation

A paid tier is a bundle of recurring promises. Name the reader's job first: stay current, make a decision, learn a practice, or support the publication. Then list each benefit and the publisher action required to deliver it. Archive access has a different cost shape from a monthly office hour; a private briefing has a different capacity limit from a reusable report. This guide treats tier design as capacity planning, not as a claim that more choices increase conversion.

Keep the entry tier coherent enough to stand alone. Add a higher tier only when it serves a distinct job or funds a visibly different service. Ghost's current tier documentation confirms that its tiers can have separate monthly and yearly prices, benefits, and content access, and that an archived tier can keep renewing existing members. Those are platform capabilities, not evidence that any particular benefit mix or number of tiers will sell.

Source notes: Create paid tiers

Cost benefits in the unit they consume

Create one row per benefit. Mark fixed production hours, marginal cash cost per member, marginal support minutes, maximum participants, cadence, and failure consequence. Value staff time at an internal planning rate even when the owner is not drawing that wage. Shared editorial work may be assigned across all paying members; live access and personal review should be assigned only to the tier consuming them.

Hypothetical planning example: a specialist briefing requires six hours each month at a $50 internal rate, or $300 fixed cost. Member support averages four minutes at the same rate: $50 × 4 ÷ 60, or $3.3333 per member before rounding. At 80 members, modeled monthly delivery cost is $566.67 before payment processing, tax work, refunds, and platform cost. At a hypothetical $12 price, $960 gross leaves $393.33 before those omitted items. This is arithmetic for testing the offer, not observed margin or a price recommendation.

Replace every hypothetical input with the publisher's own labor, cost, and capacity evidence.

Make the entitlement map unambiguous

For every tier, record which posts, newsletters, downloads, events, and support channels it unlocks; who can grant exceptions; and what happens after downgrade, cancellation, refund, or an archived plan. Avoid benefits such as 'priority access' unless priority has a measurable queue rule. Avoid unlimited benefits whose marginal cost is not actually negligible. If a benefit depends on one person, record vacation and absence coverage before selling it as recurring.

Write the entitlement map separately from marketing copy. Test it using four accounts: new monthly, new annual, downgraded, and lapsed. A reader should receive exactly the promised access without manual improvisation. The map also becomes the migration specification if the platform changes later.

• Name the recurring deliverable, cadence, and access boundary.
• Attach a capacity owner and limit to every scarce benefit.
• Separate supporter recognition from services that create fulfillment work.
• State what survives cancellation, including downloads already delivered.

Source notes: Create paid tiers

Launch one tier only when its worst month still fits

Stress-test the offer at low, expected, and capacity enrollment. The low case must cover any unavoidable fixed obligation or have an explicit subsidy. The capacity case must remain deliverable during the busiest editorial month. Set an enrollment cap or waitlist before a high-touch benefit reaches its limit; do not discover the limit through missed promises.

Review the tier after two full delivery cycles using benefit use, support time, refunds, cancellations, and contribution after labor. Remove a benefit when it creates recurring cost without reader value, but communicate any promise change to affected members. The decision is whether this benefit bundle can be delivered reliably, not whether the tier page looks competitive.