AI product selector for technical sales: parameters, rules and datasheet citations

What an AI product selection assistant does for technical sales

An AI product selector for technical sales answers questions such as "which pump do I need for 40 m³/h at 32 m head in seawater" or "which seal fits this valve at 160 °C" by searching your product database for variants that meet the stated parameters, checking your compatibility rules, and replying with the matching variants, the reasons and a reference to the datasheet page. Field sales, inside sales and your distributors get a first answer in seconds, and the application engineer handles the cases the rules cannot decide. The model behind it is a modest one, and it runs on the same company AI server as your other AI tasks.

This guide is for sales managers and managing directors of component manufacturers: pumps, valves, drives, fasteners, sensors, bearings. It explains the parts of such a system in plain words, where the AI helps and where it must not decide, and puts the hardware in one section. Our article on AI for B2B distributors covers wholesalers who search thousands of other manufacturers' datasheets; this one covers a manufacturer selling its own range. A support chatbot for end customers, as in our guide to a server for a customer service chatbot, is a different job again.

The problem is well known in technical sales. A distributor's salesperson has a customer on the phone with a duty point and a medium, the catalogue has hundreds of variants, and the application engineer who knows the range is busy. Wrong selections can come back as returns, warranty claims or lost trust. ki-syndikat.de, a German catalogue of AI use cases for small and medium-sized companies, lists a use case for valve and pump makers that checks order parameters against application rules at order intake, to catch a wrong pressure rating, material or seal type. The product selector moves that check forward, to the moment the variant is chosen.

Why a chatbot on datasheets alone picks wrong variants

A language model is an AI model that reads and writes text. Given a pile of datasheets and a question, it writes a fluent answer, and in technical selection a fluent answer can be wrong in one digit. Datasheets describe one series each, the variants differ in a code at the end of the article number, and the rule that excludes a seal material above a certain temperature may sit in a footnote of another document. A model that reads the five most similar pages, the usual retrieval approach (RAG, retrieval-augmented generation, explained in our guide to RAG on company data), will sometimes combine facts from the wrong pages.

The reliable design splits the work between three layers.

Our design recommendation; it follows the split between data, rules and text used in our guides to text-to-SQL and RAG.

The product database. Many manufacturers already have the variants and their parameters in the ERP, a product information system or the configurator: flow range, pressure rating, materials, connection sizes, voltage, certificates. The AI turns the customer's words into a search over these fields. We recommend a fixed search function that your IT defines, with named parameters, instead of letting the model write free database queries; our article on text-to-SQL on your own server explains the risks of the free form.

The compatibility rules. "Seal material X only up to 120 °C", "this motor not with that frequency converter", "seawater requires duplex steel": these rules belong in software, written by the application engineers and checked on every answer. The AI may explain a rule to the user; it does not decide whether it applies.

The datasheets. Once the variants are found, the AI looks up the datasheet pages that support the answer and quotes them, with document and page, so that the salesperson can check and forward the datasheet to the customer.

How one enquiry from field sales or a distributor is answered

Take an enquiry from a distributor: "Customer needs a pump for 40 m³/h, 32 m head, seawater, 400 V, ATEX zone 1." The system works through it in five steps.

1. Parameters. The model extracts flow, head, medium, voltage and the explosion-protection requirement, and asks back if something essential is missing, such as the fluid temperature.
2. Search. It calls the search function with these values. The database returns the variants whose ranges cover the duty point.
3. Rules. Software checks each candidate against the compatibility rules: materials for seawater, the motor's certificate for the zone. Variants that fail are removed, with the reason.
4. Evidence. The retrieval layer finds the datasheet pages for the remaining variants: the performance curve, the material table, the certificate.
5. Answer. The model writes a short reply: two variants, why they fit, what the customer still has to confirm, and the datasheet pages. If no variant passes, the reply says so and offers the route to the application engineer.

Letting a model call such a function is called tool calling, and current open models support it: the model card of gpt-oss-120b lists "native capabilities for function calling" and "Structured Outputs"; our guide to tool calling in vLLM explains the setup for the IT team.

Pump curves and other diagrams need care. Where the database holds the curve as data points, the search uses them. Where it exists only as an image in a PDF, the AI can find the page but should not read the operating point off the picture; that check stays with a person until your curves are in the database.

Price lists, access levels and distributors

Prices stay out of the model. The model sees neither price lists nor discount agreements. Prices come from the ERP after the variant is chosen, through the existing quotation process, with the access rights you already have. That way no answer can leak another customer's terms, and no price depends on how a question was worded.

Access levels. Internal sales may see all variants, special designs and internal application notes; a distributor sees its approved range and public documents. The access filter is applied to the search and the retrieval before the model reads anything, so the model never holds text the user may not see. Log every question and answer with the user, for quality review and for the moment a customer disputes a recommendation.

Telling users it is an AI. Article 50 of the EU AI Act has applied since 2 August 2026, as the European Commission's page on transparency obligations states. It requires that people interacting with an AI system are informed of it, unless this is obvious, "at the latest at the time of the first interaction or exposure", as the Commission's AI Act Service Desk text of Article 50 puts it. A line at the top of the selector covers this in practice; whether you are the provider under the Act when you build the system on an open model, and what else applies, your legal counsel confirms. Our guide to the EU AI Act for companies using LLMs gives the background.

We supply the server for a product selector and our Private AI/ML service connects it to your product data, rules and datasheets; send us ten typical enquiries and the systems your product data lives in, and our team replies with a proposal for a pilot.

Testing before the sales team relies on it

Collect 100 real enquiries from the sales inbox, with the variant your application engineers chose and why. Run them through the selector and count four things: the right variant among the first two, a correct datasheet citation, a question back where data was missing, and wrong answers given with confidence. The last number matters most, and the rules layer is what keeps it low. Repeat the test after every change to the model, the rules or the data.

Plan the data work. Selection quality depends on the parameters in the database: missing temperature limits, inconsistent units and series that exist only in PDFs show up in the first test. Our guide to preparing company documents for an AI assistant covers that groundwork.

The hardware: a modest model on a shared server

A product selector reads short enquiries, a few datasheet pages and the search results, and writes short answers. We size conversations of 32,768 tokens, which leaves room for several datasheet pages. By our users-per-card rule, 90 per cent of the memory the driver reports less 3 GiB per card, one 96 GB RTX PRO 6000 Server Edition leaves 83.0 GiB usable; gpt-oss-120b takes 60.8 GiB of it and 1.125 GiB of cache per conversation, so one card holds 19 conversations at a time, and a pair running one copy across both cards 93.

How many conversations run at once depends on use, not headcount. With the example values of our guide to sizing a private ChatGPT server by company size, 40 per cent of users active in the busiest hour, 6 questions per hour each, 30 seconds per answer including the search and two model calls, and a peak factor of 2, 40 field sales staff and 200 distributor users give about 10 conversations in flight at the peak by our estimate. Your gateway logs replace these values after the pilot.

Our estimates by the users-per-card rule, 16-bit cache, gpt-oss-120b weights of about 65 GB (60.8 GiB) from its Hugging Face file list (read 25 October 2026); power as for the entry server and the four-card inference node on our AI servers page (cards at 600 W, two EPYC processors, plus 15 per cent).

So the selector needs about half of one card. The rest of the entry server, two RTX PRO 6000 Server Edition cards, two AMD EPYC processors, 384 GB of DDR5 ECC memory and two NVMe drives, serves other departments: the company assistant, AI offer writing for machine builders, order entry or the service assistant. That is the case for running the selector on a company AI server rather than as a separate product: one server, several departments, one place for access rights and logs. A smaller model may answer selection questions just as well, since the database and the rules do the hard part; test it in the pilot. The embedding model for the datasheet search, for example Qwen3-Embedding-0.6B under Apache 2.0 with support for more than 100 languages, is small and runs beside the language model.

The entry server runs on one 230 V 16 A circuit at about 1.8 kW by our estimate and belongs in a server room or a rack. Where questions come from distributors outside your network, the selector sits behind your existing web access with login, and the server itself stays internal.

Notes for the IT team

1. Product data. Expose a read-only search function over the product database with named parameters and units; give the AI account no write rights. Our text-to-SQL guide covers read-only roles if you prefer queries.
2. Rules. Keep compatibility rules in a rules table or the configurator logic, versioned, with an owner per rule; the selector calls them as a function and receives pass, fail and the reason.
3. Datasheets. Index the current datasheets with their document number, revision and language; remove superseded revisions from the index on the day they are withdrawn. For PDF tables and curves see our guide to PDF parsing for RAG.
4. Access. Map roles (internal, distributor, region) to filters on search and retrieval; test that a distributor account cannot reach internal documents.
5. Serving. Run the model with vLLM behind an LLM gateway with keys and logging; vLLM's --api-key protects only paths under /v1, /v2, /inference and /cohere (vLLM 0.32.0 security guide), so keep the engine on an internal network.
6. Languages. Test the selector in each language your distributors use, with enquiries written by them, before you open it to that market.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build AI servers with two or four RTX PRO 6000 Server Edition cards to order, assembled and tested before delivery, with the operating system, NVIDIA driver, CUDA and a container runtime installed on request, on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Our Private AI/ML service, with our engineering partner Vixen.UNO, connects the model to your product data, rules and datasheets; describe your product range and where its data lives, and we propose a pilot with your own enquiries.

FAQ