September 28, 2026

Your Quoting Team Doesn't Need Another Chatbot. It Needs a Hundred Fast Answers.

Where a decision model like TypeSafe's Jev fits in a custom-quote process, and where it doesn't.

Nathan Westby6 min read

Ask anyone who runs inside sales at a custom manufacturer why quotes take so long, and you rarely hear "the math is hard." You hear about the data gathering and checking. Someone has to find the customer's part history, work out which of several near-identical SKUs the request refers to, check whether the spec needs an engineer's eyes, confirm material availability, pull pricing, and decide whether the request is even complete enough to quote.

None of those steps is difficult. There are just a lot of them, they live in different systems, and people are slow at switching between them. That is exactly the kind of work a new class of AI model is built for.

The shape of the problem

Picture a specialty industrial manufacturer running ERP, with thousands of customer-specific SKUs. Most of what it sells is made to a customer's specification. So a large share of incoming requests are variations on something it has made before: a new drawing revision, a slightly different dimension, the same part at a new quantity.

Requests arrive as emails, PDFs, and drawings. An inside sales rep reads each one, then works through four or five screens to answer the same handful of small questions every time.

Multiply that by hundreds of requests a week and the result is familiar. There's a backlog, turnaround is measured in days when customers want hours, and the team asks for more information up front than it needs, because a second round trip costs even more time.

Why an LLM agent alone isn't the answer

The obvious move right now is to point a large language model (LLM) agent at the inbox. It can read the email, pull fields out of a PDF, and draft a quote. That part works well, and it belongs in the design.

The trouble is the judgment calls in between. Each one becomes an open-ended text generation: several seconds, a few cents, and an answer in prose that your code then has to interpret. Ask the model how sure it is and you get a number that sounds precise but isn't calibrated. Multiply that by a dozen decisions per quote and hundreds of quotes a week, and the process gets slow, expensive, and hard to trust where trust matters most.

Enter the decision model

Jev, released in September by TypeSafe AI, takes a different approach. It doesn't write text at all. You give it the situation (the RFQ text, a customer record, a list of candidate parts) plus a set of typed questions, and it answers each one with probabilities instead of prose. There are three kinds of question:

Choice: pick one option from a list you provide.
Score: place something on a scale you define, such as low, medium, or high.
Yes/no: the probability that a statement is true (TypeSafe calls this a "noul").

Every question in a request is evaluated in parallel, so asking ten questions takes about as long as asking one: typically a tenth of a second to half a second. The cost is a fraction of a cent per request. Most important, TypeSafe trains the model so its confidence is calibrated: when it says 90 percent, it should be right about 90 percent of the time on that kind of question.

That calibration is what lets code decide which answers to act on and which to hand to a person.

It matters just as much what Jev can't do: explain its reasoning, do arithmetic, compare numbers, or reason about dates. The rule of thumb is "pick a card from the deck": give it the candidates and let it choose, rather than asking it to name one. That limitation is exactly what makes it a good fit for quoting.

A three-layer quoting flow

In a Dynamics 365 environment, I'd split the work three ways.

Dynamics 365 and plain code own the facts and the math. Prices, material costs, availability, lead times, and credit status all have exact answers, and exact answers belong in the system of record. Dynamics 365 can already expose its pricing calculations to outside systems through an API. No model should be guessing a price.

An LLM agent owns reading and writing. It pulls the customer, part description, quantities, and requested dates out of the email or PDF. At the end, it drafts the quote and any clarifying note back to the customer.

Jev owns the judgment calls in between. Once the agent has extracted the request and code has pulled candidate parts from Dynamics, a single call to Jev answers a whole batch of questions at once:

Question Jev answers	Type	What happens next
Which of this customer's existing SKUs is this request for?	Choice	A confident match links part history and pricing; a weak one goes to a rep
Is this a repeat, a revision, or a new part?	Choice	Repeats take the fast lane; revisions and new parts go to engineering
Does the spec call for anything outside standard process capability?	Yes/no	Flags an engineering review before pricing
Does the request include everything needed to quote?	Yes/no, per item	Gaps trigger a clarifying email drafted by the LLM
How time-sensitive is the request?	Score	Sets queue priority
Does the drafted quote match what the customer asked for?	Yes/no	Final check before a person approves

The last row is worth a second look. Jev isn't only a front-end classifier; it's also a fast, cheap way to check the LLM's own work before a person sees it.

Confidence decides the route

Every answer comes back with a confidence level, and that is where the real process design happens. High-confidence repeat orders land in a rep's queue fully assembled, ready to review and approve. Middle-confidence requests arrive with the uncertain field highlighted, and low-confidence ones go to a person exactly as they do today.

The goal isn't to remove people from quoting. It's to stop spending their time re-keying the easy requests, so they can focus on the complex, engineered quotes where their experience actually earns the margin.

Where I'd start

If I were standing this up, I wouldn't start with live quotes.

Start narrow. Pick one product family or a handful of customers, not the whole catalog.
Clean the item master for that slice. A decision model can only pick the right SKU if the candidate list is right. Duplicate parts, inconsistent descriptions, and stale specs quietly cap how much any AI can help; in my experience, this unglamorous work decides whether the project succeeds.
Run it in shadow mode on history. Take a few months of past RFQs, ask Jev the same questions, and compare its answers to what the team actually did. That shows where its confidence holds up on your data, not the vendor's.
Keep a person on every outbound quote until the results justify loosening that.

A few honest caveats. Jev is weeks old, access is through an early-access waitlist, and the headline benchmarks are TypeSafe's own. It returns probabilities without a written rationale, so log every input and answer if you need an audit trail, and test on your own data before trusting it with anything important.

The bigger lesson

The most common mistake I see in AI projects is using one kind of tool for every kind of work. Quoting involves three kinds: facts and math, reading and writing, and fast judgment.

Put each on the tool built for it: the ERP for truth, the language model for language, and the decision model for the hundred small calls in between. Do that, and a quote that used to wait days on a stack of lookups can be ready for review in minutes.