How to Build a Pump Configuration Model

Building a good configuration model is part engineering, part product management, part stubborn cleanup. Done well, it'll run your quoting for years and quietly make your sales team look brilliant. Done badly, you'll be rebuilding it every six months and wondering why the platform never feels stable.

Most of the failures aren't technical. They come from skipping the unsexy work of mapping the model before touching the software.

Start with one product line

Don't try to model everything at once. Pick one product line that represents a meaningful chunk of your quote volume and start there. You'll learn things in the first build that you'd rather not learn while modeling everything in parallel.

Pick a product line where you have a senior engineer who can dedicate a few hours a week, where the option set is well-understood internally, and where pricing is reasonably stable. Avoid your most political product line on the first pass.

Map the option groups

List every option group a customer has to choose from. For a typical centrifugal pump that's usually size or model, materials of construction, seal arrangement, motor, drive, coatings, and accessories. Some product lines have ten option groups. Some have thirty.

Keep the groups in the order a rep would naturally walk through them. The model should feel like a guided conversation, not a maze of dropdowns the rep has to bounce around. Group order matters more than people expect.

Write the rules down

Sit with your senior engineers and write down the rules they apply by instinct. Compatibility, dependency, visibility, defaults. Use plain language first. Translate to the CPQ rule engine second.

You will discover rules nobody knew were rules. The senior engineer will say things like 'oh, we never quote that motor with that seal, of course we don't.' Write it down. That's a rule. The fact that everyone on the team 'just knew' is exactly why it needs to be in the system.

Aim for a written rule list of 50 to 200 entries for a typical product line. If you've got less than 30, you haven't dug deep enough. If you've got more than 500, you're modeling things that should probably be defaults or options instead.

Price everything live

Pricing logic belongs in the same model as configuration. Base prices, material adders, option pricing, customer multipliers. If pricing lives in a separate spreadsheet, you've split the model in half, and the spreadsheet will always win the version control fight.

Build your pricing structure with the edge cases included from the start. Customer-specific contracts. Distributor discounting. Region-specific surcharges. Volume tiers. Build them in once, and pricing becomes a non-event on every future quote.

Test with real quotes

Pull twenty of your most recent real quotes and rebuild them in the new model. You'll find gaps. Fix them. Run twenty more. Look for cases where the model produces a different answer than what the engineer originally quoted, and figure out which one was right.

When the model handles a representative slice of your business without intervention, you're ready to roll out. If you're still finding meaningful gaps after a hundred test quotes, you have more rules to capture before going live.

Common traps to avoid

Modeling for completeness instead of for the 80% case. You'll never capture every edge case. Build for the bulk of quotes and let exceptions go through a manual path.

Letting one product line's quirks bleed into your global rule set. Keep product-specific rules scoped to the product. Your reusable rules library should be small and clean.

Building in too much default behavior. Defaults are powerful but they hide configuration choices. If you default everything, the rep stops thinking, and you ship pumps that weren't actually right for the application.

Treating the first build as the final build. The model will need ongoing maintenance. Plan for that on day one, not after the first product change forces it.