You can automate an RFQ process without replacing the tools your team already uses. The practical route is to add automation around your inbox, ERP, CRM, spreadsheets and document templates, one stage at a time, with an engineer approving what leaves the building. This guide explains how to choose that first stage and what to check before you build anything.
What RFQ automation actually means
An RFQ (request for quotation) process covers everything between a customer request arriving and an approved proposal going back. RFQ automation is the use of software to carry out the repetitive steps in between: reading the request, capturing its details, finding relevant reference material, applying costing rules, assembling the document and checking it.
It does not mean removing the engineer. Technical judgement, committed prices and the decision to bid stay with people. What changes is how much of their time goes on copying, searching and formatting.
Why replacing the stack is usually the wrong first move
When quotations are slow, the instinct is often to look for a new platform. For technical quotations that rarely addresses the real problem, for three reasons.
- The knowledge already lives in your tools. Product data sits in the ERP, customer history in the CRM, costing logic in spreadsheets and past proposals in shared folders. Replacing them means migrating all of it before anything improves.
- The delay is usually between the tools. Time is lost re-keying data, searching for the last similar job and chasing colleagues for inputs, not inside any one system.
- People already know the tools. Adoption risk and retraining are real costs, and your approval routes are probably built around the systems you have.
Automation built around the existing tools targets those gaps and leaves the systems of record where they are.
Where automation sits around your current tools
Most technical RFQs pass through the same stages. The flow below is a generic picture of where a layer of automation can connect to what you already have.
- Request arrivesInbox, customer portal, attachments
- Intake and gapsStructured record, missing information flagged
- Reference lookupPast proposals, datasheets, product data
- Coordination and costingEngineering, purchasing, pricing rules
- Draft and checksYour template, rule-based review
- Human approvalAn engineer signs off before it is sent
Stage by stage: what is repetitive and what stays human
This table shows how the same stages break down. Which of them is worth automating depends on your process, not on a standard package.
| Stage | Repetitive work today | What can be automated | What stays with people |
|---|---|---|---|
| RFQ intake | Reading emails and attachments, copying requirements into a form or spreadsheet | Capturing the request as a structured record | Deciding whether to bid |
| Reference and knowledge | Searching old proposals, datasheets and drawings for similar work | Retrieving relevant past material, with its source | Judging whether a past project is truly comparable |
| Gap analysis | Checking the request against what you can supply | Listing missing, unclear or conflicting requirements | Deciding what to assume and what to ask the customer |
| Internal coordination | Chasing engineering, purchasing and logistics for inputs | Sending structured requests and tracking replies | Resolving disagreements and setting priorities |
| Pricing and estimation | Re-applying the same costing rules in spreadsheets | Applying agreed rules consistently and showing the working | Committed prices, margin and exceptions |
| Proposal generation | Assembling a document from earlier proposals | Building a review-ready draft in your own template | Scope wording and the commercial message |
| Quality and review | Manual consistency checks | Rule-based checks and a flagged list for the reviewer | Sign-off |
| Integrations | Re-entering the same data in several systems | Passing approved data to the ERP, CRM or document store | Which system is the source of truth |
A five-step approach
1. Map one recent RFQ end to end
Take a real, recent request and list every step from arrival to the proposal that went out: who touched it, which tool they used and how long it took. Use a typical example, not your best or worst. If you have not done this before, Where the Time Goes in an Industrial Quote describes what to look for.
2. Choose one stage, not the whole process
Pick the stage where the repetitive work is heaviest and the rules are clearest. For many teams that is intake or the first draft of the proposal, but it depends on where your own map shows the time going. A narrow first scope is easier to test and easier to trust.
3. Write down the data and the rules
Automation can only apply rules that exist. For the chosen stage, list the inputs, where each one lives, which rules turn inputs into an output and who owns those rules. Gaps here are the most common reason projects stall, and finding them early is cheap.
4. Connect to the tools you already use
Plan the connections before the logic: where the request is read from, where reference data is retrieved, where the result is written. Keep the existing system as the source of truth for what it already owns, so nothing is duplicated and nobody has to learn a second place to look.
5. Run it on real data, with approval, before going live
Test on past RFQs where you already know the correct answer, compare the output with what your team produced and adjust. Then put the result in front of the person who would normally approve it. Go live only when they are comfortable that the output is review-ready.
Checklist: is a stage ready to automate?
- You can name the inputs and where each one is stored.
- The rules that turn those inputs into an output can be written down, even if today they sit in one person's head.
- The output has a known format, such as a record, a table or a document template.
- Someone owns the approval and has agreed to review the output.
- At least a few recent examples exist that you can test against.
- The stage repeats often enough to justify the effort.
If two or three of these are missing, the first piece of work is usually clarifying the process rather than building anything.
What should stay with people
Keep a person in charge of engineering decisions, of any price that commits the company, of exceptions that fall outside your rules and of final approval. Automation should present its working, flag what it is unsure of and stop at the review step. That is what keeps speed from costing accuracy. Keeping Automated Quotes Accurate and Always Reviewed goes deeper on how.
Common mistakes
- Starting with the whole process. A broad first project hides problems and delays any benefit.
- Automating before the rules are agreed. If two engineers price the same job differently, decide the rule first.
- Skipping the review step. An output nobody checks is a liability, however accurate it looks.
- Underestimating data readiness. Scattered or out-of-date reference material limits what any tool can retrieve.
- Treating it as a one-off. Rules and products change, so someone needs to own the upkeep.
Where to start
Before deciding what to automate, it helps to know what the current process costs. The Technical Quotation Cost Calculator turns your quotation volume and hours into annual labour hours and internal cost, using only the numbers you enter. It also lets you test a hypothetical scenario, clearly labelled as such.
If you would rather talk it through, Cifral Custom is built for this: we identify the repetitive work in your quotation process and scope tailored automation around your existing tools, with your team approving the result. If you are still comparing routes, CPQ vs Custom Quotation Automation explains when each approach fits.