How the configurator reaches an answer
Three outcomes, no dead ends. Every path ends with a person to talk to and a record of what the engineer was trying to build.
It educates before it qualifies
The tool teaches an engineer what is possible. Selling is what the follow up conversation is for.
Nothing disqualifies
Order quantity never gates the experience, and an unsupported combination escalates rather than returning nothing.
Modification is a first class answer
Most revenue sits between the catalog and a blank sheet. The middle outcome makes that visible to a prospect who assumed it was catalog only.
The rules stay editable
Product data is a spreadsheet, not code. Updating a seal option should not require a development cycle.
Pyvot working notes, shared deliberately
What this prototype is running on
Pulled from the ABCO Configurator Variable and Rules Intake workbook, September 2026. The gaps below are the difference between a demo and a working tool.
1 of 13 product categories has any data
The workbook's model row named a 120BV Series, which does not appear anywhere in Anderson Brass's published catalog. The prototype was re-based onto the 3211BV Series, a real three way instrumentation ball valve, using figures taken from ABCO's own spec sheet. Every other series is still a placeholder.
5 of 6 configuration rules are unconfirmed
Only the order quantity rule is confirmed. Three are informed guesses from general valve engineering, one was rescoped once we found that size limits vary by series, and one is waiting on a list only ABCO holds.
4 variables need ABCO's own answer
Stem packing, actuation options, certifications and mounting interface standards. Two are partly answered by their own site, since an EA Series electric actuator is sold as a product line and select 360 and 3200 valves carry UL refrigerant listings. What is missing is the mapping to series.
Product data coverage
Every product category crossed against every variable. The current site already publishes a downloadable spec sheet for most series, and those sheets carry part number tables, end connections, pressure ratings, materials and dimensional drawings. Most of what looked missing is transcription work, not an open question for ABCO.
9%
of the matrix is confirmed in the workbook
55%
more is already published on the current site and can be transcribed rather than asked for
Gap register
| Gap | What it blocks | Owner | Priority |
|---|
What an engineer will expect that we cannot answer
Reviewed as a design engineer specifying a component, not as a marketer. These are not prototype shortcuts. Each one is genuinely absent from the intake workbook, and several would undermine trust on day one.
| Missing | Why an engineer notices |
|---|
Variable library
This records the intake workbook as written. Where the configurator now uses a figure taken from a published spec sheet instead, such as the 1,500 PSI rating on the 3211BV, the spec sheet wins and the workbook row is what needs correcting.
| ID | Variable | Category | Status |
|---|
Configuration rules
| ID | Rule | Result path | Confidence |
|---|
Pyvot working notes, shared deliberately
How this gets built and who maintains it
A working answer to the question the on-site session left open: can ABCO keep this current without calling a developer every time a seal option changes.
Three layers, three different owners
The mistake to avoid is treating this as one system. It is three, and they change at very different rates.
ABCO owns
Catalog data
Product series, the variables that describe them, the option values under each variable, and which options apply to which series. Changes when a product or an option changes, a few times a year.
ABCO owns
Configuration rules
The trigger and effect rows from the workbook. What a selection requires, excludes, limits, or escalates. Changes rarely, but when it changes it must be fast, because a wrong rule sends real prospects down the wrong path.
Developer owns
The engine and the interface
The code that reads layers 1 and 2, evaluates a configuration, and renders the result. ABCO should never touch this, and should never need to in order to change a product fact.
Recommendation: Webflow CMS holds layers 1 and 2, baked into the page at publish
Model the catalog and the rules as Webflow collections. On publish, render them into a JSON payload on the configurator page, and let the client side app read that payload directly.
This avoids runtime API calls, so there is no API token to protect, no rate limit to hit, and no loading spinner while the tool fetches its own rules. ABCO edits in the Webflow Editor, which they will already be trained on for the rest of the site, and hits publish. That is the entire update cycle, with no developer in it.
The constraint that shapes the schema
Webflow allows only five reference or multi-reference fields per collection, ten on the Business plan. The Product Applicability Matrix is a join of eleven product categories against a dozen variables, so it cannot be modeled as reference fields on the product. It has to become its own collection, one row per product and variable pair. That single decision is what makes the rest of this fit comfortably inside Webflow rather than fighting it.
Proposed collections
| Collection | What it holds | Est. items | Refs |
|---|---|---|---|
| Variables | The vocabulary. Name, category, input type, definition, whether it affects the stock versus custom decision, confirmation status. | ~15 | 0 |
| Variable Options | The pick-list values under each variable. Label, parent variable, sort order, engineer-facing note, and a switch for options that always route to custom. | ~60 | 1 |
| Product Series | What ABCO actually makes. Series name, parent family, category, description, the baseline stock configuration, published end type and pressure rating, imagery, spec sheet file. | ~25 | 1 |
| Applicability | One row per product and variable pair. Availability set to standard, optional, custom-only or not applicable, plus a note. This is the matrix tab. | ~150 | 2 |
| Rules | Trigger variable, trigger value, effect type, affected variable, result path, description, confidence, a rule group for conditions that must combine, and the series a rule applies to. | ~30 | 3 |
Five collections, never more than three references in any one, and roughly 290 items in total. The CMS plan allows twenty collections and two thousand items, so there is a lot of headroom for the catalog to grow.
What ABCO can change alone, and what they cannot
| Change | Who |
|---|---|
| Add or retire an option value, such as a new seal material | ABCO, in the Editor |
| Change a product from optional to standard on a variable | ABCO, in the Editor |
| Add a new product series and its applicability rows | ABCO, in the Editor |
| Add a rule that fits the existing trigger and effect grammar | ABCO, in the Editor |
| Edit the copy on any of the three outcome screens | ABCO, in the Editor |
| A rule that needs several conditions combined with AND or NOT | ABCO, only if the rule-group field is built in version one |
| A variable whose value is a curve rather than a number, such as a pressure rating that varies with temperature | Developer |
| A fourth outcome, or a change to where an outcome routes | Developer |
| Anything touching the question flow or the interface | Developer |
Build the rule-group field in version one
Flat trigger and effect rows can only express single condition logic. The first time someone needs "stainless body AND above 600 PSI AND not NSF-61," a flat row cannot say it, and the rule quietly gets hardcoded instead. Once that starts happening the logic splits across two places and ABCO loses the ability to see why the tool said what it said.
A rule-group field, so several rows can be marked as one combined condition, costs very little now and is expensive to retrofit. It is the difference between a system ABCO can own and one they cannot.
The alternative worth naming
Airtable or Google Sheets as the source of truth, synced into the site. It models relationships better than Webflow, and it is literally the workbook ABCO is already filling in, so there is no new editing surface to learn. The cost is a second system to pay for and a sync job to maintain, plus product data living outside the website that hosts it. Worth revisiting only if the applicability matrix grows past a few hundred rows, or if the rules outgrow the trigger and effect grammar. Start in Webflow.
Spec sheets already exist, and they change the plan
The current Wix site publishes a downloadable spec sheet for most series, and several series carry a second overview sheet as well. Those PDFs hold the part number tables, end connection combinations, pressure ratings, materials and dimensional drawings that the intake workbook treats as unknown.
Two consequences. The Product Series collection needs a file field for the sheet, and the configurator should link it on every outcome, which is the most useful thing to hand an engineer. And the migration needs a full inventory of these PDFs with a redirect map, because they sit on two different Wix URL patterns and engineers reach them from search results and saved links.
Update cycle
ABCO edits in the Webflow Editor, publishes, and the payload rebuilds with the site. Quarterly review at minimum, plus ad hoc when a series launches or a material option changes, which matches the cadence in the governance tab of the workbook. The thirty to sixty day internal beta agreed on site should gate the external launch, and during that window the rules panel in this prototype is the right review tool.