A manufacturer signs a CPQ contract, assigns an internal project lead, kicks off with the vendor's implementation team, and gets a go-live date on the calendar. Three months later, the system is technically live. Reps have logins. A few quotes went through the new tool in week one. By week three, half the team is back to spreadsheets.
This is a common pattern, and it doesn't trace back to the software. It traces back to five decisions that either weren't made or were made wrong before anyone touched the configuration. Each one is recoverable if you catch it early. If you don't, you don't find out until go-live, which is the worst possible time.
The most reliable way to misconfigure a CPQ is to open the product before you've mapped your current quoting workflow. Implementation teams need to know how a quote actually moves through your organization: who builds it, who reviews it, what information gets pulled from where, and what the handoff looks like between sales and operations.
Without that map, the configuration reflects the vendor's default assumptions, not your process. Reps then encounter a workflow that doesn't match how they actually work, and they route around it. The fix is to spend the first two weeks of implementation in discovery, documenting the current state before a single feature gets configured.
Implementation teams ask for the price book. At a typical manufacturer, three different people send three different versions of it. One is from the ERP. One is a spreadsheet a rep has been maintaining. One is a PDF from two years ago that someone dug out of a shared drive.
The implementation team has to build against something, so they pick one. If they pick the wrong one, every quote the new system generates will be wrong in ways that are hard to trace until a customer notices a discrepancy. The right move before implementation starts is to designate a single source of pricing truth and verify it against the ERP. That decision sounds simple. It often surfaces months of pricing drift that no one realized had accumulated.
Most companies have a formal discount approval policy. Discounts over 15% require manager sign-off. Deals over $50,000 require VP approval. The policy is documented somewhere. Implementations get built to match it.
The problem is that the policy and the practice are often different. In reality, the VP approves anything a trusted rep asks for without looking at the number. In reality, the 15% threshold gets flagged but almost always waved through. Building rigid approval routing around policy theater creates friction without adding control. Before configuring approval logic, interview the people who actually approve deals and find out what they're really looking for. Build around that. The documented policy can live in the system as a floor, but the configuration should reflect how decisions actually get made.
The integration between CPQ and ERP is the piece that makes quotes accurate: current pricing, real inventory levels, actual lead times. It's also the piece that's most likely to get kicked to a later phase because it's technically complex and it's easy to rationalize a workaround.
The workaround is manual data entry. Someone updates the CPQ price book periodically. Someone checks inventory separately before promising a delivery date. When it works, it adds hours to every quote. When it doesn't work, a quote goes out with wrong pricing or an impossible delivery date. "Quoting is a free-for-all" is a direct consequence of ERP and CPQ operating as separate systems. Pushing the integration to phase 2 means going live with a system that can't actually do the job it was bought to do.
Go-live is not training. A thirty-minute demo the week before launch is not training. Training is structured, role-specific, and followed up with reinforcement in the first two weeks of real use.
Most CPQ rollouts treat training as a checkbox: schedule a session, mark it done. Reps leave the session without having built a real quote in the system. The first time they need to quote under time pressure, they fall back to what they already know. One VP of Sales described the result plainly: "Spent nearly six hours quoting this... and getting errors." That was with their old process. Going back to it after a CPQ launch is a signal that training didn't happen at a level that changed behavior.
The fix is to structure training around real scenarios before go-live, then have a designated person available for the first two weeks to answer questions in real time. The goal is to get every rep through at least five live quotes in the new system before they're on their own.
If reps aren't quoting primarily in the system by day 90, the implementation didn't fail at day 90. The failure happened at day 1, in one of the five decisions above. Day 90 is just when it becomes visible.
A CPQ rollout that works looks like this: by day 30, pricing is verified and the configuration matches your actual workflow. By day 60, approvals are routing correctly and the ERP connection is live. By day 90, reps are using the system because it makes their job easier, not because they were told to. That sequence is achievable. It requires doing the unglamorous work upfront instead of deferring it.
For more on Quotivity's CPQ, get a demo.
And if you're earlier in your research, The Three Words Every Manufacturer Gets Wrong About CPQ is worth reading first.