Why a quote takes longer than it should
A typical situation goes like this: an email arrives saying “we need a quote for…”. Someone reads it, then reads it again, opens the price list spreadsheet, finds a similar quote from last time, copies it and starts retyping. Then come the checks: is the VAT right, is the validity date correct, did the previous customer's name stay in somewhere. The actual decision about what to offer and at what price often takes a few minutes. Everything else takes hours.
That is where the opportunity is. Most of the time spent on a quote goes into searching, retyping and copying, not into judgement. And when the quote leaves two days later, the customer has meanwhile asked a competitor who answered sooner. Speed of reply often matters more than a few percent of difference in price.
This article is not about capturing the enquiry — there is a separate piece on that. It is about the next step: turning a received enquiry into a finished draft quote.
From an enquiry to a list of requirements
The first step is to read the enquiry and pull out what matters: what the customer wants, in what quantity, by when, where it should be delivered and what special requirements they have. The enquiry may arrive as an email or a web form. A form is easy, the fields are already named. A free-text email is a job for a language model, which reads the text and writes the details into a fixed structure: item, quantity, deadline, note.
What matters is what happens when something is missing or unclear. A well-configured system does not guess. If the customer writes “around twenty pieces, maybe more”, that is recorded as an uncertainty and the draft flags it. The system can also prepare a follow-up question for the customer, which a person then sends.
The result is not yet a quote but a list of requirements in the same shape the next step reads. Without a clean structure, nothing can be calculated reliably.
Prices from the price list, never from imagination
This is the rule that must not be broken: the model never invents prices. A language model is good at reading text and at finding which item in your price list a customer's request matches. It is not good at remembering or estimating a price — and if you allow it, it will produce a number that looks convincing.
So it works like this: the model only suggests which item from your price list fits (“standard installation”, not “complex installation”). The price itself is then read by an ordinary step straight from the price list — from a spreadsheet, or from your accounting or inventory system. A price is data, not text.
If an item is not found, or the model cannot decide between two, the draft marks it as unresolved and leaves it to a person. It does not add an “approximate” price. A quote with one empty line is fine. A quote with an invented price is a problem you will only discover when the customer sends an order.
Texts, terms and calculations from templates
The rest of a quote is surprisingly dull — which is exactly why it can be automated reliably. The opening paragraph, validity period, payment terms, delivery times, warranty, VAT note: all of it is standard text that repeats in every quote. It is stored once in a template and inserted automatically.
Then come the calculation rules. A volume discount above a certain quantity. Shipping by distance or weight. A surcharge for a rush deadline. Rounding, VAT, currency. If you can state a rule in a sentence, it can be written down as a rule and calculated by ordinary code, not by a language model. The result is always the same and can be checked.
The difference from today? Right now these texts and calculations live in one person's head or in an old quote that someone copies. When the terms change, one of fifteen copies stays forgotten. A template is a single place to fix.
A person reviews, adjusts and sends — and the system follows up
The output is a draft, not a sent quote. The salesperson receives a finished document together with a short summary: what the customer asked for, which items the system matched, where it was unsure and what is left to fill in. They read it, adjust the price or discount if needed and send it. A person approves every quote, always. The system never sends one to the customer on its own.
In practice an hour of work often shrinks to ten minutes of review. The review is quick because it is backed up: you can see where each item came from.
The last piece is the reminder. Many quotes go unanswered not because the customer has no interest, but because the quote sank in their inbox. The system records when the quote went out, and if no reply comes within a week, it prepares a short reminder for the salesperson. A person sends that too. If the customer replies, the reminder is cancelled.
Where it does not fit
Not every quote suits this approach. If every job is one-of-a-kind — a custom project where the estimate depends on experience and a site visit — there is no price list and nothing to pick from. The system can prepare only a skeleton: texts, terms, a summary of requirements. A person sets the price.
The same goes for negotiated pricing. If the quote changes after a phone call, the discount depends on the relationship with the customer, or the price is haggled every time, an automatic draft is at best a starting point.
One more condition: quote automation only makes sense when the price list is current and well kept. If prices are scattered across three spreadsheets and half of them are out of date, the price list needs tidying first. Otherwise the system will quickly and consistently produce bad quotes. If you would like to set up something like this, Lucorp can help make sure the draft is built from your price list and your rules, with the sending left to you.