Automating RFQ intake without automating commercial judgment

The request treated quote drafting as the problem, so discovery first tested where the time actually went. Future Built reviewed 240 historical RFQs, observed a morning inbox triage, interviewed the sales manager, two inside reps, an outside rep and the controller, and traced where price, availability and customer terms came from.

Most of the repetitive effort came before price. Each email had to be recognized as an RFQ and tied to the right account. Attachments had to be opened, line items transcribed, requested dates found, duplicates caught, an owner chosen and a HubSpot record created. At 196 RFQs a month and 17.2 minutes each, intake consumed 56.2 hours a month before any pricing work started.

The pricing trace pointed the other way. List prices sat in supplier pricebooks, but what a customer actually paid often depended on negotiated multipliers, legacy account exceptions and vendor concessions held in spreadsheets, vendor portals or a salesperson’s memory. None of it was authoritative structured data. The bottleneck was intake, and the requested feature depended on the least reliable data in the business.

Four options were compared. An autonomous quoting agent was rejected because pricing authority was not machine-readable. A new CPQ platform was too large for the bottleneck and the budget. Simple email-to-CRM rules were too rigid for documents that change shape by customer. The selected design combined bounded extraction, deterministic validation and human review.

The system owns operational preparation: receiving the email and preserving the source, routing attachments by format, parsing or extracting candidate values, validating them, matching the customer and building a review record. Once a person confirms the record, the system creates the HubSpot deal, assigns an owner and acknowledges receipt.

Salespeople and estimators keep everything commercial: price, margin exceptions, availability, account terms and the final quote.

An inconsistent document is a reading problem, and software can help read it. An undocumented pricing policy is a business problem, and a model would only guess at it.

The first technical spike did include automatic pricing from exported pricebooks, and it looked viable on simple list-price examples. It failed on the accounts where errors would cost the most: several large customers had negotiated multipliers and legacy exceptions that sales staff knew about but the export did not represent consistently.

No prompt could fix that; the missing information was not in any system the model could read. Future Built removed price calculation from production scope and documented why. The recommended next step is a separate discovery into centralizing account pricing rules: a data-governance prerequisite for any future quote automation.

Microsoft Graph signals each new message in a dedicated RFQ mailbox, and intake fetches the email and original attachments, deduplicates on message ID and retains the source package with hashes and source locations, so every value stays traceable.

A format router decides the path. XLSX and CSV files already contain rows and cells, so they are parsed and normalized deterministically and never sent to the language model; on structured input a parser is faster, cheaper and exact. Email bodies and text-based PDFs are normalized and passed to OpenAI structured extraction, which fills a defined RFQ schema with candidate values. Unsupported or unreadable files, including scanned drawings in phase one, go straight to manual intake.

Both paths feed the same validation. Candidates and validation issues are stored in Supabase Postgres with extraction runs, review events and an audit trail. The Next.js review queue reads that state, and only approved records sync to HubSpot, which remains the CRM of record.

Graph subscriptions are treated as operational dependencies rather than permanent plumbing: renewal is monitored, missed events can be reconciled, and notification failures surface to an operator. Replays retain the original message identity, so recovery does not create duplicate RFQs.

For the salesperson, the work shifts from opening, reading, transcribing and re-keying to inspecting, confirming and correcting where needed.

Extracted values are untrusted candidates until they pass checks, and the model’s own sense of confidence never sets the route. Deterministic rules do: a supported, readable format; required fields present (part number or description, quantity, unit); a customer resolved by exact ID or approved alias; part numbers matching expected patterns. Field-level evidence, such as source agreement, can send a record to closer review but can never excuse a failed check.

Records that pass every check are auto-eligible, which here means a shortened human review. Useful extractions that fail a required check go to focused review. Unsupported, unreadable or materially ambiguous inputs go to full manual. Source conflicts block handoff until a person resolves them, missing values stay null rather than being invented, and every confirmed record is revalidated.

The evaluation design uses a 240-RFQ labeled set, stratified by customer and document format. In the constructed evaluation model, customer identity reaches 97.5%, part numbers 95.2% exact match on labeled lines, quantity and unit pairs 98.3%, and explicitly stated requested dates 96.7%. At the record level, the modeled route mix is 82% shortened review, 7% focused review and 11% full manual. These figures define the representative operating case; they are not a benchmark from a historical Norwyn deployment or a claim about OpenAI generally.

The representative rollout plan stages deployment: in week five, the system runs in shadow mode on live RFQs while two inside-sales reps compare its output with their own work; in week six, CRM creation and acknowledgment are enabled for the shortened-review route only.

The trace follows synthetic RFQ NMC-0261 from Alder Fabrication, shown in the review screen above. An email with a PDF arrives at 13:42:00 UTC and is deduplicated, fetched and routed a second later. Extraction takes 2.4 seconds and returns two typed line items with provenance.

Validation then catches something the model was never asked to settle. The PDF lists line 01, NX-PS18-PNP, at 12 EA, while the email body revises it to 24 EA. The validator raises SOURCE_CONFLICT and blocks handoff instead of picking a source silently. A reviewer opens the record at 13:44:00, compares both sources and corrects the quantity to 24 EA: 72 seconds, one correction. The record is revalidated, persisted with an audit event and queued for sync; HubSpot confirms it at 13:45:14, ready for human pricing.

Post-launch figures cover a constructed eight-week period with all three inside-sales users on the queue. The headline figure weights the three routes: 82% of RFQs at 3.8 minutes, 7% at 8.0 minutes and 11% at the full manual 17.2 minutes, which gives 5.57 minutes per RFQ. At the same 196 RFQs a month, intake falls from 56.2 to 18.2 hours, releasing about 38 hours.

The case model gives high attribution to the effort reduction and to acknowledgment within two business hours, up from 37% to 88%. Median receipt to quote-ready handoff fell from 27.4 to 18.6 hours, and intake rework fell from 11.5% to 4.2%; both carry medium-to-high attribution.

At a modeled loaded cost of $45 an hour, the released time represents about $20,519 a year of employee capacity, not a payroll reduction. Against a $9,800 implementation, modeled payback is 5.7 months.