How to write a pricing FAQ that cuts sales tickets

If sales answers the same bill question ten times a week, that answer belongs on the pricing page FAQ.

Buyers do not book a demo to learn your brand story. Many early calls are bill questions in disguise: who this plan is for, what makes the price jump, what is not included, how overages work, whether seats are human or usage-based. When those answers only live in AE heads, your calendar fills with ticket work. A clear pricing FAQ moves those questions to the page so sales can spend time on deals, not on repeating the same paragraph.

What is a pricing FAQ for?

Pre-sales clarity. Not legal theater. Not a place to hide the real price behind soft language.

The FAQ sits next to your tiers and, for AI products, next to a bill estimate buyers can trust. Tiers split buyers. The estimate shows a number. The FAQ answers the objections that stop the click or the booking.

Which questions must appear?

Start from the last thirty sales and support threads about money. Sort the threads into four buckets and write one FAQ item per bucket.

1. Who it is for. Which plan matches which team size or job. When to talk to sales. When self-serve is enough.
2. What changes the price. Seats, usage, modules, support level, annual vs monthly. Name the levers in plain language.
3. What is not included. Onboarding hours, custom models, premium support, SSO, sandbox environments. Surprises after the card is charged create churn and angry tickets.
4. How overages work. Soft caps, hard caps, auto-scale, notification before the bill jumps. AI products that bill on tokens or runs need this in writing.

If a question shows up in sales Slack every week and is missing from the FAQ, you are choosing tickets over clarity.

How do I write each answer?

Short. Specific. No weasel words.

Bad: "Pricing is flexible based on your needs."

Better: "Team includes up to 10 seats and 50,000 runs per month. Extra runs bill at $X per 1,000. Need SSO or a shared sandbox? That is on Business."

Use the same numbers your estimate widget and your order form use. If the FAQ says one thing and the checkout says another, you did not cut tickets. You created new ones.

Point to related tools when useful. An ROI calculator answers "is this worth it." The FAQ answers "how will I be billed." Keep those jobs separate.

How does this fit with tier design?

Tiers should split buyers, not feature checklists. The FAQ explains the split in buyer language.

Example shape:

• Starter: solo or tiny team, self-serve, usage floor
• Team: one department, shared workspace, standard support
• Business: multi-team, security and admin needs, success contact

Then the FAQ says who belongs where, what happens at the edges, and when product-led sales should join. Do not make the FAQ a second pricing table. Make it the translation layer.

What sales tickets should disappear after you ship it?

Track a short list for thirty days:

• "Do I pay per seat or per run?"
• "What happens if we go over?"
• "Is onboarding included?"
• "Can we start on Team and move to Business mid-year?"
• "What is not in the list price?"

If volume on those threads does not drop, your FAQ is incomplete or buried. Put it on the pricing page, not in a help center nobody reads before booking.

What should I never do in a pricing FAQ?

• Answer with "contact us" for questions you already know
• Hide overage math
• Use different unit names than checkout (credits vs tokens vs runs)
• Promise "unlimited" when you mean a high cap
• Copy competitor FAQ language that does not match your bill
• Write essay answers when a three-line answer would do

Clarity cuts tickets. Cleverness creates follow-ups.

What should I do this week?

1. Export thirty days of pricing questions from sales and support. Tag the four buckets.
2. Draft one FAQ answer per repeated question. Use checkout numbers.
3. Place the FAQ on the pricing page under the tiers and estimate.
4. Tell AEs to paste the FAQ link when the same question arrives. Update the FAQ when a new repeat appears.
5. Review ticket volume on those tags after two weeks. Keep editing until the repeats die.

Adapt or fail. A pricing page that forces every bill question into a meeting does not create pipeline quality. It creates a help desk with quota.

Start Signals, Convert, Grow

FAQ

How many pricing FAQ items do I need?

Eight to twelve covers most early SaaS bills. Start with the repeats. Add only when a new question keeps showing up.

Should the FAQ include discount policy?

Yes, if you have one. "Annual prepaid saves X%" belongs on the page. Custom discounts that only exist in AE improvisation belong in a written rule, not a mystery.

Do I need a separate FAQ for AI usage billing?

If usage is a price lever, yes. Buyers ask how runs, tokens, or records map to the bill. Answer with units that match the meter they will see.

Where should the FAQ sit on the page?

Directly under tiers and any estimate widget. Do not make buyers hunt a docs site before they understand the bill.

How often should I update it?

Any time packaging, overages, or inclusions change, and any time sales reports a new repeat question. Stale FAQ answers are worse than none.