The checklist that looked perfect

They followed the list. Not a random blog post. The list. Five tidy bullets for CPQ-ERP integration taped to the project room wall. Purpose-built CPQ. Prebuilt connectors. Standardize data. Think about scale. Get teams involved early.

Three months after go live, the quote cycle was slower than before. Production was drowning in change requests. Sales had a spreadsheet called "quote hacks" that everyone swore they didn’t use.

I’ve seen that movie more times than I like to admit. One kickoff in Stuttgart sticks with me. The program manager tapped the slide with the checklist like it was a safety card on a plane. By the book, the plan was flawless. By the field, it was untested.

Checklists are clean. Real integration is not.

"The checklist isn't the plan. It's the agenda for hard conversations."

The conflict the checklist hides

The belief is familiar: if we choose the right stack and tick the right boxes, the rest will follow. It rarely does. Not because the list is wrong, but because it lets teams dodge the work in between the boxes. The work with people, ownership, and tradeoffs that never fit on a slide.

Here’s the core tension. CPQ lives in the art of the possible. What a customer could buy if engineering and pricing say yes. ERP lives in the reality of what exists. What has been built, costed, and shipped before. You need both worldviews. You also need to design the rules of engagement between them.

A checklist papers over that conflict. It gives you a sense of progress while postponing the decisions that decide everything. Who owns which truth. What happens on an exception. Where product logic ends and production constraints begin.

"CPQ is not about automation - it's about correctness."

To be fair, checklists do help align a room. They get procurement off your back and keep the project from wandering. But they are a starting signal, not a flight plan. The distance between bullets is where projects fail.

"Adoption is the only metric that matters."

Design the space between systems

The real work shows up when you take each tidy item and ask the questions it avoids.

  • Beyond "Standardize data" - Who owns the truth? Which system is the master for product structure, customer-specific pricing, and order status. What is the explicit process when two systems disagree. Who decides and within what SLA. How do you audit that decision later when a quote becomes a claim. If you cannot point to an owner and a decision clock, you do not own the truth.

  • Beyond "Use prebuilt connectors" - What doesn’t the connector do. Will it carry your custom fields, variant logic, or a multi-level configured BOM with phantom items. Can it handle tiered and matrix pricing, units and conversions, and price effectivity over time. What happens on versioning, retries, partial failures, and idempotency. How do you trace a quote line to a production order without a human stitching IDs in Excel. If you haven’t rehearsed the failure modes, you have designed for a demo, not for Tuesday morning.

  • Beyond "Get teams involved" - What is the decision flow. Map a real exception. Sales offers a non-catalog variant. Who approves. Where does the request land. How does engineering respond. How does production capacity feed back to the quote. On what clock. This is where the deep weirdness of your business lives. The integration must make that path safe and repeatable.

A few rules I use when I’m neck-deep in this work with clients:

Rule 1: Ownership beats mapping. Data mapping without clear ownership is theatre. Pick a single master per domain - product structure, price policy, customer terms, order status - and write the arbitration rule for conflicts. Example: product variants are mastered in CPQ until a quote becomes an order, then ERP owns the configured BOM. Price policy is mastered in pricing service X, not in spreadsheets. When a conflict appears, the owner resolves within 24 hours and the decision is logged where sales can see it.

Rule 2: Exceptions are the product. Don’t design for the happy path. The 10 percent of quotes that trigger engineering changes will define your timeline and your reputation. Build a path for exceptions that is visible, tracked, and time-boxed. In one Tacton CPQ program, we cut exception cycle time in half by adding a simple status handshake with ERP and a clear veto rule for engineering. No new tool. Just a designed handshake.

Rule 3: Connectors are contracts, not magic. Treat the CPQ-ERP interface like an API contract with human consequences. Write down the fields, the events, the error codes, and the tolerances for latency. Decide what happens when orders are partially valid. Example: allow creation of the purchase order only when the configured BOM has a release tag from engineering. No tag, no order. Make it explicit so people stop guessing.

Rule 4: Explainability or bust. If sales can’t see why a configuration or price is valid, they will route around the system. Make logic visible enough to be questioned. In practice, that means showing rule reasons, price components, and constraints in plain language. I’ve watched adoption jump just by exposing price breakdowns and configuration rationales. Trust follows clarity.

Rule 5: Change is a first-class feature. Governance isn’t overhead. It’s how you ship change without breaking sales. Put a weekly cadence on rule updates, with a small release train and a visible backlog. Require tests for product rules the same way you require QA for code. If a change still needs a project plan, your field will invent workarounds.

"Governance isn’t overhead - it's how you scale change without breaking sales."

Watch for these anti-patterns on your floor:

  • Checklist Theater - The team can recite the bullets, but no one can name an owner for pricing disputes. Meetings feel tidy. Quotes do not.

  • Connector Worship - The belief that a prebuilt connector removes the need to design the data contract. It doesn’t. It only accelerates what you already designed.

  • Form-Modeling CPQ - Recreating ERP forms inside CPQ. You turn a guide into a filing cabinet and then wonder why reps go back to Excel.

  • Rubber-Stamp Governance - A committee that meets, nods, and approves everything. If nothing ever gets rejected, you don’t have governance. You have a calendar event.

If you prefer metaphors, think of CPQ and ERP as structural beams in a building. The beams do different work, but the load paths between them decide whether the floor holds. You can make the beams stronger all day. If the joints are wrong, the building sags where people walk.

So what can you do this week, without waiting for a new budget cycle:

  • Run a truth workshop. In one hour, decide ownership for product structure, pricing policy, customer terms, and order status. Write conflict rules and SLAs on a single page. Publish it where sales and ops can find it. Revisit it monthly.

  • Map an exception end to end. Take the last quote that needed a special. Whiteboard the steps from first ask to delivered order. Mark wait times, handoffs, and why each decision was made. Turn that map into a designed path inside CPQ and ERP with clear states and owners.

  • Rehearse a connector failure. Pull the plug in a test environment. Watch how quotes and orders recover. Decide what the system does automatically, what a human decides, and how you log the event. Write the playbook.

  • Make logic visible. Expose configuration reasons and price components in the quote. If your tool can’t, write a simple explanation layer. People trust what they can see.

I’ve been doing this work since 2000, mostly with Tacton CPQ. The projects that last treat integration like gardening, not assembly. Prepare the soil. Plant clear rules. Prune often. Growth looks boring week to week and impressive year to year.

Do the messy parts on purpose. Decide who owns which truths. Design the handshake. Practice failure. Show your work.

That’s the actual integration.

Integration isn't a thing you install. It's a shared understanding you design.