Invalid configurations reach the customer
Components that cannot ship together, a required accessory nobody added, an option not available in that region. Fulfilment catches it after the customer has already seen the price.
Salesforce · Conga CPQ
Quotes that are right before anyone checks them.
If a quote needs a specialist to validate it, your configuration rules are in someone's head instead of in the system. Twopir Consulting implements Conga CPQ by modelling the catalogue and the rules that govern it first — bundles, constraints, price lists, discounting and approvals. So a rep who joined last month can still quote correctly.
Trusted by 500+ organizations — including sales and revenue operations teams selling configurable products across multiple regions and price books.
CPQ Delivery Coverage
- Salesforce Partner
- Product Catalogue
- Bundles & Options
- Constraint Rules
- Price Lists
- Discounting & Approvals
- Guided Selling
- Quote to Contract
Only three people can quote this correctly
That is the symptom. The cause is always the same: the rules that make a configuration valid live in experience rather than in the system. Every failure below follows from it.
Pricing lives in a spreadsheet somebody maintains
The price book is in the CRM and the real pricing is in a workbook with the current tiers. Two sources, one of which is always slightly out of date.
Discount approval is an email thread
Nobody can tell what was approved, by whom, or against what margin. At quarter-end the thread becomes the audit trail, and the answer to "why did we give that away" is unavailable.
New reps take months to become productive
Because quoting correctly requires knowing which combinations work, which the product catalogue never encoded. Onboarding time is the real cost and nobody measures it.
The proposal is rebuilt by hand anyway
The quote is right in the system, and the document the customer receives is assembled in a word processor from last quarter's version. The two drift immediately.
Quote terms get re-keyed into the contract
Products, quantities, duration and price typed again into the agreement. Every re-key is a chance to introduce a discrepancy nobody finds until billing does.
Four layers, and the one that decides the project
Conga CPQ configures complex products, applies pricing and discounting rules, enforces approvals and guides sellers to a valid quote. It can combine hardware, software, services and subscriptions on one quote, and it integrates with Salesforce. Conga's CPQ documentation is the authority on the product; the table below is how we scope an implementation of it.
| Layer | What it decides | How it fails |
|---|---|---|
| Catalogue | What can be sold: products, categories, bundles and option groups, across hardware, software, services and subscriptions. | Modelled the way the ERP stores products rather than the way the business sells them. |
| Constraint rules | What is valid: which products must be sold together, which exclude each other, which are restricted by region. | Under-specified, so invalid quotes still reach customers — or over-specified, so reps cannot quote real deals. |
| Pricing | What it costs: price lists and price list items, with pricing models by quantity, region or other factors. | Kept in a spreadsheet alongside the system, so there are two prices and one of them is wrong. |
| Discount & approval | What can be given away, by whom, and what needs sign-off before it can be. | Thresholds set so low that everything needs approval, so approval becomes a formality nobody reads. |
| Guided selling | How a seller reaches the right configuration: interactive questions that narrow the catalogue to what fits. | Built last as a nice-to-have, when it is the layer that actually shortens rep onboarding. |
Where CPQ implementations overrun
Almost always in the rule layer, and almost always because the rules were never written down anywhere before the project started. They exist as expertise: the senior rep who knows which combinations work, the sales engineer who checks every quote.
Eliciting those rules is the real work of a CPQ implementation, and it takes longer than configuring them. We scope it as its own phase rather than discovering it during build.
Getting the rules out of people's heads
The catalogue and rule model is the first deliverable, and it is produced before any configuration begins. Everything else follows from getting it right.
Catalogue Modelling
Structured the way the business sells, not the way the ERP stores. Categories a rep can navigate, bundles that reflect real offers, option groups that make sense at the point of sale.
- Category and hierarchy design
- Bundle and option group structure
- Hardware, software, service and subscription lines together
- Attribute model for configurable products
- Catalogue maintenance ownership
Constraint Rule Elicitation
The hardest and most valuable part: extracting the validity rules from the people who hold them, writing them down, and testing them against deals that have already happened.
- Structured elicitation with sales engineers
- Inclusion, exclusion and recommendation rules
- Regional and entity restrictions
- Validation against historical quotes
- A written rule set you own
Pricing Configuration
Price lists and price list items configured so the system is the single source, with pricing models by quantity, region or whatever your commercial model actually uses.
- Price list and price list item structure
- Quantity, region and tier-based models
- Multi-currency and entity pricing
- Subscription and recurring price handling
- Retiring the parallel spreadsheet
Discounting & Approval
Thresholds that reflect margin rather than habit, with routing that escalates the deals that genuinely need a decision and clears the ones that do not.
- Discount bands tied to margin or value
- Approval routing and delegation
- Auto-approval where the rules already cover it
- Audit trail on every concession
- Reporting on discount behaviour by team
Guided Selling
Interactive questions that take a seller from a customer need to a valid configuration — the layer that most shortens onboarding and most often gets cut.
- Question flow design from real discovery calls
- Need-to-product mapping
- Cross-sell and upsell recommendations
- Testing with new reps, not experienced ones
- Iteration once real usage data exists
Quote to Proposal to Contract
The handoffs either side of CPQ. The proposal generated from the quote rather than rebuilt, and the agreed terms carried into the contract rather than re-keyed.
- Proposal generation from the configured quote
- Quote-to-agreement field mapping
- Renewal and amendment quoting
- ERP handoff for fulfilment and billing
- See Conga CLM implementation
Rules first, configuration second
CPQ follows the same phased model as every Conga implementation we run, with one addition: rule elicitation is its own phase with its own gate.
Model the catalogue
How the business sells, not how products are stored. We work from real quotes and real conversations rather than from the product master, because the two are rarely the same shape.
Elicit the rules
Structured sessions with the people who currently hold them, then validation against historical deals. The output is a written rule set — and it is valuable to you even if nothing is configured from it.
Configure & price
Catalogue, constraints, price lists and discounting built in a sandbox, with the most complex product family first so the hardest modelling problems surface early rather than late.
Test with real deals
Historical quotes replayed through the configured system. If a deal that closed last year cannot be quoted, a rule is wrong — and this is how you find out before the sales team does.
Enable & iterate
Training aimed at new reps rather than experienced ones, then a deliberate review once real usage data exists. Guided selling in particular gets better with evidence.
The test that actually tells you it worked
Can a new rep quote your hardest deal?
The measure we scope CPQ engagements against
Not whether the system is configured, and not whether it demos well. Whether somebody who joined last month can produce a valid, correctly priced quote for your most complex product family without asking a specialist to check it.
If they cannot, a rule is still living in someone's head. That is a concrete, testable standard, and it is the one we design the rule elicitation phase to meet.
Talk through your product modelWhat you keep
Every CPQ engagement
A written catalogue model. A documented rule set — inclusions, exclusions, regional restrictions, and the reasoning behind each one. The price list structure and who owns maintaining it. The historical deals used as the test set, and their results.
The rule set is the asset. It outlives the configuration, it survives the people who supplied it, and it is what lets you change platform later without starting the elicitation from nothing.
Conga consulting overviewWe spend the time where CPQ projects overrun
We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we work with enterprise organizations facing the same problems at larger scale.
Rule elicitation is a phase, not an assumption
Most CPQ proposals price configuration and assume the rules already exist in documented form. They almost never do, and that assumption is where the overrun comes from.
We model how you sell, not how you store
A catalogue inherited from the ERP structure is navigable by finance and useless to a rep. The selling model and the fulfilment model are different things and both are legitimate.
We test against deals that really happened
Replaying historical quotes is the fastest way to find a wrong rule. A configuration that cannot reproduce last year's business has a modelling error, whatever the demo showed.
We design the handoffs either side
A quote that has to be re-typed into a proposal and again into a contract loses most of its value. Our CPQ work is scoped with the document and agreement steps in view.
We set approval thresholds that mean something
If everything needs approval, approval stops being a control and becomes a queue. Tying thresholds to margin usually reduces both the number of approvals and the discounting.
Answers before the first call
A useful test is whether quotes need checking before they go out. If a sales engineer or a senior rep reviews configurations for validity, the rules exist and they are not in the system — that is what CPQ is for. If products are largely standalone, pricing is a straightforward price book, and discounting is a simple percentage with one approver, a well-configured Salesforce price book plus good document generation may cover you at far lower cost. The complexity that justifies CPQ is combinatorial: bundles, options, exclusions and regional restrictions interacting with each other.
Establishing the rules, not configuring them. Constraint rules — which products must be sold together, which exclude each other, which are restricted by region — usually exist only as expertise held by a few experienced people, and extracting them is slow, iterative work involving disagreement between those people about what the rule actually is. Configuration is comparatively quick once the rules are written down. Any CPQ estimate that does not scope rule elicitation separately is assuming documentation that, in our experience, very rarely exists.
Yes. Conga CPQ supports combining hardware, software, services and subscriptions on a single quote, which is one of the main reasons organizations with mixed commercial models choose it. The design considerations are around term alignment — whether a subscription co-terminates with an existing one, how mid-term amendments are priced, and how renewals are generated — and those decisions have implications well beyond CPQ, in billing and in contract management. We work them through during catalogue modelling rather than treating them as a configuration detail.
It is generated from the configured quote rather than assembled by hand, which is the point — a proposal rebuilt in a word processor drifts from the quote immediately and reintroduces exactly the errors CPQ removed. Conga CPQ produces proposals from the quote, and where the document itself needs significant design work, conditional content or multiple output formats, that is document generation territory: see document generation services and Conga Composer implementation.
Yes, and it is usually the right design where the ERP is the system of record for price. Conga connects to ERP and finance platforms including SAP and NetSuite, so product, price-list and entitlement data can flow into the quoting layer rather than being re-entered. The decisions to make are which system owns which part of price — base price in the ERP with commercial discounting in CPQ is a common split — and how often the sync runs, since a daily refresh is fine for a stable catalogue and inadequate for volatile pricing. See Conga integration services.
Almost always because the rules are too restrictive rather than too loose. When constraint rules are written conservatively they block configurations that are actually sellable, so reps discover that the system will not let them quote a real deal and go around it. The fix is not enforcement but calibration: replay recent closed deals through the system and find the ones it rejects. Each rejection is either a genuine rule the business wants enforced or a rule that is wrong, and working through that list is usually what turns adoption around.
Start Here
Bring us the deal only your best rep can quote
Describe the configuration that always needs checking before it goes out. We will tell you which rules are missing from your catalogue, how much elicitation work that implies, and whether CPQ is the right answer for your product model.
Serving: US | Canada | UK | UAE | Australia | New Zealand
