The 9 mistakes you don't want to do
1. Not knowing what you want to sell — or how
Your CPQ is only as good as the data behind it: product structures, pricing, rules, texts, images. But it's not just about clean data — you need to know what you want to sell and how you want to sell it before you start configuring anything.
Which products go in first? What does the sales flow look like? Who decides pricing? These are concrete problems that need answers before anyone touches the CPQ tool. We've seen projects stall for weeks because the pricing data wasn't ready, or go sideways because nobody had agreed on the product scope. Get this sorted early. It's the least glamorous part of a CPQ project and the one most likely to blow up the timeline.
2. The project lacks executive backing
CPQ touches products, pricing, sales, and IT. If the project is run by one department without executive backing, it stalls the moment it needs a decision that crosses department lines.
You need someone senior enough to break ties, approve scope decisions, and keep the project moving when people disagree about priorities. But it's not just about the sponsor — look inward at the project team too. Do the people assigned actually know both CPQ and your business? Do they have the seniority to make calls? Do they have enough time allocated? We've seen good projects die because the steering committee met once and then forgot about it — and we've seen them struggle because the best people were only available 20% of the time.
3. Underestimating the people side
A CPQ system changes how salespeople, product managers, and distributors work — every day. If you launch without preparing them for the change, you'll get resistance, workarounds, or both.
This doesn't mean a six-month change management program. It means listening to everyone involved: know your sales strategy, know how your reps actually work, know what your customers expect, know your processes. If you skip this, you'll build a system that makes sense on paper but not in practice. The HMF project surprised us — after go-live, not a single distributor called with questions. That happened because the system was built with their input, not just handed to them.
4. Going for the full scope in one release
This is the most common mistake and the most costly. The team defines everything they could ever want, the project scope grows, the timeline stretches, and the organization loses patience before anything goes live.
Be clear about what needs to be achieved and what's out of scope. Know the difference between a blocker and something that's just inconvenient. Ship the first release with 80% of the scope, get it into people's hands, and let them test it for real — not in a demo, but hands-on with actual configurations. A CPQ that's live and useful beats a perfect one that's still in development.
5. Only involving sales
CPQ isn't a sales tool — it's a system that connects product knowledge, pricing, and sales. If you don't involve product management, engineering, finance, and IT in the project, you'll build something that works for quoting but breaks when it hits the rest of the organization.
We learned this the hard way on a project in Italy. Engineering helped us define a configurator with hundreds of questions. When it went live, we realized sales only cared about three or four of them. They didn't understand the rest and didn't want to. The configurator was technically correct but practically useless — because nobody had asked sales what they actually needed to do their job.
6. Fighting the tool instead of working with it
The instinct is to take your current quoting process and force it into the CPQ system exactly as it is. That's a mistake. Most things in a modern CPQ work well out of the box — but only if you let them.
A common example: companies try to squeeze 10-15 workflow states into CPQ because that's how their internal approval process works on paper. In practice, quotes stall in the queue and people go outside the process anyway. The tool isn't the problem — the process was too rigid to begin with.
And not everything should be automated. On one project, quotes above a certain discount level required two approvals — regional and then global sales manager. Instead of building a double approval workflow, we showed a phone number. Sales reps preferred to lower the discount so they could keep moving. The business outcome was better than any automated approval chain would have delivered.
7. Making the configuration logic a black box
It's easy to get outsmarted by your own CPQ. The configuration logic grows, rules get layered on top of rules, and before long nobody can explain why the system behaves the way it does.
Keep it explainable. Keep it simple. If the logic is too complicated to walk someone through, the problem can usually be described in a better way. The goal isn't to model every edge case — it's to build something that your product people can look at, understand, and maintain. The moment the CPQ becomes a black box, you've lost control of it.
8. Building CPQ as an island
A CPQ that isn't connected to your ERP, CRM, or PIM creates double work and data inconsistencies. Prices in CPQ won't match ERP. Product texts won't match the catalog. Sales reps will end up maintaining information in two places.
We split integrations into two categories. Quality integrations — the ones where missing data leads to wrong quotes — go into phase 1. If pricing or product rules aren't synced from ERP, you'll ship errors to customers. That can't wait. Time-saving integrations — the ones that reduce manual work but don't break anything if they're missing — go into phase 2. This keeps the first release focused and gets you live faster without compromising what matters.
9. Not planning for independence
Go-live is the beginning, not the end. Products change, pricing changes, markets change. If no one internally can maintain the CPQ after launch, it drifts out of sync with reality and people stop trusting it.
Your team should be able to update the product logic, refine the user interface, change the pricing, and automate more documents — without calling the consultants every time. That doesn't happen by accident. It means coaching during the project, not just a training session at the end. By go-live, your team should be running it — not waiting for someone else to make changes.
