A services-team CRO told me last spring that her team had just bought a CPQ tool. They were nine months in. The proposal turnaround time had dropped, which she liked. The realised margin on the proposals that closed had also dropped, by about four points, which she did not. Her team had not changed. Their delivery had not changed. They were just configuring and pricing engagements faster, against scopes that were no more rigorous than they had been before.
That is the pattern I see most often when teams adopt product-style CPQ for services work. The configuration speeds up. The pricing automates. The scope, which is the thing that actually determines whether the deal makes money, sits exactly where it sat before: in someone’s head, in a slide deck, in a Word document that legal will eventually edit.
Configure-price-quote without configure-price-scope is theatre. The remainder of this piece is about why, and what configure-price-scope looks like in practice.
The CPQ gap in professional services
Product companies solved configure-price-quote two decades ago. The mechanics are clean: a product catalogue, configurable options, pricing rules, approved discount bands, automatic quote generation. The deal that goes out the door reflects what the company actually sells, at a margin the company has structurally protected.
Services teams have been trying to import that pattern for ten years. Most of the imports have failed. The reason is structural, not tooling. A product configuration is a fixed thing. The configurator can hold the truth of the product because the product is the same shape every time. A services engagement is not a fixed thing. Its scope is what is being negotiated. The configuration cannot hold the truth of the engagement because the truth of the engagement is the scope itself, and the scope is a moving object during the sale.
Importing CPQ-for-product into a services team treats scope as if it were a product attribute. It is not. Scope is the deliverable boundary that determines whether the team will make or lose money. Treating it as a configuration field hides exactly the place where margin is decided.
Configure-price-scope, not configure-price-quote
The reframing I now use with operators is configure-price-scope. The S replaces the Q. The mechanics rhyme with CPQ. The center of gravity is different.
In configure-price-quote, the artifact is a quote. Configuration produces a price. Pricing logic protects margin. The quote is the deliverable.
In configure-price-scope, the artifact is a structured scope object that the team will deliver against. Configuration produces a scope. Pricing logic is calibrated against the scope. The scope is the deliverable, and the quote is a derived view of the scope’s economics.
The practical implications cascade from there. A configure-price-scope system holds:
- Deliverable specifications, not deliverable descriptions.
- Defined acceptance against each deliverable.
- Complexity drivers attached to each scope component, calibrated against the team’s actual delivery history.
- Margin bands calibrated per engagement type, enforced at the configuration layer.
- An audit trail of how the scope changed during the sale, and how the price moved with it.
A configure-price-quote system, by contrast, holds a configuration of options and a price. The scope is downstream of the quote, captured in a Word SOW that nobody on the delivery team queries.
The difference is not aesthetic. It is the difference between a system that can defend margin during delivery and a system that cannot.
CPQ for product vs CPQ for services vs PS-OS-style CPS
A short comparison may be useful, because operators evaluating tools regularly conflate the three.
| Dimension | CPQ for product | CPQ-for-services (typical) | PS-OS configure-price-scope |
|---|---|---|---|
| Central artifact | Quote derived from configured product | Quote derived from configured option set | Structured scope object that the team delivers against |
| Scope handling | Implicit in product attributes | Captured as text fields adjacent to the configuration | A structured first-class artifact, queryable, versioned |
| Pricing logic | Rules over product variants | Rules over option pricing, often with discount approval | Rules over scope components, with margin bands enforced per engagement type |
| Margin defence | At the discount approval layer | At the discount approval layer | At the scope-and-margin-band layer, before discount even comes up |
| Delivery linkage | Product is fulfilled, not delivered | Quote is “won,” handed to delivery via PDF | Scope object becomes the engagement’s working artifact during delivery |
| Learning loop | Pricing tuned by product analytics | Pricing tuned by win rate | Scope and margin tuned by realised delivery margin against quoted margin |
The middle column is what most services teams end up with when they buy a product-style CPQ from a CRM vendor and try to bend it to services work. It speeds up the wrong thing. It does not move realised margin, because it is not in the place where realised margin is decided.
For the operator-level read on the related delivery shape, see the proposal factory on what high-frequency proposal work looks like when the substrate is right, and the SOW process is broken at most teams on why the document layer is downstream of the structural problem.
Real proof: where this shows up in the numbers
Three pieces of grounded evidence are worth naming, because the configure-price-scope argument is not a marketing claim, it is an operating one.
The first is proposal turnaround. Industry reporting on services proposal cycles has long sat in the multi-week range for non-trivial engagements2. Teams that move to a structured scope-and-quote substrate consistently report turnaround compressing to days. The mechanism is not that the configurator is faster. It is that the team is no longer reconstructing the engagement shape from scratch every time, which is where the days were going.
The second is realised-margin variance. The SPI Research benchmark shows industry profit margins at decade lows1. Inside that aggregate, the variance between top-quartile and bottom-quartile teams on the same engagement types is wide. The teams that have moved on configure-price-scope-style substrate compress that variance, because the scope object enforces consistency that a Word SOW cannot.
The third is win rate on competitive proposals. There is no clean industry figure for this, and operators should be careful with anyone who quotes one. What is documented is that proposals that arrive with a clear, structured scope tend to convert at a higher rate than proposals where the scope is described in prose and the price is a single number2. That tracks with what I have seen in operator notebooks. The structured scope is doing legibility work for the buyer as well as defence work for the seller.
What to ask a vendor
If you are evaluating a tool that says it does CPQ for services, three questions are worth asking before anything else.
First: where does the scope live? If the answer is “we capture scope as a description field,” that is configure-price-quote, not configure-price-scope. The vendor is selling product CPQ in a services-shaped box.
Second: how does the system enforce margin? If the answer is “discount approval workflow,” that is too late. Margin needs to be enforced at the scope-and-band layer, before discount is the conversation.
Third: what is the linkage between the scope object and delivery? If the deliverable handoff is a PDF, the scope is being abandoned at the moment of sale and reconstructed by the delivery team from scratch. The compounding work fails to happen. If the scope object is the engagement’s working artifact during delivery, the loop is closed, and the team’s next quote will benefit from this engagement’s actuals.
For the working artifact most operators use to start this transition, see the SOW template and the fixed-fee pricing calculator. Both are structured-scope-first by design, and both are intended to feed an engagement object rather than to live as standalone documents.
Frequently asked questions
-
Configure-price-scope replaces the Q in CPQ with S, putting the structured scope object at the center of the artifact rather than the quote. The configuration produces a scope. Pricing logic is calibrated against the scope. The quote is a derived view of the scope's economics, not the artifact itself. The practical difference is that CPS holds deliverable specifications, defined acceptance, complexity drivers, and margin bands as first-class structure, where CPQ-for-services typically captures scope as text fields adjacent to a configuration.
-
A product configuration is a fixed thing. The configurator can hold the truth of the product because the product is the same shape every time. A services engagement is not a fixed thing; its scope is what is being negotiated. Treating scope as a configuration field hides the place where margin is actually decided. Teams that import product CPQ speed up the configuration and pricing while leaving the scope exactly where it was, in someone's head and in a Word SOW.
-
It enforces margin at the scope-and-band layer rather than at the discount approval layer. Each engagement type has a calibrated margin band attached to the service definition. When a deal is being shaped at a margin outside the band, the system flags it and requires a structured justification before the deal can move forward. By the time discount approval would normally be the conversation, the deal has already been shaped within an acceptable margin envelope. Discount becomes a tactical lever rather than the only line of defence.
-
The SOW is a downstream document derived from the structured scope object. The scope object is the engagement's working artifact, queryable and versioned, that the team delivers against. The SOW is what legal needs. In CPS-style systems the SOW is generated from the scope, not authored separately. For the deeper read on why the SOW process is broken when the substrate is wrong, see the SOW Process Broken piece.
-
No. The pattern can be made to work with custom-built tooling, with mature competing platforms that allow scope to be modelled as structure rather than text, or with Servantium where the engagement layer is built around this shape. The structural move is what matters. A team that has imported product CPQ into a services context can usually retrofit the scope-as-structure pattern into the existing tool, though the further they have gone with treating scope as a description field, the more rebuilding it requires.
Sources
- . (2025) . 2025 Professional Services Maturity Benchmark. https://spiresearch.com/professional-services-maturity-benchmark/ Accessed 2026-05-07. ↩
- . (2024) . Sales Operations Benchmark, proposal cycle and win rate analysis. https://www.forrester.com/research/ Accessed 2026-05-07. ↩
