How to Choose an SAP CPQ Implementation Partner: The Questions That Matter

The question I get asked most often at the evaluation stage is some version of this: we have three quotes, they describe three different projects, one is noticeably cheaper than the other two, and we cannot tell whether that is a good deal or a warning sign.

With almost any other SAP product you can triangulate. You search the partner’s name and find people who have worked with them. You ask which certification their consultants hold. You open the SAP Partner Finder and filter by solution. When you are choosing an SAP CPQ implementation partner, every one of those checks quietly fails. Which means the questions you ask in the room have to do the work that reputation normally does everywhere else.

This article assumes you have already settled the earlier question of when it makes sense to bring in outside help at all, and that the platform itself is settled. If it is not, what separates SAP CPQ from Salesforce CPQ once you open them is the question that comes first. What follows is what to ask once you have.

An SAP CPQ implementation partner is unusually hard to check

The Partner Finder has no filter for SAP CPQ. SAP groups partners into five customer facing categories: Sell, Build, Consult and implement, Managed service, and Enablement. The Consult and implement list alone has more than 2,700 companies. The obvious next step is to narrow by solution, and that is where it stops. Type CPQ into the Solution filter and it returns no matches. Type quote and the only thing that comes back is Quote-to-Cash management, filed under Financial management. The directory that is supposed to shortlist for you cannot tell a firm with fifteen CPQ projects behind it from a firm with none.

The certification you would ask about is not in the active catalogue. There used to be an associate level exam for SAP CPQ implementation. Search the current catalogue for CPQ and you get two accidental matches, one of them because the exam description contains the word configure. A SAP employee confirmed in a Community thread that the exam they passed a few years ago no longer appears on the list. So when a partner says their consultants are certified in SAP CPQ, you have no clean way to check what that means. The closest current equivalent is SAP’s own eighteen hour course, Implementing SAP CPQ, which has no prerequisites and is open to anyone. Training, not a credential.

So the shortlist gets built by conversation rather than by filter, and a partner’s answers about the product carry more weight than any badge. It helps to know what an SAP CPQ implementation actually covers before you sit down, so you can hear when a scope is missing something.

Three technical questions that show whether they have opened the system

You do not need to be technical to ask these, only to recognise a specific answer when you hear one. An SAP CPQ implementation partner who works in the system every week will handle all three without reaching for a colleague.

Which quote engine will we be on, and who owns the migration

SAP maintains two separate administration guides for SAP CPQ, one for Quote 1.0 and one for Quote 2.0, and they are not variations on a theme. The Quote 2.0 guide has sections for Sales Area Administration and Business Partners. The Quote 1.0 guide has Customer Administration and Renewal Management instead. Different objects, different admin screens, different habits.

If you are live on Quote 1.0, this decides the shape of your project. SAP’s migration documentation says plainly that moving to the Quote 2.0 engine needs to be handled as a project, and splits the work into two scenarios. Move across without significantly changing your modelling and the migration tool works, with your old quotes still available. Rebuild the model and the tool cannot be used, the old quotes do not come with you, and SAP notes that this second path is not covered by the documentation at all. There is also a prerequisite most people miss: copying the production tenant is mandatory, because the tool only works when the technical IDs of quote related entities match between source and target.

A partner who has done this will tell you which scenario you are in, will mention the tenant copy unprompted, and will say that rebuilding the model is where most of the time and budget goes, because that is what SAP’s migration guide says too. One who has not will describe migration as a technical step near the end.

How much of this becomes script, and who can read it after you leave

SAP CPQ is extended with IronPython, attached to events and administered under Setup, Develop, Global Scripts. Scripting is normal and often necessary, and custom development inside the platform is part of most serious implementations. The question is proportion, and whether anyone will be able to maintain what gets written.

SAP publishes its own guidance on eliminating common performance problems in SAP CPQ, and the list of things to look at opens with poorly written IronPython scripts, followed by scripts running for a long time and CTX tags looping too many times. When the vendor names implementation quality as the first suspect for a slow system, you are entitled to ask a partner how they avoid being that suspect.

Keep a few hard platform limits in your pocket too. A single line of IronPython code is capped at 50 operators. More than ten nested script calls in one request writes a warning on older tenants and throws an error on tenants created after the 2202 release. Since 2205, scripts running longer than twenty minutes are cancelled automatically, and script size is capped at 40,000 characters. There is also a live example of why a shortcut becomes your problem: SAP has flagged the removal of the eval function, and existing scripts using it keep working but cannot be edited until eval is taken out. Something written quickly in year one can freeze a rule you need to change in year three. Ask how scripts are documented, whether they are version controlled, and what the handover artefacts are, because handing the system over to an internal team is where undocumented code stops being an abstract risk.

What our SAP landscape has to be running before any of this connects

Integration is where quotes diverge most, usually because one bidder checked the version requirements and another assumed. SAP publishes them and they are specific. S/4HANA on premise needs 1809 or higher. SAP ERP for variant configuration products needs 6.0 EHP 5 or higher on a Unicode system. SAP Sales Cloud needs 1905 or higher, with SAML 2.0 single sign on established. SAP Commerce needs 1811 or higher, and a higher bar again for configurable products.

One line from that same page is worth reading out loud in a vendor meeting, because it sets up months of work that nobody has costed: out of the box, SAP CPQ and SAP Sales Cloud do not share the same product master. If nobody in the room reacts to that, they have not designed a replication before. Someone who works here regularly will go straight to which system owns the material master, how business partners replicate, and what happens when product data changes upstream, and you can weigh that answer against how the integration architecture is usually laid out. The numbers are all in SAP’s system requirements table, and reading them beforehand changes the tone of the meeting entirely.

The questions that decide what you are left holding

The questions above tell you whether a partner can build it. These tell you what your position looks like on the day they finish.

Whose name goes on the Technical Contact line

When an SAP CPQ contract starts, the Technical Contact named on that contract receives the provisioning mails, gets an S-user ID, and is granted the Cloud Administrator role. That person then creates S-user IDs for everyone else on the project and assigns their authorisations.

Read that again with procurement eyes. If the Technical Contact is your implementation partner rather than someone on your payroll, your partner controls access to your own tenant, and getting it back is an administrative process nobody planned for. Put your own name there, then decide separately what access the partner needs, which belongs with your ongoing support arrangement rather than with provisioning.

What happens in the two weeks before a release upgrade

SAP CPQ upgrades on a published schedule, and four releases each year come with a pre-upgrade testing window. The new version lands in sandbox and test environments about two weeks before production. SAP’s own explanation of why that offering exists is the useful part: it says two weeks may not be sufficient, because customers often have extensive customisations in their tenants that require more time to verify.

That sentence describes your future, so ask directly who regression tests your customisations before each upgrade, on whose budget, and what happens when something breaks. Ask whether they have used the pre-upgrade testing offering, since places are limited and enrolment goes through a customer case. A partner who has run this cycle will know that issues get raised under component CEC-SAL-CPQ with the release identifier in the subject line. That level of specificity is not something anyone improvises.

Who is accountable, in writing, before anyone signs

SAP publishes a RACI matrix specifically for SAP CPQ projects, which makes this easy to test. Ask a candidate to fill it in for your project. The interesting rows are the ones where instinct is wrong. User acceptance testing is accountable to your business users, not to the partner. Integration development and custom development are accountable to the partner’s technical consultants. Data migration is shared across both sides with no single owner, which is exactly why it slips. Blueprint, testing and go live sign off all sit with your project sponsor. The document states that there should be only one accountable role per task, so a matrix that comes back with three names in a box is telling you something about how that firm runs projects.

One more thing while you are there: get the delivery team named. Consultants inside large integrators have said publicly that the CVs in a proposal are representative rather than binding. Ask for named individuals, ask what happens if they are pulled onto another engagement, and put the answer in the contract along with your right to request a replacement. The cost of getting this wrong is not theoretical, and picking up a project someone else left half finished is a category of work that exists for a reason.

What a good answer actually sounds like

Every article on this subject hands you questions. Almost none tell you how to grade the reply, which is the part that matters, because a rehearsed answer and a real one use the same vocabulary.

The pattern I trust is specificity that costs the speaker something. A partner who says migration is straightforward is selling. One who says it depends on whether you are rebuilding the model, and that if you are, the tool will not help and your historical quotes will not come across, has just made their own quote look bigger and harder. That is someone telling you the truth at their own expense.

The second pattern is admitted limits. The best advice I have seen from people who have run these selections is to favour the partner who volunteers what they are not good at. Anyone claiming equal depth in configuration, scripting, integration, pricing and change management is describing a team that does not exist.

Three things to take away. You cannot outsource this judgement to a directory or a certificate, because for this product neither works. The technical questions are the real shortlist, since answers about the quote engine, the scripting proportion and the integration prerequisites separate people who have opened the system from people who have read the brochure. And ownership gets settled before signature, because the Technical Contact line, the release testing duty and the RACI are all cheap to fix now and expensive later.

Choosing an SAP CPQ implementation partner is harder to research than it should be, and the gap closes by asking better questions rather than by finding a better list. If you want a second opinion on the answers you are getting, we are glad to look at them with you.