They’d followed the list. Not just any list — the list. Five tidy bullet points on CPQ-ERP integration.
Use a purpose-built CPQ.
Don’t overbuild — go prebuilt.
Standardize your data.
Think about scalability.
Get your teams involved early.
The team had printed it. Highlighted it. Presented it to the steering group.
By the book, they were on track.
But three months after launch, the quote cycle was slower than before.
Production was fielding daily change requests.
Sales had a shared spreadsheet called “quote hacks.”
What happened?
Checklists are clean. Real integration is not.
It turns out, ticking boxes isn’t the same as solving problems.
“Use a purpose-built CPQ” doesn’t help if you model it like an ERP form.
“Go prebuilt” skips over the nuance of what those connectors don’t do.
“Standardize your data” — sure. But which system owns the truth? And what happens when they disagree?
These aren’t footnotes. They’re the real work.
Integration isn’t about choosing the right tools — it’s about making them talk. About reconciling the deep weirdness of business rules, engineering structures, pricing logic, and human workflows.
You don’t get that from a five-step diagram.
You get it from asking harder questions. From sitting in on the messy meetings between sales and IT. From understanding why the ERP data model was set up like that in the first place. From mapping how product complexity actually flows through a quote.
Because integration is not a thing you install. It’s a thing you design.
So next time you see a checklist for CPQ-ERP success — pause.
Then ask:
What’s hiding between these steps?
What assumptions are we making?
What happens when this pretty diagram hits real complexity?
Checklists are a fine place to start. But they’re a terrible place to stop.