AI quoting engine
The AI quoting engine
Custom quoting is where vertical businesses bleed time: the catalog is enormous, the pricing logic lives in two estimators' heads, and every quote is a small research project. An AI quoting engine turns that into a system — configured, priced, and checked in one pass, with a person approving the result.
01
What it is
An AI quoting engine takes a request — dimensions, specs, product selections, the customer's PDF — and produces a priced, line-itemed quote an estimator can review and send. Not a chatbot that talks about pricing: a system that resolves a real catalog, applies your actual pricing rules, and outputs the document your customer signs.
The hard part is never the model. It's that your catalog has hundreds of thousands of configurable options, your price rules carry exceptions no horizontal software vendor ever modeled, and the one person who knows them is booked three weeks out. The engine's job is to hold all of that and get a draft in front of human judgment in minutes instead of days.
02
When it's the right wedge — and when it isn't
It's the right first build when:
- Quote turnaround is measured in days and the backlog is quietly losing deals.
- The pricing logic is tribal — only a handful of people can quote the complex jobs.
- Catalog complexity is real: multiple manufacturers, option trees, compatibility rules, exceptions.
- Volume justifies a system: quotes go out every week, not every quarter.
It's the wrong wedge when quoting is a flat-rate price list — a disciplined spreadsheet wins and software would be decoration. It's also premature when the catalog doesn't exist in any structured form anywhere; that's a vertical data model project first, and pretending otherwise just moves the failure to week four. And if nobody owns quoting, fix ownership before tooling.
03
How it's built
Sprinter uses a repeatable loop — wedge → spec → build → ship → measure — and the spec stage pins down four layers before code:
- Entities — catalog, SKU, option, rule-set, quote, customer. The domain modeled explicitly, not inferred at runtime.
- Workflow — intake → configure → price → approve → send, with the approve step owned by a named estimator.
- Agents — pricing-rule extraction from the documents and heads where the logic lives today; quote drafting against the modeled catalog.
- Surface — an estimator console for review and overrides, plus a clean preview the customer actually sees.
Reusable build patterns can shorten common setup, but the architecture and acceptance tests are selected for the actual wedge rather than assumed from a universal platform.
04
Evidence boundary
Cab‑O‑Matic supplies capability evidence for the underlying catalog problem: cabinet pricing, quoting, and configuration across complex manufacturer data. The evidence is the engineering itself; we attach no adoption, deployment, scale, or outcome figures to it.
05
What a v1 proves in weeks
A v1 doesn't quote everything. It takes one manufacturer line — or one job type — end to end: catalog modeled, rules encoded, agent-drafted quotes reviewed by one estimator on real requests.
What it has to prove is specific: a draft the estimator trusts comes back in minutes instead of days, and the exceptions surface for a human instead of hiding in the output. If that holds for one line, extending to the rest of the catalog is roadmap, not research. If it doesn't hold, you've spent weeks finding out — not quarters.
FAQ
Questions this pattern has to answer.
How does it handle pricing exceptions and one-off deals?
It routes them instead of guessing. Rules that can be encoded are encoded; anything outside them lands with the estimator, with the full context attached. For the first month every quote is human-approved anyway — autonomy is earned on evidence, not assumed.
Our catalog lives in PDFs and a manufacturer portal. Is that a blocker?
It's the first work item, not a blocker. Turning messy catalogs into entities software can reason over is its own pattern — the vertical data model — and it gets scoped honestly in the spec. If the catalog exists nowhere at all, we say so and fix that first.
Will customers see AI-generated prices without review?
Not in a v1. A named estimator approves every quote until the reconciliation record says the engine can be trusted on routine configurations. Even then, thresholds keep unusual jobs stopping at a person.
What does it cost to run?
Model costs are pennies per quote. The real cost is the build and the catalog modeling — which is exactly why the wedge gets scored before anything is built. Start with the Product Wedge Review to see whether quoting is actually your strongest first bet.
Next step
Score the wedge before you build.
Bring the workflow, owner, data, and proof line. The review turns that into a build, fix-first, or don’t-build call.