9 Mistakes to Avoid When Implementing CPQ

We've run CPQ projects since 2000, most of them with Tacton CPQ for manufacturers. The same handful of mistakes keep showing up, project after project, industry after industry. None of them are exotic. All of them are avoidable if you know to look for them before they cost you a delayed go-live or, worse, a system nobody trusts. Here are the 9 we see most.

1. Not knowing what you actually want to sell

The single most common mistake is starting to build configuration rules before anyone has agreed what "sellable" means. We learned this the hard way on a project in Italy: engineering helped us define a configurator with hundreds of technical questions, but sales only cared about three or four of them when talking to a customer. The model was technically correct and commercially useless. Before any rule gets written, get sales, engineering and product management around the same table and agree the sellable structure, the configurator should encode the sales conversation, not the engineering bill of materials.

2. No executive sponsor

CPQ projects generate constant small disputes, which options are in scope, who approves which discount, whose product line goes first. Without someone with real authority to make those calls, every disagreement stalls the project for a week while people escalate informally. We've seen projects drift six months past their target date for exactly this reason, with the software itself untouched the whole time. Find a sponsor, commercial director, sales VP, sometimes the CEO in a smaller manufacturer, before kickoff, not after the first stalemate. In practice this person doesn't need to attend every workshop; they need to be reachable within a day when sales and engineering disagree on scope, and willing to actually decide rather than schedule another meeting about it.

3. Underestimating the people side

A CPQ rollout changes how salespeople and distributors actually work, and that's harder to manage than any rule engine. The measure of a project that got this right isn't a demo, it's silence. After HMF Cranes went live across its 14-market dealer network, not a single distributor called with questions. That's the result of training, rollout communication and distributor buy-in done properly alongside the technical build, not an afterthought bolted on the week before go-live. Read the full HMF Cranes story for what that rollout looked like.

4. Trying to launch the full scope in one release

Ambition kills CPQ timelines. Teams try to model the entire product catalogue, every market, every edge case, in a single release, and the project either slips for a year or launches with rushed, unreliable logic. We ship the first release with roughly 80% of the eventual scope: the product lines and options that cover most of real quote volume. The remaining long tail gets added in fast follow-on releases once the model is proven with real sellers and real customers, not in a lab.

5. Only involving sales in the workshops

Sales knows what customers ask for. Engineering knows what's actually buildable. Finance knows what's actually profitable. Projects that only consult sales end up with configuration rules that look right in a demo and break the first time a genuinely unusual order comes through, because nobody with engineering or pricing authority was in the room to catch it. The fix is structural, not procedural: put engineering and finance stakeholders in the same discovery workshops as sales, from week one. It costs a few extra hours of calendar time up front and routinely saves weeks of rework once the model meets real orders and someone from engineering finally sees a rule they would never have signed off on.

6. Fighting the tool instead of adapting the process

Some teams try to force CPQ to replicate an old broken process exactly, instead of asking whether the process itself should change. On one project, rather than build a double-approval discount workflow that mirrored an old spreadsheet habit, we simply showed the rep the discount's effect on margin in real time. Sales reps preferred to lower the discount themselves so they could keep moving, and the approval bottleneck disappeared without a single extra workflow step. The tool usually isn't wrong, the process it's being asked to copy often is.

7. Black-box pricing and configuration logic

If sellers can't see why a configuration is invalid or why a price landed where it did, they stop trusting the system and go back to email and spreadsheets to "double-check." Rules and pricing logic need to be visible and explainable at the point of use, a rejected option should say why it's rejected, and a price should be traceable to the rule that produced it. Governance over who can change pricing logic matters here too, undocumented changes are how black-box logic happens in the first place. A useful test during acceptance: put a rule or a price in front of the person who will actually use it and ask them to explain it back to you. If they can't, the logic isn't ready to ship, regardless of whether it computes the right number.

8. Letting CPQ become an island

CPQ sitting disconnected from CRM and ERP recreates the exact problem it was bought to solve: data re-entered by hand, orders that don't match what was quoted, and configurations that were valid in the tool but unbuildable once they hit production. Swift Lifts avoids this by pairing Tacton CPQ with real-time CAD from Dynamaker so a configuration is checked and visualized before it's ever quoted, see the Swift Lifts story. CPQ has to sit in a chain with CRM and ERP, not next to it; we cover exactly where each system's job starts and ends in CPQ vs CRM.

9. Not planning for independence after go-live

Go-live is the start of the maintenance job, not the end of the project. Products change, prices change, new options get added constantly, a CPQ model is only as good as its last update. Projects that don't identify and train an internal owner who can maintain rules after the consultants leave tend to decay within a year: rules go stale, sellers stop trusting the output, and the team quietly reverts to spreadsheets. Plan the handover from day one, not as an afterthought at the end of the contract. This is exactly what a disciplined CPQ implementation process should build in from the start.

How we run projects

We structure every implementation to avoid these nine mistakes by design: a scoping workshop with sales, engineering and finance in the room before any rule gets written; a named executive sponsor identified at kickoff; an 80%-scope first release; and a documented handover plan so the model survives after we're gone. That's also why implementation and license cost are two different conversations worth having separately, see what SaaS CPQ actually costs once both are on the table.

Ready to talk about implementation? Book a meeting and we'll talk through your situation, no prep needed.

Frequently asked questions