From an email to a finished quote – how AI handles RFQs, tenders and customer specifications

A typical enquiry at a mid-sized manufacturer or distributor does not look like a form. It is an email of three sentences and four attachments containing a drawing, a spreadsheet table, a scanned letter and a specification in PDF. The requirements are scattered across all four, partly duplicated and partly contradictory.

The first hour of a salesperson's work goes on establishing what the customer actually wants. The second and third go on matching that to the catalogue: which item code corresponds to the description, whether we have a substitute, whether a parameter from the table falls within our range. Only then does pricing begin, and finally document assembly, which in this accounting is the shortest stage of all.

On top of that sits a choice nobody states out loud: whether to bid at all. Teams that answer everything spread themselves thin and post low win rates. Teams that select deliberately win more often – industry benchmarks show a spread from an average around 45% to 60% and above for those who watch selection and answer completeness. But to select deliberately you first have to understand the enquiry quickly – which brings you back to stage one.

That is why automating this process makes sense even when it does not shorten writing the quote at all. It shortens the path to the „bid or no bid” decision from three days to an hour.

The first step turns attachments into a list of requirements. The agent reads the documents, pulls out items with their parameters and reduces them to one table: requirement, source (which document, which page), parameter, unit.

Citing the source matters more here than the extraction itself. A salesperson handed a requirement list with a pointer to a specific place in the specification can verify each line in seconds. A list without sources requires reading the whole thing again, which saves nothing.

Things that read well: text in digital PDFs, tables with a regular structure, parameters with units, deadlines and terms expressed in words. Harder: poor-quality scans, tables broken across several pages, requirements hidden in a conditional clause („for variant B the following applies…”), and anything derived from a technical drawing. That last area is feasible but is a separate project rather than an add-on – and should be priced that way.

A practical implementation rule: the agent must explicitly flag what it could not read or read with low confidence, and treat it as an item for human decision. A list that pretends to be complete is worse than a shorter one with honestly marked gaps – because in the first, nobody notices the missing requirement until the complaint arrives.

A compliance matrix assigns every customer requirement one of three answers: we meet it, we meet it conditionally, we do not meet it – together with a rationale and a pointer to a product or service in the catalogue. This is the real output of the whole process; the quote text is derived from it.

The agent can prepare a draft of that matrix: match a requirement to an item code, compare parameters, propose the closest substitute and flag items where the customer's scope exceeds yours. It must not settle disputed items, because „we meet it conditionally” is a contractual declaration, not a technical judgement. Somebody in the company takes responsibility for it.

A well-designed matrix does one more thing worth noting at implementation: it shows the risk distribution across the whole bid. If eight of forty requirements are conditional and three fall outside scope, that is information for whoever decides on bidding – and information available in the first hour rather than on submission day.

The matrix is also the best training material for the system. The corrections a human makes to the agent's draft are a ready set of test cases: they show exactly where matching fails.

The second part of the work is descriptive content: the company, references, delivery process, quality standards, warranty terms. In most companies these are produced by copying from the last similar quote, so after two years four different versions of the same paragraph are in circulation and one of them names an employee who has left.

An answer library tidies this without a revolution: a collection of approved fragments each with an owner and a review date. The agent matches fragments to the questions in an enquiry and assembles a draft response – always from the same, current version. A fragment past its review date is flagged so it does not reach a quote unchecked.

The side effect is often more valuable than the speed-up itself. Building the library forces a review of what the company says about itself, and in the process a fair amount of content that has not been true for years disappears. It is one-off work, useful regardless of how many quotes AI later handles.

Plan from the outset who owns the library. Without a named person, the starting state returns within six months, only now with an extra layer of tooling on top.

Three things stay with the human, and it is worth naming them explicitly at design time so they do not become a dispute during the first difficult bid.

First: price. Not because a model cannot compute it, but because price in B2B is a decision about margin, relationship and how badly you want this customer. The agent can prepare a baseline calculation and show where you sit relative to comparable completed jobs – the decision belongs to the salesperson or the sales director.

Second: commercial terms and contractual clauses. Deadlines, penalties, warranties, scope of liability. These are company obligations rather than content to be generated, and accepting them must leave a named trace in the system.

Third: the decision to bid. The agent supplies the basis – requirement completeness, compliance distribution, indicative effort – but a human judges whether it is worth it, knowing the market and the customer.

There is a fourth thing worth remembering when planning: data. Proposal teams work on price lists, margins and customer specifications often covered by confidentiality clauses. If they do not get a tool with access to company knowledge, they will paste that material into general-purpose chatbots, because the work has to get done. Deploying a controlled tool is, in this case, simultaneously an act of risk management.

The sequence that works starts with one enquiry type rather than the whole process. Pick the category that recurs most often and has the most standardized attachments – usually the segment where customers send similar specifications. Build extraction and the compliance matrix on that.

Stage two is the answer library for the same segment. Stage three is connecting the catalogue and price list – the point at which the project stops being document work and becomes an integration. That is where most of the cost appears, and it is worth having confirmed by then that the first two stages work.

Measure four things. Time from enquiry arrival to the bid decision. Time to sending the quote. The share of requirements correctly matched to the catalogue without human intervention. And the number of enquiries handled per person – because in many companies the real effect is not a faster quote but an answer to enquiries that previously went unanswered.

For matching quality, use the same method as for any other agent: a reference set built from enquiries handled manually over the last quarter, with the correct matching approved by whoever is accountable for quoting. We describe this in detail in a separate article on agent evaluation.