NEWS

RFQ Responses and Proposals: Why are they so laborious? Part 2 – Intake Process

Introduction

In my last article, I looked at RFP/RFQ response complexity from the perspective of the sheer number of people involved in the response process. (In case you are wondering, you can read RFQ Response – Why is it so laborious? – Humaxa if you’d like to catch up.)

RFQ Intake Process

In this article, I’d like to talk about the intake process. Of course, the goal of the intake process is to make sure the supplier thoroughly understands the OEM’s requirements and determines whether they can fulfill the request competitively and profitably.

Point of Entry

The RFQ is typically received by the sales team, who act as the liaison with the OEM. From there, the project manager is responsible for routing certain parts of the RFQ to the key stakeholders. For example, the requirements having to do with engineering specifications need to go to the Head of Engineering or Technical Project Manager. Other requirements would need to be routed to the heads of the manufacturing team, the quality team, the finance team, and the legals team.

Sometimes suppliers’ engineering teams try to save time by using an existing Product Lifecycle Management (PLM) system. The problem with these legacy systems is that they don’t take newer (AI) technologies into account. (Just slapping a chatbot onto an existing PLM software package to talk to it in natural language won’t necessarily do the trick.)

Limits of Possibilities

Let’s just pretend that it’s possible to have an AI Agent evaluate the RFQ and route different sections and different requirements to the people who need to evaluate them. What if this could happen automatically, and in a matter of seconds? How many headaches would that avoid?

And what about all of the previous RFQs that have been responded to by that particular supplier. There are tons of information in prior responses that can be mined to respond to new RFQs faster. How can all those responses be ready, at the fingertips?

This concept may seem like just a dream – but it’s not. With today’s technology, it’s possible. But what would it look like?

RFQ Process with AI Automation

Perhaps the easiest way to understand what the process could look like would be to look at one example: Technical Requirements. Typically, the Head of Engineering (for the project) would review the specifications to analyze the design, performance, testing, and compliance requirements. He or she would then need to conduct at least a rudimentary feasibility study to determine if all the requested parts or systems are within the company’s technical capabilities. Then, the Head of Engineering would need to identify any gaps between the OEM requirements and the supplier’s existing capabilities.

Both conducting a feasibility study and identifying gaps require searching through a multitude of existing specifications and workflows related to current or historical projects while asking questions of systems experts.

Similar or Prior Responses

What if it was possible to simply ask an AI Agent about similar responses and have the agent for a recommendation on whether winning the RFQ was viable? And what questions to ask and whom? It could also be possible to ask the AI Agent to conduct a gap analysis, so long as the AI has access to all prior responses and associated data, like whether the proposal was a winning bid or not.

Please note that this doesn’t mean humans are out of the loop. Any party responsible for responding to an RFQ would need to review AI Agent recommendations and responses. There may need to be edits, cuts, or augmentations. That’s all a part of the process. But the endless hours of looking for previous proposals and finding similar questions and responses – all that busywork would essentially be eliminated.