Automating Technical Customer Enquiries: From Email to a Verifiable Quotation Draft

At first glance, a technical customer enquiry often looks straightforward: an email, two attachments and a request for a quotation. The real work begins during processing. Which version is required? Is the drawing current? Are quantities, material or delivery location missing? Does the requested variant fit the product range? And who can make a binding assessment of technical feasibility?

This is precisely where automation becomes useful. Not because a language model should make price commitments or send a quotation on its own, but because much of the preparation can be structured: assigning documents, capturing details, detecting missing information, finding approved knowledge and preparing a transparent draft.

The point is this: the email inbox is not what is being automated. What is automated is a clearly defined workflow between the enquiry, knowledge, systems and approval.

Anyone who begins with the question “Which model should we use?” is usually one step too early. First, the company must understand what actually happens today. One representative enquiry is enough to begin.

For this enquiry, map the path from receipt to quotation:

1. Input: Through which channel do the message and attachments arrive?
2. Assignment: How does the team identify the customer, project, product group and responsible person?
3. Clarification: Which required details, contradictions and technical questions are checked?
4. Knowledge: Which data sheets, price versions, rules and previous solutions are consulted?
5. Draft: Which information is prepared for costing, follow-up questions or the quotation?
6. Approval: Who checks technical feasibility, price, availability and legal commitment?

This map reveals two things: recurring tasks that can be automated effectively, and decisions that still require subject-matter responsibility. Both belong in the same process.

Not every step needs AI. Fixed rules are usually easier to test and operate for unambiguous checks. Generative AI becomes useful when language, different document formats or multiple possible formulations are involved.

This separation is more than technical housekeeping. It makes troubleshooting easier. If a material specification is missing, it must be clear whether it was absent from the original, lost during extraction or overwritten during transfer to another system.

Many companies first think about the finished quotation text. That is often not the best starting point for a pilot. Greater value can be created earlier by determining whether an enquiry is ready for specialist processing at all.

Each enquiry type needs a small information model. It does not describe every conceivable field, but the information without which the next step cannot proceed meaningfully. For a technical component, this might include:

• product or product group,
• dimensions and tolerances,
• material and surface finish,
• quantity and requested date,
• applicable standards or customer requirements,
• drawing number and version,
• delivery location and any special testing or documentation requirements.

This is a simplified example, not a universal catalogue of required information. The actual attributes come from the company’s own quotation process. That is an important part of the groundwork: specialist knowledge that currently exists only as routine in the minds of individual employees becomes visible as verifiable logic.

The result must not invent missing information. If a detail is absent, it is marked as missing. If the email and drawing contradict each other, the system creates a follow-up question. A system that exposes uncertainty clearly is more valuable in a quotation process than one that elegantly conceals every gap.

A language model alone is not enough to classify an enquiry. It does not automatically know the current prices, the approved product variant or the latest technical guideline. This knowledge must come from existing systems and documents.

RAG, which combines a language model with targeted retrieval from approved sources, can help here. The European Data Protection Supervisor describes RAG in simplified terms as the interaction of retrieval and generation, while also stressing the need to consider sensitive data, permissions, currency and possible manipulation of sources.

For the quotation process, this means:

• Every item of information used needs a visible source.
• Document version and validity must be visible.
• Retrieval may use only content the respective person is permitted to access.
• A similar previous order is a useful indication, but not proof of technical suitability or a current price.
• If no reliable source is available, the system must ask for clarification or stop.

Whether RAG is necessary depends on the sources. If product attributes are cleanly structured in the ERP or PIM, a direct query is often better. RAG is most useful where relevant knowledge is contained in data sheets, guidelines, manuals or other longer documents.

New automation must not become the next data silo. It needs to define which system remains authoritative for each type of information.

One possible allocation of roles:

• CRM: customer, contact, sales opportunity, communication and processing status
• ERP: items, terms, costing, availability and commercial document
• DMS: original documents, versions and traceable filing
• Knowledge system: approved technical sources with retrieval and permissions
• Automation layer: handoffs, validation rules, logging and escalations

This is not a prescribed architecture for every system landscape. In some companies, one system performs several roles. What matters is preventing different systems from silently maintaining conflicting versions of the same case.

Write access should be introduced gradually. A pilot can initially read information only and provide a draft in a review interface. Only after assignment, permissions and error handling work reliably should the company decide which data may be written back to the CRM or ERP under controlled conditions.

The NIST AI Risk Management Framework recommends clearly documenting the scope, limitations, potential cost of errors and roles for human oversight. This is a sensible operating principle even outside formal high-risk scenarios.

In technical sales, the company must therefore define in advance what the reviewer can actually see and decide:

• original enquiry and attachments used,
• extracted attributes with source locations,
• missing or contradictory information,
• product and knowledge sources used,
• assumptions that still need confirmation,
• changes since the previous review,
• approval record and responsible person.

Approval is meaningful only when sufficient time, expertise and decision-making authority are available. A green button at the end of an opaque process is not effective oversight.

The BSI report on generative AI models assigns risks not only to the model but to the entire lifecycle and the specific use. For a quotation process, that means assessing the data source, processing, output, system access and operation together.

A sensible pilot does not begin with every product, every customer and a complete ERP integration. A limited enquiry type with enough genuine, redacted sample cases is a better starting point.

Record baseline values before building the technical solution:

The result is a clear decision: continue, make targeted improvements or stop. A pilot is valuable even when it shows that data, responsibilities or the existing process must be improved first.

The greatest impact does not come from making a quotation generator as autonomous as possible. It comes from bringing fragmented information together earlier, exposing missing details and giving specialists a transparent draft instead of a blank document.

This requires a clear process, reliable sources, defined system roles and genuine approvals. Only then should the company decide where rules, RAG or generative AI can make the greatest contribution.

The Technical Enquiry to Quotation solution shows the complete target state. If the first task is to determine which steps in the existing process are worth automating, the Quotation Process Assessment der passende Einstieg. Für eine breitere Einordnung weiterer Anwendungsfälle führt die AI Consulting for Machinery Companies direkt zum persönlichen Beratungstermin.

Sources reviewed on 9 August 2026. This article describes a process and decision model, not legal advice or a system architecture that can automatically be applied to every company.

• NIST: AI Risk Management Framework – Core
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• European Data Protection Supervisor: Retrieval-Augmented Generation (RAG)
• BSI: Generative AI Models – Opportunities and Risks for Industry and Authorities