The CPQ Process: From Configuration to Quote, Step by Step

What is the CPQ process?

Strip away the software and the CPQ process is just the three steps every configurable-product sale has always gone through, done properly instead of by hope: Configure a combination of options that is actually buildable, Price it correctly, and Quote it in a document the customer can sign. CPQ software exists to make those three steps fast and error-free instead of slow and error-prone, that's the whole pitch, and we cover the software itself in more depth in what CPQ is.

There's a second thing people mean by "the CPQ process," and it's the reason this page also gets linked as our implementation process: the project of getting a CPQ system live in the first place. Both matter, and they're connected, a CPQ implementation project's entire job is building software that runs the configure-price-quote workflow correctly for your product. We cover both below.

Step 1: Configure, valid product combinations only

The salesperson, or the customer directly in self-service scenarios, answers need-based questions, capacity, voltage, mounting, region. A rules engine removes invalid combinations as choices are made, so nobody ever configures something that can't be built. On a crane programme we ran, a specific jib length excluded certain stabilizer packages; the seller simply never saw the invalid combination, so the error never had a chance to reach the factory floor. That's the entire value of this step, not more options, fewer wrong ones.

Step 2: Price, rules, discounts, margins

Every valid configuration gets its price computed from rules: base modules, option pricing, market and currency logic, discount bands, and approval thresholds that trigger automatically instead of after the fact. This is where pricing stops being a PDF price list nobody follows and becomes something the system actually enforces, we go deeper on that shift in pricing waterfalls and CPQ. Get this step wrong and step 1's accuracy is wasted, a valid product quoted at the wrong margin is still a bad quote.

Step 3: Quote, document, approval, signature

One click produces the quote letter, technical spec, and increasingly CAD drawings, in the right language and template. Swift Lifts collapsed roughly 40 separate pricing workbooks into a single model that now produces a quote with an accurate 3D drawing in minutes, see the Swift Lifts story for how that changed their distributor sales. Approval routing (does this discount need a manager's sign-off?) belongs in this step too, not as a separate manual chase after the quote goes out.

After the quote: order handoff to ERP

The step people forget when they draw "the CPQ process" as three boxes: once the customer signs, that same structured configuration data should flow straight into the order and production system, no re-keying, no transcription errors between what was quoted and what gets built. HMF Cranes runs this handoff across 35 countries from one model, which is arguably where a good Tacton CPQ implementation saves more quiet, compounding time than any of the three steps in front of it. Read the HMF Cranes story for the full picture.

From process to project: how a CPQ implementation actually runs

Everything above describes what the system does once it's live. Getting there is a project, and it's the part of "the CPQ process" that people ask us about most directly when they say they're looking at our "programme." Here's the shape it typically takes.

Add it up and a focused implementation runs 4–5 months from that first workshop to go-live, the same number we quote on about us and stand behind on every proposal. Multi-family, multi-country programmes take longer; see what CPQ implementation actually costs for how scope moves both the timeline and the price.

One thing worth saying plainly, since we sell and implement Tacton CPQ ourselves as a Tacton reseller and partner: the phases above are how we run a Tacton implementation. Other platforms structure projects differently, see our comparison of CPQ vendors for how we weigh Tacton against the rest of the market, partnership fully disclosed.

8 things we've learned from running CPQ workshops

These come from the CPQ Analysis Workshops we run before every implementation, the same workshop referenced above and the one about us describes as the usual starting point.

1. Don't settle for the pre-sales team. The people who run your workshop and demo should be the same people delivering in month four. Ask who's actually in the room later, not just at the kickoff.
2. Keep the model explainable. If your own product experts can't explain why the system rejected a combination, salespeople won't trust it and will route around it. A CPQ model nobody understands is worse than no model.
3. Ride the horse in the direction it's going. Model the product the way your sales conversation actually happens, not the way the engineering catalogue is organized. The catalogue is the output of a good model, not the input.
4. Avoid black-box logic. Rules with no visible rationale get silently worked around the first time they're inconvenient. Every constraint should trace back to a real physical or commercial reason someone can point to.
5. Control scope before you control timeline. Almost every implementation that runs long added scope after the workshop, not because the original plan was unrealistic.
6. Assign an internal owner from day one. The system decays the moment nobody inside your company is responsible for keeping rules and prices current as the product changes.
7. Test with real deals, not demo data. UAT with your actual salespeople quoting actual current opportunities catches gaps that clean demo data never surfaces.
8. Plan for maintenance, not just launch. A go-live date is a milestone, not a finish line, budget ongoing modelling time the same way you'd budget for a live product line.

Common challenges and how we handle them

"The model is too rigid." Usually means the rules were written from the engineering catalogue instead of the sales conversation, see practice 3 above. The fix is re-modelling from how a salesperson actually talks to a customer.

"Nobody trusts the price the system gives." A trust problem, not a math problem. It's fixed by making the pricing logic visible and explainable to the sales team, not by adding manual override paths that quietly reintroduce the errors CPQ was meant to remove.

"It was fast at go-live and has gotten slower to change since." A sign the internal owner from practice 6 never got assigned, or moved on without a handover. Ongoing modelling capacity is not optional, we cover realistic numbers for it in what CPQ costs.

What to measure once you're live

Three numbers tell you honestly whether the process is working: quote turnaround time (request to sent quote), quote error rate (how often a sent quote needs correcting after the fact), and time-to-productivity for a new salesperson or distributor before they stop escalating to a product expert. If none of these are improving within the first quarter post-go-live, something in the model or the rollout needs attention, not more patience.

Where to go next

If you haven't yet, start with what CPQ is for the software side of this process, or read 9 mistakes to avoid when implementing CPQ if you're earlier in the decision than the process itself. When you're ready to talk specifics, book a meeting, the first conversation is the same Analysis Workshop described above, not a scripted demo.

Frequently asked questions