PruvatoAn RFQ arrives on WhatsApp at ten in the morning. It's a few lines typed straight into the chat. One of them reads:
Cu/XLPE/SWA/PVC 4x16mm2, 300m
Somebody now has to work out which product that is, find it in a supplier catalogue, check whether it's in stock, look up what this customer paid last time, and type it into a quote template. Then do the same for the next eleven lines. If it's a bill of quantities from a contractor, there may be four hundred.
RFQ automation is the term for software that takes on the repetitive part of that job. When the incoming list is a BOQ rather than a short request, you'll see the same thing called BOQ automation: it's the same work, just longer.
The term is also widely misunderstood, usually in the same direction, so it's worth being precise about what it does and where it stops.
The thing people assume it means
The word "automation" suggests a machine that reads an incoming request and sends a quotation back without anyone looking at it.
That would be a bad idea, and nobody serious builds it.
A quotation is a commercial commitment. Price it wrong and you either lose the job or win one you lose money on. Identify the wrong product and you ship the wrong thing, pay for the return, and spend a week rebuilding the customer's confidence. The last thing any trading company needs is a faster way to make that mistake.
So the useful definition is narrower, and more interesting.
What RFQ automation actually does
Four steps. The split between them is the whole point.
It reads the RFQ however it arrives. WhatsApp message or email body. No template for your customer to fill in, no portal for them to log into, no change to how they already work. The first real obstacle in this job is that the input is whatever someone felt like sending, and that obstacle is solvable.
It works out what each line is asking for. This is the hard part, and it's where the honest version differs most from the marketing version. Some lines carry a manufacturer part number, and those resolve cleanly. Some describe a product well enough to narrow it to a handful of candidates, but not to one, and in that case the right output is the handful, presented for a person to choose from, not a confident guess. Some name a brand or a category nobody has in the catalogue yet, and the right answer there is to say so plainly rather than return the nearest thing.
It applies your prices and your rules. Your cost, your customer-specific pricing, your margin floors, what each salesperson is allowed to discount. These are not judgement calls made case by case: they're rules your business already has, usually written down somewhere or held in a manager's head. Software is good at applying rules consistently. It should not be inventing them.
It assembles the draft. Line items, quantities, units, prices, totals, your template, your branding.
And then it stops. You or someone you name reviews the draft and approves it before it goes anywhere. Not a threshold, not a rule that lets small quotes through unseen: a person, every time.
What it removes, and what it leaves alone
The pairing matters more than either half.
Removed: re-typing line items from a message into a spreadsheet. Searching supplier catalogues one product at a time. Looking up what this customer paid in March. Re-keying everything a second time into the quotation template. Chasing which of the four PDFs on your desktop is the current price list.
Not removed, by design: deciding which product the customer meant when their description genuinely fits more than one. Deciding what margin this particular job can carry. Deciding whether to quote the cheaper brand or the one they specified. And the send itself.
The first group is repetitive work that produces the same answer every time and wears people out. The second group is why you employ experienced people.
A system that claimed the second group too would be claiming something it can't deliver, and you'd find that out on a live quotation in front of a customer.
Why this is harder than the term suggests
Three things make quoting here more work than the phrase "RFQ automation" implies.
Multi-brand catalogues. A trading company in Dubai might stock seven brands of circuit breaker and four of cable, from manufacturers in Europe, the Gulf and Asia, each with its own part-number scheme and its own way of describing the same thing. A customer writing "20A MCB" has not told you which of those they want, and often doesn't know they haven't.
Mixed languages and shorthand. Descriptions arrive in English, sometimes with Arabic alongside, frequently in a shorthand that only makes sense to people in the trade, and differently abbreviated by every customer who sends it.
Approved-vendor requirements. On many projects the specification isn't only technical: certain products have to come from a manufacturer a consultant or client has approved for that job. It's a real constraint in this market, sitting on top of everything else, and it's the customer's own requirement to state, not something an automated match can infer or certify on your behalf.
None of this is a reason the work can't be helped. It's the reason the help has to understand products, not just read documents.
Seeing it
The clearest way to understand any of this is to put a real line through it.
You can paste an RFQ line and see what comes back, including the lines where the honest answer is a short list of candidates rather than one product.
And if what you need today is just the document, Quote Studio is free and open: bilingual quotations, your branding, no account required.