AI configurators for building products makers: the product rules they need

What an AI configurator should and should not do#

An AI configurator for a building products maker should turn a dealer's or contractor's request, written in their own words or pulled from a takeoff, into a valid configuration of windows, doors, cabinets or other made-to-order products. It should not invent options, sizes or prices. The rule engine stays the authority on what can be built and what it costs.

That split matters because the natural-language layer is the part buyers see, while the rules are what keep remakes off the shop floor. A configurator that accepts an impossible size-and-glass combination produces either an order the plant cannot build or a product that fails in the field.

Checklist: the rule data an AI configurator needs#

The rule data an AI configurator needs goes well beyond a price book. Assemble it before choosing software, because gaps here cause most configurator failures, whatever the interface.

Each rule needs an owner. Engineering owns performance limits, sales operations owns pricing and lead times, and order entry often owns the synonym list, whether or not anyone has written it down.

• 1Product families, base models and series, with effective and discontinued dates.
• 2Option catalog with codes: sizes, materials, finishes, glass, hardware, screens, grilles and accessories.
• 3Size limits by model and option, including minimums, maximums and allowed increments.
• 4Compatibility rules: which glass, hardware, finishes and accessories work together.
• 5Engineering and performance limits, such as structural ratings, impact and safety glazing requirements, and local code variations.
• 6Pricing rules: base prices, option upcharges, size-based pricing, dealer tiers, freight and order minimums.
• 7Lead times by option, plant and season.
• 8Measuring and handing conventions, such as unit size versus rough opening and the side from which handing is viewed.
• 9Synonyms: the names dealers and installers actually use for options.

Where product rules hide today#

Product rules at most building products makers are scattered across systems, and some exist only in experienced people's heads. Finding them is the slowest part of a configurator project, so map the sources first.

How historical orders validate the rules#

Historical orders validate a rule set because every order the plant built and delivered without trouble should pass. Replay past orders through the rules, then study the failures and the near misses.

Run the replay again after every rule change. The order history becomes a regression test, and it is also how you judge whether a vendor's AI configurator handles your products before you sign.

Mistakes to avoid when adding AI to a configurator#

The most common mistake when adding AI to a configurator is letting the language model fill gaps in the rules. If a dealer asks for a finish the catalog does not list, the tool should say so and offer valid choices, not pick the closest-sounding code. Build that behavior into acceptance testing, using real dealer emails that contain ambiguous or invalid requests.

Other mistakes are quieter. Teams load the price book but skip lead times, so the configurator promises dates the plant cannot meet. They test on clean sample requests instead of the messy takeoffs and marked-up PDFs dealers actually send. And they retire the order entry specialist's review step before the replay results show the rules are complete.

• 1Require the tool to cite the rule or catalog entry behind every option it selects.
• 2Test with real historical requests, including the ones order entry had to call the dealer about.
• 3Keep a human review step for any configuration the rules flag or the tool marks as uncertain.
• 4Log every correction order entry makes, and review the log as a source of missing rules.

Illustrative example: a door maker connects email orders to its rules#

Illustrative: a fictional maker of commercial doors and frames sells through distributors who email hardware schedules and marked-up PDFs. Order entry staff translate each request into ERP order lines, applying rules they learned over years on the job.

Before adopting an AI configurator, the company writes down its rules from the ERP item master, engineering's fire-rating limits and a series of interviews with its most experienced order entry specialist. It then replays historical orders. Many failures trace to rules no one had written down, such as which frame profiles take which hinge preparations, and remake tickets point to a few combinations the old configurator allowed.

The AI tool now drafts order lines from distributor emails, the rule engine checks them, and order entry reviews anything flagged. The specialist's knowledge sits in the rule set rather than only in one person.

Who owns the rule data and order history#

A building products maker usually owns its product rules, price books and order history, but some inputs come from others. Architects' hardware schedules and specifications are project documents with their own ownership terms, dealer agreements may limit use of dealer-supplied customer data, and residential orders can carry homeowner names and addresses.

Order histories linked to changes, remakes and service outcomes are operational records of the kind AI developers use to train and evaluate sales and quoting agents. The SourceX Enterprise Data Value Framework credits domain expertise, human-generated signal and data cleanliness, and counts privacy burden against net value. SourceX handles rights and preparation through the SourceX five-step transaction, starting from a metadata-only fit check, with the manufacturer approving each step.