Writing an SAP CPQ RFP: What the Templates Leave Out

Search for what an RFP means in SAP and the first thing you are handed is documentation for Request for Proposal Events in SAP Ariba. That is a sourcing module. It is not the document you are trying to write. The one I mean goes out to three implementation firms and comes back as three proposals describing three different projects, at three prices, with no shared unit of measure between them.

Templates for this are easy to find and mostly disappointing. Half of them are a form that asks for your email. The ones that are not gated are thorough about quoting software in general and silent about the product you have already chosen. I went through the first ten results for this topic and counted how many mentioned Quote 1.0 versus Quote 2.0, the absence of a transport layer, IronPython, the CODERINT add-on, or who pays for regression testing four times a year. The count was zero on every item, and each one of them changes what a bid should cost. An SAP CPQ RFP has to do the work those templates skip.

An SAP CPQ RFP is a partner selection document, not a product evaluation

The first question worth asking is whether you need this document at all. If your company already runs SAP ERP and has decided that quoting belongs in SAP CPQ, the platform question is closed. What remains is a choice between implementation approaches and the people who will execute them. That is a different exercise from a product bake-off, and running it as one burns weeks answering questions you resolved months ago. The platform comparison belongs upstream, and if it is still genuinely open, that decision deserves its own analysis before a single requirement gets written.

A request for proposal does not replace discovery

The second trap is asking for a fixed price on scope nobody has examined. I understand the instinct. Procurement wants a number, and a number feels like control. What it buys is a risk premium, because a partner pricing unexamined work has to price the worst version of it. Discovery is paid work that happens with the firm you selected, not free work you extract from three firms competing. When I see a proposal quoting a precise figure for an integration nobody has looked at, I read it as a guess with confident formatting. Better to scope the discovery itself in the document, then let the structured discovery work produce the numbers that follow.

One more thing I noticed while researching this. I looked for publicly posted CPQ tender documents, the kind that universities and public agencies routinely publish for IT infrastructure, and I could not find one. There is no precedent lying around to copy. Whatever you send out, you are writing from scratch.

What you write about yourself decides whether the bids come back comparable

Every template I read asks vendors to describe their capabilities. Almost none ask you to describe your landscape precisely enough for those descriptions to be priced. This is backwards. A partner cannot size an integration without knowing what sits on the other end of it, and when that information is missing, each firm assumes something different. Three reasonable assumptions produce three incomparable proposals, and then everyone blames the vendors.

The landscape facts that change the shape of every bid

State these in the document, not in a follow up call. Which ERP release you are on, and whether S/4HANA is on premise, private cloud or public cloud. Which SAP Sales Cloud version, if any, and whether SAML 2.0 single sign on is already in place. Whether the CODERINT add-on is installed. Where your configuration logic lives today, because moving it out of LO-VC is a different project from leaving it where it is. And whether you expect to land on Quote 1.0 or Quote 2.0, since the two engines cannot run side by side on the same tenant, which makes it an architectural commitment rather than a preference. If you are unsure how many of these you can answer, the readiness inventory you should already be holding is the place to start. A document sent before that inventory exists comes back as guesswork.

The volumes nobody asks you for

Alongside the systems, give the shape of the work. Number of product families in scope. How many pricing rules you maintain today and where they are written down, if they are. How many quote document templates, in how many languages. How many approval levels, and whether any run in parallel. Which integration endpoints have to exist on day one and which can wait. These are boring numbers, and they are the difference between a proposal and a brochure. The section of an SAP CPQ RFP that describes your own landscape is the section that decides everything downstream of it.

The integration path deserves a real question rather than a checkbox. One SAP CPQ user in manufacturing put the problem plainly in a public review this April, writing that they were “using DPA to extract the data from ERP so better to have a direct connection from CPQ to ERP.” That is an architecture decision with performance consequences, made once and lived with for years. Ask each bidder which path they propose and why, not whether ERP integration is supported.

The clauses that are cheap to write and expensive to skip

Licensing is the one number SAP does not publish

Here is something worth knowing before you start drafting. I went through the SAP CPQ help portal looking for licensing terms, and there is no such section. The documentation covers administration, integration, development, troubleshooting and end user guidance. It says nothing about the licensing metric, nothing about user types, nothing about which adjacent products carry separate entitlements. That information lives in the order form you receive during negotiation, which means you cannot verify it independently beforehand.

So ask for it in writing, as a requirement rather than a question. What the metric is. Which user types exist and what each one costs. Whether SAP Subscription Billing, SAP Commissions, Integration Suite and the variant configuration components are included or separate. Reviewers on public software directories list license cost as a recurring complaint without ever citing a figure, which tells you the number stays hard to pin down even after purchase. How you press a candidate on the answer belongs to the conversation that happens after the document goes out, but the ask itself belongs here.

Availability, support and what the service level agreement leaves out

SAP publishes a service level agreement for its cloud services committing to 99.7 percent monthly system availability for production, with a credit of 2 percent of the monthly subscription for each full 1 percent below that, capped at the monthly fee and claimable within 30 business days of month end. Read the exclusions, because that is where the useful detail sits. Excluded downtime covers the published maintenance window and any major upgrade window announced at least five business days ahead. Those hours never count against the commitment.

A second gap matters more. SAP support does not cover problems caused by customisation written by you or your partner. On a build carrying significant IronPython, that exclusion covers a good share of what can break at two in the morning. Ask who answers in that case, for how long after go live, and at what cost, and ask for it as a commitment rather than a reassurance. What a workable support model looks like in practice is worth reading before you draft that section, because the vocabulary matters.

Who runs regression four times a year

SAP CPQ ships four releases a year, each reaching sandbox roughly two weeks before production. There is no transport layer between environments, so moving a validated configuration is a tenant copy through support rather than a promotion you control. That combination creates a standing obligation: someone regression tests before every release, forever. I have never seen a generic template mention it, and I have seen the cost of it land on a client who assumed it was included. Name it, ask for it to be priced annually, and look at the release cadence you are committing to so the number has context. While you are there, settle what leaves with the partner: who owns the scripts, who holds the technical contact line, and what gets handed over if you change firms.

Scoring only works if the questions were written to be scored

Standard procurement practice separates mandatory criteria, which are binary and eliminate a bidder outright, from desirable criteria, which carry weights. That distinction collapses the moment requirements are phrased as feature checkboxes, because every bidder ticks every box and the scoring produces a three way tie.

A concrete illustration. SAP states in its own integration documentation that SAP CPQ cannot be used to trigger subscription changes in SAP Subscription Billing. A row reading “Subscription billing: supported” hides that completely, and you would find out in month four. Written as a scenario instead, describing an existing customer upgrading mid term and asking the bidder to walk through how that quote reaches billing, the same row becomes answerable, comparable and scorable. Write requirements as things a salesperson has to do, and the vague answers become visible.

Two dates belong in the timeline section because SAP has already fixed them. Its onboarding resource center tells customers to work through the first onboarding materials a few days after the contract start date, and to book the Deployment Readiness Check six weeks before go live, which is included in Enterprise Support. A proposed plan that ignores either one is a plan that has not been built before. If you cannot describe your own current state well enough to write any of this, an independent read of the system you already run will get you further than another round of internal workshops.

So, what to take from this. A good SAP CPQ RFP is mostly about you, and the parts describing your landscape decide whether anything comes back comparable. The expensive clauses are the quiet ones: licensing metrics, the support gap around custom code, and quarterly regression that never appears on a template. And every requirement should be written so that a weak answer looks weak on the page. If you want a second pair of eyes on a draft before it goes out, that is a conversation we are glad to have.