LESSON 05 / 14 · FREE BUSINESS COURSE
Plans turn your service into a decision customers can understand. A useful plan describes the work it supports, what is included, and when a customer needs more. It also sets boundaries that let you deliver the promise sustainably.
By the end: create a short plan matrix, explain a sensible upgrade path, and test the limits that matter. Prices in this lesson are illustrative; you will examine pricing and costs in Lesson 9.
Begin with different customer situations
The original FitSite example separates solo trainers, established gyms, and multi-location businesses. Those are useful hypotheses because the work may differ: a trainer needs a clear professional presence, a busy gym may need a richer schedule and booking workflow, and a chain may need location-specific information.
Do not assume staff counts determine the right product. A solo trainer may rely heavily on online booking, while a larger gym may already have a system it wants to retain. Use interviews to identify meaningful differences in workflow, complexity, support, and scale. Plans should reflect those differences instead of stereotypes.
For another SaaS business, the dividing line might be one project versus a team workflow, occasional use versus frequent work, or one location versus several. Choose a small number of understandable situations. Three tiers are common in examples, but one good offer or two clear choices can be enough to start.
Write the promise before the feature list
For each plan, write a sentence explaining the customer’s useful outcome. Then list the features and service work required to deliver it. If you cannot explain a feature’s role in that outcome, reconsider whether it belongs in the initial offer.
A basic plan must still complete its promised job. Removing an essential feature simply to force an upgrade can make the entry plan disappointing. If a customer cannot use your “booking website” to take or direct bookings, either change the promise or include a workable booking route.
Include operational details customers need to decide: the number of sites or workspaces, relevant usage limits, custom domain availability, supported integrations, support scope, and any setup service. Explain limitations plainly. Technical quotas matter when they affect delivery, even if they should not dominate the headline.
Use the FitSite matrix as a working example
- Starter — illustrative $49/month: one studio website with the Studio Essential template, core business information, and a contact route. State clearly whether booking links and custom domains are included.
- Growth — illustrative $99/month: one website with additional template choices and a tested booking or content workflow appropriate to the buyer. Include support and integration boundaries.
- Pro — illustrative $199/month: support for an agreed multi-location arrangement, such as up to five sites, with the relevant templates and maintenance scope.
These numbers preserve the original teaching example; they are neither market benchmarks nor a pricing recommendation. You must check your costs and buyer response. Do not promise “all premium plugins” unless licensing, support, and compatibility make that deliverable. A longer feature list can increase costs without improving the customer’s result.
Be precise about allowances. If Pro includes five sites, state whether a storage quota applies per site or across the membership according to the actual configuration. A multi-location page on one site is not the same as five independent sites. Do not let the pricing table and the provisioned product describe different things.
Translate the matrix into product settings
On the optional WordPress track, Ultimate Multisite supports plans, templates, and limits. Create a product for each intended plan and configure the available template choices, supported plugins and themes, site allowances, and other relevant quotas. Consult the current documentation for the controls available in your version.
Use deliberate plugin defaults. A contact form may be part of every site, while a specialist integration belongs only where it is needed. Network-activated plugins load across the network; do not assume a plan setting can prevent that behavior. Test the actual customer experience for each tier and avoid claiming a feature is gated when it remains accessible.
Treat permissions separately from marketing. Give customers the access needed to maintain their content, and keep platform administration under your control. Test a fresh customer account on every plan rather than reviewing only from a network administrator’s view.
Keep the public comparison table and internal delivery checklist together. When a feature changes, update both before offering the revised plan. This helps avoid selling an old promise while provisioning a new configuration.
Design upgrades and downgrades before selling them
A customer should understand what changes when moving between plans. In Ultimate Multisite, review the plan-group and upgrade/downgrade settings for the installed version, then test the permitted transitions. A visual order such as Starter, Growth, Pro is only useful when the underlying transition behavior matches it.
Downgrades deserve particular attention. What happens if a customer has more sites, storage, or users than the lower plan permits? What happens to a custom domain or an integration? Define a process that preserves customer data and communicates the required changes. Do not promise automatic deletion, instant proration, or immediate refunds without confirming the intended billing behavior.
Test plan changes in a controlled payment test environment where supported. Review renewal dates, displayed prices, entitlements, and customer emails. Record anything requiring manual support so you can price and explain it honestly.
Add optional extras sparingly
The source suggests extra storage, priority support, and additional sites. These can be useful add-ons when customers understand them and you can reliably deliver them. Start with a real recurring request instead of adding checkout choices just because the software supports them.
For each add-on, define the unit, price, billing interval, cancellation behavior, and delivery responsibility. “Priority support” needs a concrete scope and response expectation; it should not imply guaranteed resolution. Additional storage needs a measurable allowance and a clear definition of whether it is shared.
Keep add-ons visibly optional and avoid preselected charges. Lesson 6 covers presenting the offer at checkout. A simple purchase decision is easier to test and support than a large collection of bundles with overlapping entitlements.
Your exercise: put the lesson to work
Create a one-page plan matrix and test checklist:
- Name your first customer segments and the outcome each plan promises.
- List required features, limits, support scope, and exclusions in plain language.
- Attach provisional prices marked “illustrative—needs validation,” plus estimated delivery costs.
- Write one upgrade and one downgrade scenario, including what happens above a lower-plan limit.
- If using WordPress, provision one test account per plan and compare the delivered experience against the matrix.
Your deliverable: an offer you can explain in a short conversation, with clear boundaries and a list of settings or billing behaviors still requiring verification.
Before you move on
- Plans should map to useful customer situations and remain viable to deliver.
- Example prices are assumptions until costs and customer evidence support them.
- Test limits, plugin availability, upgrades, and downgrades rather than relying on a pricing table.
Sources and further reading
Adapted from the original website-business lesson. Ultimate Multisite: plans, limits and plugin controls