If your sales team is still spending a significant part of their week processing quotes manually, you are not behind. You are in the same position as most mid-market B2B companies, and the reason is not that you haven't tried hard enough or invested in the wrong software.
The reason is that the tools available to solve this problem until recently were not actually capable of solving it. OCR, RPA, and ERP automation rules each addressed a real part of the quoting workflow. None of them addressed the core problem. Manual quoting persisted not because the industry was slow, but because the technology wasn't ready.
The core problem
A quotation workflow starts with an inbound request: a BoQ, an RFQ, a purchase order, a free-text email. That request arrives in variable format, uses the customer's language rather than your product catalog's language, and contains a mix of explicit requirements and implied context.
To convert it into a quote, someone needs to:
The distinction that matters
Previous tools were very good at reading. They were not built for understanding. That single distinction explains most of the history of failed quoting automation projects over the past twenty years.
Why earlier tools failed
Failed approach
Optical Character Recognition
Common starting point for document automation in the 2000s and 2010s
OCR reads characters off a page and outputs a text string. It discards all spatial relationships that made the original document parseable. An invoice or BoQ with columns, headers, and structured rows becomes a flat stream of text once OCR has processed it. The column that held quantities and the column that held product codes are indistinguishable in the output.
Making that output useful required mapping the extracted text to the right fields, which required templates. And templates broke constantly. Small layout changes: an extra column, a shifted header, a resized logo, caused extraction logic to fail. Template maintenance became a hidden operational cost. Each document change required manual updates, testing, and redeployment.
For a quoting environment where customers send documents in dozens of different formats, maintaining a template library is itself a part-time job. Every new customer, every layout update, every unusual document type creates a gap that routes back to manual processing.
Even when OCR extracted characters correctly, it didn't understand what they meant. An OCR system might correctly read several numbers on a page while still failing to produce data that can be trusted in a business process: it does not know which number represents an invoice total, which is a purchase order reference, and which belongs to a line item.
In a quoting context
Knowing that a number appears on the page is not useful. Knowing that it is a quantity for a specific line item, in a specific unit of measure, associated with a specific product description: that is what quoting requires. OCR could not provide it.Failed approach
Robotic Process Automation
The next layer of the automation stack in the 2010s
Where OCR read documents, RPA automated the subsequent steps: navigating screens, copying and pasting data between systems, triggering workflows, sending emails. Combined with OCR, it seemed to offer a path to end-to-end quoting automation.
Ernst and Young found that up to 50% of RPA projects fail to deliver ROI. The failure mode was consistent: legacy OCR and RPA expect structured, predictable inputs: forms that match templates, screens that stay the same. But enterprise data is largely unstructured and varied.
RPA failed silently. A bot that hits an unexpected input doesn't stop and ask for help. It either errors out visibly (which gets fixed) or it continues processing with incorrect data (which doesn't get fixed until downstream damage appears). A layout change that causes OCR to misread a field value goes undetected. The RPA bot keeps running. No alerts. No crashes. Just wrong decisions at scale.
In a quoting context
Wrong decisions at scale means incorrect prices reaching customers, wrong products proposed, margins eroded by configuration errors that nobody caught because the system appeared to be running normally.Two more failed approaches
Failed approach
ERP Automation Rules
Logic applied to structured data, not unstructured incoming documents
Most mid-market companies using SAP, Dynamics, or comparable ERPs have some level of automation rules configured. Standard products auto-price. Known customers trigger discount logic. Common order types flow through without manual intervention.
These rules work: for the cases they were designed for. They break on anything outside their parameters.
ERP automation rules are logic applied to structured data. They assume the data has already been correctly entered and classified. They cannot read an incoming BoQ, interpret it, or decide which rules apply to which line items. Someone still has to process the document first.
The ERP automation handles what happens after the data is in the system. The front-door problem: getting the data in correctly from an unstructured inbound document, remains manual.
In a quoting context
For companies receiving BoQs and RFQs by email in variable formats, ERP automation rules solve the downstream workflow. They do not touch the step that consumes most of the inside sales team's time.Failed approach
Intelligent Document Processing
More flexible than OCR, still extraction-only
IDP platforms emerged as a more sophisticated response to the template-brittleness of OCR. Instead of fixed templates, they used machine learning models trained on large volumes of documents to recognize fields and extract data more flexibly.
This was a genuine improvement over OCR-plus-templates. An ML-based IDP system could handle layout variation better, generalize across document formats it had seen in training, and produce more reliable extraction on standard document types.
But the core limitation remained: early IDP systems were built for extraction. They were not built to reason about what was extracted.
Matching a line item description against a product catalog, resolving a variant configuration from a specification, identifying that a customer's article number maps to a discontinued product with a known replacement: these require understanding of context, not accuracy of character recognition.
The training data problem
IDP tools still required training data. A new customer format, a new product category, a new language: all required labeled examples before the model could handle them reliably. In a quoting environment with a long tail of unusual documents, the training data problem never fully went away.What changed
The arrival of large language models as accessible, API-callable services changed the fundamental capability available for document understanding tasks. For quoting workflows specifically, three things changed at once.
No training data required
An LLM-based system does not need labeled examples of your customers' document formats before it can process them. It brings general language understanding, including technical terminology, unit conventions, abbreviation patterns, and product description language, and applies it to your specific context at inference time. A new customer with an unusual BoQ format is handled on arrival, not after a training period.
Contextual matching, not lookup
When a customer's BoQ describes "DN50 PN16 flanged gate valve, cast iron," an LLM-based system doesn't look for that exact string in a cross-reference table. It understands what the description means, identifies the relevant dimensions, and searches the product catalog for the best match based on the specification. This is the step that previous tools couldn't do.
API accessibility
Capable LLM models became available through standard APIs: callable from any application, without managing model infrastructure. This meant that companies building automation tools could incorporate reasoning capability without building it from scratch. The combination created the conditions for a new generation of quoting automation tools that had not previously been possible.
Why most workflows are still manual in 2026
Most companies tried OCR or RPA in the 2010s, concluded that quoting automation doesn't work for their environment, and haven't revisited that conclusion. It was correct at the time. It is no longer correct.
The conclusion to revisit
Change in business processes lags significantly behind change in technical capability. Most mid-market companies tried OCR or RPA in the 2010s, found that it created as many problems as it solved, and concluded that quoting automation doesn't work for their environment. That conclusion was correct at the time and has not been revisited.
⅔
McKinsey estimates that non-value-adding activities, including paper- and fax-based quote negotiations and order management, account for about two-thirds of sales teams' time. That figure reflects the depth of the problem: not a lack of awareness that it exists, but a history of attempted solutions that didn't hold.
McKinsey
The companies now successfully automating their quoting workflows are not doing something fundamentally different in terms of business process. They are using tools built on a different technical foundation: one that can actually do what quoting requires, rather than approximating it with extraction and rules.
See it in practice
Those are the capabilities that previous tools lacked, and that make the difference between a quoting automation project that succeeds and one that becomes another item on the list of things that didn't work.
See the RFQ and BoQ intake agentsBy clicking "Accept", you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
