Jeff Brokaw

A heavy quote cost up to $50 per prompt.

The product could save sales reps weeks on a large electrical quote. A rep could process a customer’s email or upload a detailed bill of materials or drawing. It extracted the requirements, searched hundreds of thousands of products and prepared priced quote lines with alternatives and supporting spec sheets for review.

The model was doing the database’s job.

A request might arrive as a handwritten takeoff, a drawing set, a spreadsheet or an email with half a part number. Reps had to identify the items, find valid alternatives and apply the distributor’s customer pricing. The difficult lines could hold up the whole quote.

The application sent large amounts of unfiltered catalog data to the model to find the matches. A query could carry roughly 82,000 tokens. We were paying the model to search through information the database should have narrowed down first.

The core database was Azure PostgreSQL: 65 tables, missing search indexes and electrical attributes stored in JSON. It held 2.4 GB of data on an oversized server. A separate Snowflake Cortex service added another system to maintain without fixing that search path.

  • $25 to $50Model cost per 200-line BOM
  • 20 to 30 minProcessing time before the rep’s quote review
  • 65 tablesIn the original Azure PostgreSQL database

Product-match accuracy rose from 80% to 98%+.

We rebuilt the catalog and matching process, then reached the cost and speed results below. A heavy, 200-line bill of materials took 3 to 7 minutes to process, down from 20 to 30. Exact part-number lookups no longer needed a model call.

The accuracy figure measures individual product matches in our internal research. Reps still reviewed the quote, including substitutions and compatibility.

98%+Product-match accuracy, up from 80%
Before80%
After catalog and matching work98%+

Source: my internal product-match research.

Rebuild results, by workload.
WorkloadReported beforeAfter rebuild
Heavy, 200-line bill of materials$25 to $50 · 20 to 30 min$0.10 to $5 · 3 to 7 min
Simple product search$5 to $15 · 10 to 30 sec$0.001 to $0.01 · under 3 sec
Exact part number$0.50 to $2 · 5 to 10 secUnder 50 ms · no model call

Results reached after the rebuild. Each row compares the same workload. Processing time excludes the rep’s full quote review; exact lookups still incur infrastructure costs.

I chose AlloyDB over expanding Snowflake Cortex.

Snowflake Cortex was a separate search add-on alongside the Azure PostgreSQL database. I wrote the decision memo for moving the product’s retrieval to AlloyDB on Google Cloud. I wanted SQL filters, vector search and customer-specific product records in a PostgreSQL-compatible system, with fewer data copies and search pipelines to maintain.

Some products sat among more than 8,000 very similar catalog items. A close description could still hide the wrong voltage, current rating, mounting or application. The search had to narrow the field using the customer’s technical requirements before the model saw the candidates.

I built the routing around the language people used in requests: trade names, abbreviations, common terms and manufacturer aliases. “Three pole” and “3P” needed to become the same constraint. “Cut sheets” meant the supporting spec sheets. The customer did not have to write like the catalog.

I wrote the detailed implementation roadmap the engineers built from. It specified table definitions, manufacturer and category dictionaries, 52+ electrical-attribute mappings, normalization rules, search indexes, spec-sheet recovery and extraction, model selection, and cost and latency logging. It also set the sequence for the work and the acceptance tests.

Three lookup tables mapped trade language to product categories, attribute names and product counts. SQL narrowed the catalog, with vector retrieval for requests that needed semantic matching. Up to twenty candidates reached the model. Exact part numbers went straight to a database lookup.

A contactor’s coil voltage and power-circuit rating went into separate fields. Finding “120V” somewhere in a record was not enough. The field had to describe the part of the product the customer meant.

I also wrote the Azure-to-Google-Cloud migration plan, including staged traffic changes, acceptance checks and a rollback path. The engineering team implemented the database rebuild and executed the move.

Hundreds of thousands of products. The source sheet came with the match.

A rep could process a customer’s email or upload a detailed BOM, drawing, PDF or photo. The product extracted line items, quantities and technical requirements, resolved them against hundreds of thousands of catalog products, and prepared a priced quote with alternatives and attached spec sheets. On large quoting jobs, it could save reps weeks of work.

We used Google Cloud Document AI to parse manufacturer PDFs into structured product data. Manufacturer aliases, categories and technical attributes were normalized so a search could distinguish a contactor’s coil voltage from its power-circuit rating. The source document stayed available with the product record.

For each extracted attribute, my roadmap required the original value, source, parsing method and confidence to be retained. That gave the team a way to trace an incorrect rating back to the data or extraction step that produced it.

The demonstration below is extremely simplified. It shows a six-line slice of a product built for large, detailed quoting jobs. It is not the actual product interface and does not show the full platform.

Reps could work from the email they already had.

The Outlook add-in read an open RFQ, resolved its line items and drafted a reply with the quote. Reps could start from the customer’s email without retyping the request into another tool.

I built iOS and Android apps for capturing lists, searching products and assembling quotes. The product produced priced quote lines and formal quote documents for review. Teams, Slack and ERP/CRM connections supported the broader workflow.

CaptureLists, PDFs and photosResolveProducts and alternativesReviewQuote lines before sharing

The catalog work expanded to roughly 500,000 products, with enrichment still in progress: resolving manufacturer aliases, extracting spec-sheet attributes and building canonical product records. Prices and stock came from customer feeds, with batch updates where direct connections were not yet available.

The data model kept shared product specifications separate from each distributor’s item codes, customer pricing and warehouse stock. A matched product still had to resolve to the distributor’s own item and commercial terms for the quote.

Model routing, prompt caching and a record of every job.

A faster search still needed to be affordable at customer scale. I built an internal command center to see which agents ran, what failed and where we were spending money.

Model routing

Code and catalog lookups handled work that did not need a model. Easier model tasks went to a cheaper model when it passed the quality checks. Stronger models handled the work that required them.

Prompt caching

I added prompt caching so repeated calls could reuse shared context. Caching a completed search result was separate: price and stock still needed freshness checks.

Learning loops

Failed matches became catalog corrections, product-type checks and test cases. We checked whether the product was right, even when the response arrived in the expected format.

Customer-level costs

I designed metering around the customer, user, task and model, accounting for retries and cache hits. That let us test customer allowances against the work they consumed and keep internal agent costs separate from billable usage.

A quick lookup and a 200-line BOM needed different prices.

Flat pricing would hide the difference between a customer making quick lookups and one repeatedly processing large bills of materials. I built pricing around a platform fee, seats, included usage and heavier job classes.

Customer-level metering let us test those allowances against serving costs before launch. I explain the approach in AI cost per customer.

I built the website and the case for buying it.

I wrote the launch messaging and built the website, including product pages, buyer-role pages, pricing explanations, competitive comparisons and implementation material.

A rep needed to know how it handled the awkward lines in a quote. An owner needed to understand the price and the work it could take off the team. The integration and security reviewers needed enough detail to evaluate it.

I got the company SOC 2 ready.

Examination in progress.
Status as of October 14, 2026.

That included access and role controls, audit logging, customer-data boundaries and the evidence needed to review how the system operated. We had to account for who could access customer data and which actions the system recorded.

The company had an enterprise distributor involved. The product and launch website remain prelaunch while the SOC 2 examination is in progress. A completed report has not been issued.

The details behind the case.

What did Jeff Brokaw own in this engagement?

I joined as a consultant, then became Chief AI Officer. I hired AI engineers, owned architecture and product decisions, wrote the rebuild and migration roadmaps, built the mobile apps, set customer pricing, built the launch website and messaging, and led SOC 2 readiness. Engineers implemented the database rebuild and cloud migration.

Which cost and accuracy results are reported?

After the rebuild, a heavy, 200-line bill of materials cost $0.10 to $5 and took 3 to 7 minutes to process, down from $25 to $50 and 20 to 30 minutes. Simple searches fell to $0.001 to $0.01 and under 3 seconds. Exact part-number lookups took under 50 ms without a model call. Internal research reported item-match accuracy increasing from 80% to 98%+. These processing results do not measure the full sales quote cycle.

Was the product launched and SOC 2 completed?

As of October 14, 2026, the product and launch website remain prelaunch and the SOC 2 examination is in progress. A completed report has not been issued. No post-launch revenue or public app-store release is claimed.

Technical references: Google Cloud Document AI, PostgreSQL JSON types, AlloyDB vector search, Snowflake Cortex Search and AICPA’s SOC resources.

More work by Jeff Brokaw →