Industrial RFQ Intake Checklist: What Sales Needs Before Quoting

Direct answer: an industrial RFQ should contain enough commercial and technical context to decide whether the opportunity fits, who owns it, what is missing, and whether estimating can begin. The form should not try to complete the engineering work. It should create a reliable handoff and a visible exception path.

Most RFQ friction is not caused by one missing field. It comes from several intake channels, inconsistent terminology, attachments with hidden requirements, and different teams needing different information. A website form, distributor email, tender document, and salesperson's note may all describe the same opportunity at different levels of completeness.

Use two gates: qualification and quote readiness

Do not make every buyer answer every engineering question before sales can respond. Split the workflow into two decisions.

• Qualification gate: is this a real opportunity the company can and should pursue?
• Quote-readiness gate: is there enough verified information for application engineering or estimating to begin?

This distinction keeps the first interaction proportionate. A buyer exploring fit should not face the same burden as a procurement team issuing a detailed specification.

1. Buyer and opportunity context

• Company, location, website, and contact role
• End user, EPC, OEM, distributor, consultant, or other relationship to the project
• Project or opportunity name and internal reference
• New installation, replacement, expansion, maintenance, or emergency requirement
• Current project stage and expected decision date
• Whether the request is budgetary, technical, or a formal tender response

The relationship to the project matters. A consultant writing a specification, an EPC preparing a package, and an operator replacing failed equipment may need the same product family but a different response, evidence set, and follow-up owner.

2. Scope and line items

• Requested product, service, system, or outcome
• Quantity and unit of measure
• Required interfaces, accessories, spares, commissioning, or training
• Known manufacturer, model, drawing, tag, or material reference
• Alternative products permitted or prohibited
• Which line items are mandatory, optional, or still being defined

Preserve line-item structure when extracting data from documents. Collapsing several tagged assets into one summary can destroy the relationship between quantity, duty, material, and delivery requirement.

3. Application and operating conditions

This section must be designed with application engineers. Typical fields may include medium, duty point, pressure, temperature, flow, load, dimensions, environment, material compatibility, utilities, control interface, hazardous-area classification, and expected operating profile. The exact set should vary by product family.

Never let an AI system silently infer a missing safety- or performance-critical value from a similar request. Missing information should produce a visible question, an assumption requiring approval, or escalation to a named specialist.

4. Standards, quality, and documentation

• Applicable standards, codes, certifications, and approved-vendor requirements
• Inspection, testing, traceability, and documentation expectations
• Cybersecurity, data, export-control, or site-access constraints where relevant
• Required drawings, data sheets, calculations, declarations, manuals, and language
• Deviation process and whether alternatives must be listed separately

These requirements often sit in attachments rather than the email body. The intake workflow should preserve the source reference so a reviewer can trace each extracted requirement back to the document and page.

5. Delivery and commercial timing

• Ship-to or project location
• Required-on-site date and whether it is fixed or indicative
• Quotation deadline and time zone
• Incoterms, currency, validity period, warranty, and payment expectations when known
• Framework agreement, contract, or approved supplier context
• Named competitors or incumbent solution only when lawfully and appropriately recorded

6. Attachments, privacy, and record ownership

Record the source channel, original message, attachments, version, and who may access them. Avoid asking buyers to upload sensitive plant, personal, or controlled information before the purpose and handling are clear. Large or confidential packages may require a secure exchange rather than a public form.

Choose one system of record for the opportunity. The website, inbox, extraction service, and automation layer can support intake, but the approved facts, owner, status, exceptions, and next action should not split across several invisible stores.

A simple completeness status

• Ready to qualify: buyer, relationship, scope, timing, and next decision are clear.
• Ready for technical review: product-specific mandatory inputs and source documents are present.
• Clarification required: named fields are missing, contradictory, or unverified.
• Exception review: safety, compliance, strategic, commercial, or unusual application risk requires a specialist.
• No-bid or nurture: reason is documented and a proportionate next action is assigned.

What to automate first

The safest first automation usually reads and organizes the request rather than deciding the solution. It can identify line items, extract candidate fields with source references, detect duplicates, compare completeness against a product checklist, route by territory or application, create a CRM summary, and draft a clarification message.

Measure reviewer acceptance, corrected fields, missed requirements, false flags, routing accuracy, time to first useful response, and human overrides. Keep the original document and an audit trail. Expand the boundary only when evidence shows the narrower step is reliable and adopted.

What not to automate first

Avoid automatic technical selection, exception approval, contractual interpretation, final pricing, or delivery commitment when the data and accountability model are immature. Those outputs can look plausible while carrying disproportionate commercial or safety risk.

ShiftNode's view

A better RFQ flow is not a longer form. It is a staged conversation with a clear data contract, specialist branches, source traceability, and an honest stop when information is missing. Once that foundation exists, AI can reduce administrative effort without pretending to replace technical judgment.