“$49/month” is not enough information to evaluate a software offer. Is that price per person, per workspace, per location, or for a block of usage? Does an administrator count as a paid seat? What happens when consumption crosses the included amount? A prospect cannot compare plans until the billing unit is clear.
The pricing page should be a faithful explanation of the billing system, not a simplified story that breaks at checkout. If your billing implementation has exceptions, map those first. A SaaS founder discussion about pricing metrics illustrates how providers debate the appropriate unit; it does not establish what your customers understand.
Write a unit sentence for each plan
Use a sentence that can be copied into an invoice: “$49 per active user per month, billed monthly,” or “$49 per workspace per month, including three users.” If the price is usage-based, specify the event counted, included quantity, overage rate, and when usage resets. Name the currency and billing interval. If taxes or fees are added, link to the applicable terms and show what the buyer can expect in their region; finance and legal teams should approve the wording.
Avoid labels such as “per team” when the definition of team changes across plans. If there is a minimum commitment, state it beside the number. If a buyer can add a seat mid-cycle, explain the prorating rule in a short FAQ linked from the price, using the actual billing provider’s behavior.
Test a realistic bill
Pick two customer scenarios: a solo user and a growing team. Calculate the charge for each under every eligible plan. Include a month with extra usage if relevant. Can the public page lead a reasonable buyer to the same total, or does an undisclosed rule appear only in the payment screen? If the calculation is too complex for a static table, provide an example and a route to a tailored estimate without implying that the example is a guaranteed quote.
Next compare the page with checkout, order confirmation, account billing screen, and sales proposal. Changes to a billing system can silently make an old marketing table false. Assign an owner to review the page whenever plan rules change.
Remove false simplicity
Not every edge case belongs in a large grid. Keep the primary unit clear beside the price, then use a concise “How billing works” explanation for limits and exceptions. If a plan is genuinely custom, say which variables determine a quote and what the buyer receives after contacting sales. Hiding the unit of a self-serve plan tends to create avoidable clarification work.
ARCHV can scope a pricing page using owner-approved plan rules and examples. Billing logic, taxes, contract terms, and subscription-system changes require separate specialist work. Request a website estimate with your plan definitions and an example invoice for each plan.
As a final check, ask someone unfamiliar with the plan to calculate the first and second month's charges for a realistic team. If they cannot do it from the page and the relevant terms, identify which rule is missing. That exercise tests comprehension more directly than asking whether the table looks clear.