Industrial OEMs rarely receive a customer request as one clean form. The email may contain the deadline and delivery site. A spreadsheet holds quantities. Drawings define the equipment. A specification adds materials, testing and documentation. The buyer may replace one attachment two days later without saying what changed.
Saving the attachments is easy. The hard part is deciding which files govern the bid, what the customer is asking for, what is missing and whether estimating can start. An inbox rule or OCR model can help with the first step. It has not automated intake until it produces work the next team can trust.
Define “ready for estimating” first
Write the acceptance rule before you choose software. For most industrial OEMs, estimating needs a named customer and site, the requested equipment or duty, quantities, the current technical baseline, the response deadline, requested delivery, open questions and an internal owner. “Email processed” is not an acceptance rule.
The NIST MEP Supplier Scouting Playbook offers a useful check on the fields that matter in a manufacturing request. It asks for process, dimensions, tolerances, performance, materials, certifications, regulations, volume, target price, delivery, packaging and supporting drawings. Your products will need their own fields, but the intake record must cover anything that can change feasibility, cost, acceptance or schedule.
| Part of the record | Question it must answer | Reason to stop |
|---|---|---|
| Request identity | Which customer, site, opportunity and revision is this? | The system cannot make a unique, supported match |
| Technical baseline | Which drawings, specifications and standards govern the bid? | The source set is incomplete, conflicting or superseded |
| Commercial basis | What quantity, destination, due date and delivery did the buyer request? | A missing term changes cost or feasibility |
| Open questions | What must sales, engineering or the buyer resolve? | A material gap has no owner or due date |
| Next handoff | Who can act now, and what will they receive? | The next team would have to reopen the email package |
Map every place an RFQ can arrive
Start the workflow when the business receives the request, not when someone finally logs it. List the shared mailboxes, customer portals, sales inboxes, shared drives and CRM forms that customers use. For each source, record how the automation proves receipt and how it preserves the original package.
A portal download needs the customer, portal request number, downloaded file names and receipt time. An email needs the original message, thread and attachments. A file copied to a shared drive still needs a link back to the message or portal event that supplied it. Without that chain, a reviewer cannot tell whether the active file came from the customer or from an internal working copy.
ISO 10013:2021 reflects the move from paper to electronic records and gives guidance on maintaining and retaining documented information. That principle applies directly here: the intake workflow should control the flow of the record, not turn a governed customer document into detached text.
Treat every new file as a possible change
When the buyer sends a revision, preserve the earlier file. Identify the drawing or document number, compare the revision with the active set and show which quote work may now be stale. ASME Y14.35 defines practices for identifying and recording revisions across engineering product definition data and related documents. Intake is where that control starts for the bid.
A changed drawing can invalidate a material takeoff, a supplier RFQ, a compliance answer or a promised date. The NASA Systems Engineering Handbook calls for traceability between requirements, design documents and tests, and for teams to assess the cost, schedule and design effect of a requirements change. An industrial quote needs the same basic discipline: identify what changed, find the dependent work and ask its owner to review the effect.
- Preserve the original customer message and every attachment.
- Extract document numbers, revision marks and dates where they exist.
- Send duplicate, missing and conflicting files to a named reviewer.
- Record which estimate, supplier package and proposal used each revision.
Turn every material gap into a question
Software can detect that the request has no quantity, delivery location or motor data sheet. It should not decide that an ambiguous operating condition is harmless. Use rules for objective completeness checks. Send technical uncertainty to the engineer who owns the product or application.
Write the gap as a question another person can answer. “Incomplete RFQ” is a status. “Confirm whether the stated 65 °C is ambient or process temperature” is work. The second version can go to the buyer, carry an owner and due date, and close against a recorded answer.
Some gaps should stop estimating. Others can proceed under a visible assumption. Decide that rule by product family. A missing hazardous-area classification may stop equipment selection. A missing shipping contact may wait until order entry. The workflow should show the difference instead of treating every empty field as equally urgent.
The automation should do seven specific jobs
Test these jobs separately. A product can extract fields well and still match the wrong customer. It can identify every file and still miss that the drawing and BOM refer to different revisions. One overall “accuracy” number hides the failure that will reach the quote.
| Job | What the system does | Review point |
|---|---|---|
| Capture | Collects the message, portal export and attachments without changing the originals | Did every source arrive? |
| Identify | Matches the customer, site, request and open opportunity | Is the match unique and supported? |
| Structure | Extracts quantities, dates, product references and required deliverables | Did the parser preserve units and table context? |
| Control | Lists drawings and specifications by document number and revision | Which set is current, and what conflicts? |
| Check | Runs product-specific completeness rules | Which gaps block work, and which permit an assumption? |
| Route | Assigns the request and each open question to a named owner | Can the owner act without repeating intake? |
| Release | Creates the checked package for qualification, engineering and estimating | Did the handoff preserve the sources, assumptions and deadline? |
Five shortcuts that fail in real quoting work
| Shortcut | What goes wrong | What the workflow should do instead |
|---|---|---|
| Summarize the email | The summary omits a requirement buried in a drawing or workbook | Index the package by source and link every extracted requirement back to it |
| Save attachments to one folder | The team cannot tell which file is current or why it arrived | Record the document number, revision and email or portal request it came from |
| Mark the RFQ “incomplete” | Nobody knows the exact question or who must answer it | Create one owned question for each material gap |
| Write everything to CRM | CRM becomes a pile of fields and attachments that engineering still has to interpret | Write approved sales fields to CRM and link the working technical record |
| Auto-release high-confidence results | A plausible value can come from the wrong customer or revision | Require source, match and exception checks before release |
Decide where each record belongs
Name the system that owns the customer, opportunity, product definition, document, quote and task. The intake application can present one case and write approved results back, but it should not create a quiet second master for each object. Store the source identifier, current revision and synchronization state so a reviewer can see what came from where.
The working case does need information that CRM or ERP may not model well: the original request package, document relationships, open technical questions, assumptions and decision history. Link that record to the governed customer and product records. Do not flatten it into a stack of generic CRM attachments.
A clean boundary might put the account and opportunity in CRM, released product data in PLM, material and customer masters in ERP, and the active intake case in Bourne. The exact systems differ by company. The rule does not: one owner for each fact, one record where the team does the work, and approved updates sent back to the source systems.
Example: a pump RFQ changes after costing starts
A buyer sends a data sheet, seven drawings and a workbook for three pump packages going to two sites. The email contains the response deadline. The workbook contains quantities. A project specification defines the hazardous-area requirements and required documentation. One referenced motor data sheet is missing.
Bourne creates the request record, matches the account and opportunity, and lists the received files. Sales owns the question about the missing motor data. Application engineering owns the duty-point review. Estimating can start the unaffected work because the record says which decision still blocks motor selection.
The next day, the buyer sends Rev D of one drawing. The workflow preserves Rev C, shows the changed flange and identifies that the estimate and two supplier RFQs used Rev C. The engineer confirms the effect. The affected cost lines and supplier packages reopen. The rest of the bid continues. Nobody has to restart the RFQ, and nobody can silently quote against the old flange.
What Bourne does during intake
Bourne watches the approved channels where requests arrive, reads the package and builds the working intake record. It can match the customer and opportunity, list the current files, extract the requested product and commercial dates, draft missing-information questions and route each technical gap to its owner. Your team reviews uncertain matches and judgments that change scope or feasibility.
After approval, Bourne writes the approved customer and opportunity fields to CRM and passes the same case into the bid/no-bid decision, technical clarification and costing. Each handoff carries the source package, current revision, assumptions and open questions. Sales and engineering do not have to rebuild the request from the inbox.
Pilot it on the RFQs that waste the most time
Use recent RFQs with revised drawings, attachments buried in reply chains, customer part aliases, incomplete specifications, mixed units and more than one delivery date. Include a clean request too. The pilot should show whether the workflow handles normal work and the exceptions that consume experienced people.
Agree the acceptance criteria before setup. A practical first set is: every source file is preserved; the customer and request match is explainable; document revisions are correct; cost-driving gaps become owned questions; the current package reaches estimating; and a later revision reopens only the affected work. Run the same cases through the current process and through the system.
| Measure | Start | Finish | Failure to count |
|---|---|---|---|
| Receipt-to-ready time | The RFQ reaches the company | Estimating receives the accepted package | The case waits in an inbox or queue |
| Human preparation time | A person first touches the request | The accepted package is released | Manual file sorting, rekeying, searching and follow-up |
| Late intake defects | Estimating begins | The proposal is submitted | A missing, wrong or stale input forces rework |
| Change response time | A revised file arrives | Affected work receives the approved change | The revision is missed or unrelated work restarts |
Buğra Gündüz
Buğra Gündüz is the co-founder and CEO of Bourne and co-founder of HockeyStack. He built HockeyStack into an eight-figure AI business. At Bourne, he works with entrepreneurs and established companies to create AI products and services.