RFQ to quotation workflow prototype
Extraction is one stage. The prototype exists to find out where the rest of the workflow breaks.
Problem
Extracting line items from a document is necessary but not sufficient. A quotation needs the extracted line matched to a real catalogue item, priced against this customer's terms, checked against business rules, and put in front of a person before anything reaches the customer.
Each of those stages can fail in ways the previous stage cannot detect. A confidently extracted line matched to the wrong SKU produces a confidently wrong price.
The question: built end to end against a synthetic catalogue, where does the workflow actually break, and which stage produces the errors that matter most?
Input
- A synthetic product catalogue with realistic characteristics: overlapping descriptions, abbreviations, trade names that differ from the formal description, and items distinguished only by a size or grade buried in the description.
- Synthetic customer pricing: list prices, customer-specific agreed terms, quantity-break tiers and a small set of business rules of the kind that usually exist informally.
- Enquiry documents drawn from the extraction corpus, so the prototype consumes realistically messy input rather than clean test data.
Approach
- Build the full chain — ingest, extract, match, price, apply rules, queue for review, generate the draft — rather than optimising any single stage in isolation.
- Instrument every stage so a wrong final price can be attributed to the stage that caused it.
- Treat human review as part of the system rather than a disclaimer bolted on the end: the measure of the prototype is how quickly a reviewer can confirm or correct a draft, not whether it can run unattended.
- Make every line traceable back to the source text and the pricing rule applied, since a reviewer who cannot see why a price was proposed will re-do the work from scratch.
Architecture
- 01IngestAccepts the enquiry in whatever format it arrived and records the original alongside the parsed form.
- 02ExtractProduces candidate line items with source spans, using the pipeline from the extraction lab.
- 03MatchResolves each description to catalogue candidates and scores them, rather than committing to a single match.
- 04PriceRetrieves applicable pricing for the matched item and this customer — list, agreed terms, or quantity-break tier.
- 05RulesApplies business rules and flags anything outside them, such as a margin below an agreed floor.
- 06ReviewPresents the draft with every uncertain line marked, its source text, and the rule that produced the price.
- 07GenerateProduces the quotation in the format the team already uses, after a person has approved it.
Output
Not yet measured
This experiment has a defined method and architecture, but the run has not been completed and scored. We publish results once they have been measured — an estimated number is not a result, and putting one here would undermine every other figure on this site.
Failure modes
- Confident mismatches: a line extracted cleanly and matched to a plausible but wrong catalogue item is the most dangerous failure in the chain, because nothing downstream flags it.
- Items distinguished only by a grade, size or material buried in a long description — the descriptions are near-identical to a matcher and completely different to a person.
- Customers who use their own internal part numbers, which appear authoritative and match nothing in the catalogue.
- Missing pricing: an item matched correctly for which no applicable price exists for this customer, where the correct behaviour is to ask rather than to fall back to list.
Limitations
- A synthetic catalogue is more internally consistent than a real one. Real catalogues carry years of duplicate entries, discontinued items and inconsistent naming that make matching harder.
- The prototype does not write to any ERP. Integration is a per-customer problem and is deliberately outside the scope of the experiment.
- This is a prototype built to find failure modes, not a product. It has not been run against a real customer's catalogue or a real enquiry volume.
Production considerations
- Matching confidence must be calibrated per customer catalogue, not globally — the same threshold behaves very differently on a 2,000-item catalogue and a 40,000-item one.
- The review interface is the product. Time-to-approve is the metric that determines whether a team keeps using it.
- Nothing should be sent to a customer without explicit approval, and the system should make refusing to guess the default behaviour when pricing is missing.
What we learned
The dangerous errors are not the ones the system flags. They are the ones it is confident about, which is why confidence has to be calibrated rather than reported raw.
Building the whole chain first surfaces different problems than perfecting one stage, and the integration points between stages produced more failure modes than any individual stage.
This is an engineering experiment on prototype. It is not a client engagement, it is not a case study, and nothing here is a performance guarantee for any particular business.
Related: RFQ Automation →