The company manufactures glass. Its customers do not order a catalog item; they describe what they need, and what they need is assembled from a set of choices. That is the whole problem in one sentence, and it is why quoting consumed as much of the commercial team's week as it did.
Why a quote here is not a price lookup
A distributor quoting from a catalog answers a question with a number that already exists. A manufacturer of a configurable product does not have that number. It has a set of options the customer can combine, and a price that follows from the combination they chose.
So every request has to be read, understood as a specification, and then priced from the company's own data. Two requests for the same product in different configurations are two different pieces of work. There is no line to look up.
The product is a set of choices. The quote is what you get when you resolve the customer's choices against your own data.
And the requests arrived in every format
The second half of the problem was the intake. Requests came in by email, written the way each customer happened to write them. There was no form to fill in, no structure to rely on, and no way to know in advance whether the next message would contain a tidy list or a paragraph of prose.
This is the normal state of B2B quoting and it is precisely what defeats conventional automation. A form-based system needs the customer to fill in the form. A scripted integration needs the input to be identical every time. Neither describes an inbox.
What the work looked like before
The team assembled each quote from spreadsheets. The specifications and the pricing data lived in Excel files, and producing a quote meant reading the customer's email, working out what had actually been asked for, finding the relevant figures across those files, and building the quote from them.
Nothing about that is unusual, and nothing about it is cheap. It is accurate work done by people who know the product, and it is slow for exactly that reason: the knowledge is in their heads and the data is in a file they have to go and open.
What the agent does now
- 01Reads the request
Takes the incoming email and works out what is being asked for, whatever form the customer wrote it in.
- 02Resolves it against their database
Matches what was requested to the company's own product and pricing data, rather than to a copy or an exported list.
- 03Assembles the quote
Builds the draft from the resolved data: what was asked for, in the configuration asked for, priced from the company's own figures.
- 04Drafts the reply
Prepares the response as a draft email, ready for a person to read, adjust if needed, and send.
- 05Writes and logs it
The draft goes into the company's own calculation system, and the transaction is logged in the ERP, so the record exists where the business already keeps its records.
What actually changed
Quote preparation is 63% faster than the process it replaced. That is the company's own measurement against their own previous process, published with their approval.
The mechanism behind the number is worth being precise about, because it is not that the agent is quick at arithmetic. It is that the reading, the resolving and the assembling now happen without a person moving between an email and a set of spreadsheets. What is left for the person is the part that needed them: checking the result and deciding to send it.
| Before | Now | |
|---|---|---|
| Reading the request | A person interprets the email | The agent reads it, in whatever form it arrived |
| Finding the data | Opening spreadsheets and locating the figures | Resolved against the company's own database |
| Building the quote | Assembled by hand from those files | Assembled by the agent from the resolved data |
| Sending it | A person writes and sends the reply | A person reviews the draft and sends it |
| The record | Whatever was saved afterwards | In the calculation system, logged in the ERP |
How long it took
Two and a half months, from the first assessment of the workflow through the strategy, the build and the implementation, to an agent running in production.
That is one deployment and not a promise about yours, which depends on your data and your rules. It is stated here because it is a measured fact about this project rather than an estimate, and because it is a more useful number to a buyer than most of the ones this industry quotes.
Why this one worked
Three things, and they are the same three that predict whether any quoting deployment will repay the effort.
- The volume was real and constant. Quoting was not an occasional task, it was the commercial team's week.
- The data existed and was reachable. The configuration and pricing information was theirs, in their systems, and could be resolved against rather than copied.
- The outcome was defined. A quote is either prepared or it is not, which makes both the automation and the measurement unambiguous.
Choosing your first workflow sets out those criteria in general, and from an RFQ to a quote goes through the workflow step by step.