From Requirements to Clarification Questions: Systematically Resolving Incomplete Customer Enquiries

A technical enquiry rarely arrives as a neatly completed dataset. An email states the requested deadline, a PDF contains the technical description, a spreadsheet lists quantities, and a drawing shows a variant that the text does not mention. For sales and engineering, the real work therefore often begins before the quotation: identifying what can already be relied on and what still needs clarification.

For this, we present our working model for a clarification list here. It is not a universal standard, but a practical structure for a workshop or a limited automation pilot. The aim is not to answer every enquiry automatically. It is to produce a traceable list of questions that makes unresolved decisions visible.

An empty mandatory field is relatively easy to spot. Details that appear complete but do not fit together unambiguously are harder to identify: a quantity without a unit, two different revision levels, or a requested delivery date without an agreed scope of supply.

A useful clarification question should therefore connect four pieces of information:

• Observation: What was found in the documents?
• Source reference: Which email, file, table or drawing contains the information?
• Clarification needed: Which specific decision or additional detail is missing?
• Impact: Which next step is waiting for the answer?

Practical Tip: Instead of writing “information missing”, state both the information available and the decision still needed. This makes it easier for the recipient to give an unambiguous answer.

For an initial review, an enquiry can be divided into five areas. This helps organise the work; subject-matter experts must decide which questions are relevant to the individual company.

A controlled workflow can be organised into six steps:

1. Bring inputs together: Assign the email, attachments and existing case data to one enquiry.
2. Extract details: Capture relevant values and passages without yet treating them as correct or binding.
3. Preserve source references: Keep each extracted detail linked to its source and identifiable document version.
4. Check rules: Check defined mandatory information, units, permitted ranges and dependencies.
5. Flag conflicts: Identify ambiguous, contradictory or unassignable information as requiring clarification.
6. Approve clarification questions: A responsible subject-matter expert reviews the priority, wording and recipient.

The result is not yet a quotation draft. It is a traceable working basis that helps sales and engineering decide which information must be obtained first.

Not every review step needs generative AI. For a dependable process, separate the technical components according to their task.

Practical Tip: Have the system flag gaps first, rather than filling them automatically. An explicitly identified uncertainty is more useful to the quotation process than a plausible assumption without a confirmed basis.

Working through each file separately can easily produce several questions about the same issue. Grouping them by decision is usually clearer for the recipient. One possible framework distinguishes between:

• Blocking: Technical selection or costing cannot begin without the answer.
• Variant-defining: The answer determines which version or option will be offered.
• Confirmatory: An assumption is possible, but should be confirmed before it is used further.
• Downstream: The information is needed for the quotation text, delivery or documentation, but does not block initial costing.

This prioritisation is also a working structure. Whether a point actually blocks progress depends on the product, risk and internal workflow.

Suppose an enquiry contains a drawing at revision B, a bill of materials at revision C, and an email stating “delivery by the end of October”. The system should not automatically fill in technical values from this. A traceable clarification list could instead look like this:

The connection between finding and question matters. It makes clear why the question was raised and which document needs updating once the answer is received.

For a limited test, a table with these columns is sufficient to start with:

• Case or enquiry ID
• Review area
• information found
• source and document version
• unresolved clarification question
• impact or priority
• responsible role
• answer and approval status

Practical Tip: Add a column titled “How could we have detected this gap automatically?” After a few real cases, it becomes clear which checks can work as fixed rules and which still need expert judgement.

A pilot should not be judged by how many questions the system produces. Instead, assess whether the questions are useful for the next steps:

• Is each question linked to a specific source reference or rule?
• Are identical clarification points from several files brought together?
• Do inconsistencies remain visible instead of being silently replaced by an assumption?
• Can a subject-matter expert edit, reject or add to a question?
• After an answer is received, is it clear which data and documents were updated?

To prepare for this kind of pilot, use the Data Inventory Before Quotation Automation. We describe the overall process from incoming enquiry to a reviewable draft in our article Automating Technical Customer Enquiries.

A good clarification list does more than reveal missing fields. It connects details, sources, inconsistencies, impacts and responsibilities. This creates a distinct, controllable step between an incoming enquiry and a quotation draft.

Rules can handle unambiguous checks, search and RAG can provide approved knowledge, and a language model can group unresolved points and phrase them clearly. The expert decision about which question to ask and which basis to use remains separate. To structure this clarification step for your own process, the Quotation Process Assessment is a suitable starting point.

The quotation process assessment costs EUR 1,900 excluding VAT. It covers one process, three to five sample enquiries, up to four systems, two joint meetings, analysis, a pilot plan and one revision round. Implementation is quoted separately.