CPQ Requirements Checklist: Define This Before Any Vendor

A CPQ requirements checklist is the document you write before you talk to any vendor, listing exactly what your quoting process has to do so that demos answer your questions instead of the vendor's. The single most common reason a CPQ project disappoints is that the buyer walked into demos without a written definition of their own configuration rules, pricing logic, approvals, outputs, and integrations, and let the software set the agenda. This is that checklist, from a business analyst who writes them for a living, so you can define the requirement first and shop second.

I am a business analyst, and the most valuable week of any CPQ project is the one before anyone sees a demo, spent writing down what the business actually needs. If you are still deciding whether you need CPQ at all, our explainer on what CPQ is covers that; this assumes you know you need it and want to define it properly.

Why write requirements before you talk to any vendor?

You write requirements first because otherwise the vendor writes them for you, in the shape of their product, and you find out the gaps after you have signed. A demo is designed to show what a tool does well, not what it does badly, and without your own checklist you have no way to steer it toward the things that will actually make or break your project.

A written requirement flips the conversation. Instead of watching a polished happy path, you hand the vendor your real configuration rules and pricing edge cases and ask them to show you those, live. You find the gaps during evaluation, when they are free to discover, rather than during implementation, when they are expensive. The checklist also aligns your own side, because the act of writing it forces sales, finance, operations, and IT to agree on how quoting actually works today, which is often the first time anyone has written that down. Treat the sections below as prompts; the deliverable is a document, ideally a few pages, that any vendor could read and quote against without a single meeting.

What belongs in your configuration and product rules?

This is the heart of the checklist, because configuration is where CPQ earns its name, and it is where vague requirements do the most damage. Write down, concretely:

• The product families you sell and roughly how many configurable products sit in each.
• The options and features a buyer chooses, and which ones are independent versus linked.
• The dependency rules: which options require, exclude, or force others.
• The validation rules that decide whether a configuration is sellable at all.
• Any engineered-to-order logic, where a quote generates something new rather than picking from a catalog.
• How often the product model changes, and who is allowed to change it.
• The languages and units of measure your products must be described in.
• How the system should surface an invalid configuration to the seller, as a nudge or a hard stop.
• The messiest real configuration you have ever quoted, written out as a test case.

That last item matters more than the rest. A tool that handles your clean examples but not your worst real one will fail in production, so put the hard case in writing and make every vendor quote it.

What belongs in your pricing and approval rules?

Pricing and approvals are where quoting quietly becomes a governance problem, so name the rules precisely rather than describing them as "flexible."

• Your price books, and whether they vary by region, currency, segment, or channel.
• The discount types you allow, and the limits on each.
• The approval matrix: which discount or deal shape triggers whose sign-off, and in what order.
• Margin floors or guardrails the system should enforce, not just suggest.
• Contract and subscription terms, if you sell recurring, including renewals and co-terming.
• Any deal-specific or negotiated pricing that lives outside the standard books today.
• Currency, rounding, and tax or duty rules that apply by market.
• Time-bound pricing, promotions, or price protection you have to honor.
• Who owns pricing, and how a price change gets made and audited.

If your pricing and approvals currently live in spreadsheets and email, say so plainly, because moving that into a governed system is much of the value, and much of the work.

What quote outputs and documents do you need?

The quote a customer sees is the visible product of all this machinery, so define it as carefully as the logic behind it.

• The documents you produce: quote, proposal, order form, statement of work.
• The branding, layout, and language variations each needs.
• Whether quotes go out as PDFs, portals, or both, and in which languages and currencies.
• Where electronic signature fits, and which documents require it.
• The handoff from an accepted quote to an order, and what has to be true for that to happen cleanly.

What integrations and data do you need to name?

CPQ almost never lives alone, so list every system it has to talk to and, crucially, who owns the data at each seam.

• Your CRM, and whether CPQ lives inside it or beside it.
• Your ERP, for orders, products, and pricing, and which system is the source of truth for each.
• Billing or subscription management, if quotes become recurring revenue.
• Electronic signature and document services.
• The master data question: where products, prices, and customers are authored, and how they stay in sync.

The data-ownership answers are the ones that prevent the worst implementation fights, so do not leave them for later.

Who are the users and what do they need?

Finally, name the people, because a tool that the sales team will not use is a failed project regardless of how well it is configured.

• The roles who will build quotes, approve them, and administer the system.
• Roughly how many users of each, and where they are.
• The realistic skill level and patience of your sellers, which should shape how much guided selling you need.
• Who will own and maintain the system after go-live, which is the question most buyers forget.

What does "done" look like, and who owns it afterward?

Two questions get skipped in almost every requirements document, and both are expensive to answer late. The first is what "done" actually means, written as acceptance tests in your own numbers rather than as a vague sense of readiness: the specific quotes the finished system has to produce correctly before you will trust it with a real customer. If you cannot describe the quotes that prove success, you cannot tell whether the project succeeded, and neither can the vendor.

The second is ownership after go-live, because a CPQ system is not a project that ends, it is a living model of how you sell, and it decays without a keeper. Write down:

• Who administers the product and pricing model day to day.
• Who is allowed to add users, change rules, and approve exceptions.
• Who fixes it when a rule is wrong at six in the evening on the last day of the quarter.
• How changes to the model are tested before they reach live quotes.

Name that owner in the requirements. A tool nobody owns quietly rots back into the spreadsheets it was bought to replace, and the requirements document is where you prevent that by making stewardship somebody's explicit job.

How do you turn this into something vendors can quote?

Collapse all of the above into a short brief a vendor can read cold, lead with your three or four hardest requirements, and attach your worst real configuration and pricing example as the acceptance test. That single page does more to protect your project than any feature comparison, because it makes the vendors compete on your reality instead of their strengths. Keep it honest about what is still uncertain, too. If you do not yet know whether you need consumption pricing, or how many currencies you will really sell in, write the open question down rather than papering over it, because the vendors worth hiring will help you think it through, and the ones who gloss past it are telling you something you should hear before you sign. When you are ready to compare platforms against this definition, our CPQ software comparison is the next step, and if you would rather hand the whole definition-and-build to a team that starts with exactly this kind of checklist, our CPQ work, delivered by our Salesforce development practice, does.