Our Client Wanted a Chatbot. We Built Their Quote Desk Instead.

A distributor we worked with takes a few hundred requests for quotes every day. They arrive as email, as PDFs, as spreadsheets with no consistent schema, and occasionally as a photo of a handwritten list taken on a warehouse floor. Someone reads each one, works out which SKUs the customer actually means, checks stock, applies the right contract pricing tier, and sends a quote back. Turnaround is a day, sometimes two. A meaningful share of requests never gets quoted at all, because the queue is longer than the day.

When we asked the operations director what they wanted to automate, the answer came quickly: a chatbot for the website.

Not because the chatbot mattered. Because the chatbot was the thing that looked like AI. The quote desk did not look like AI. It looked like two people who had been doing it for nine years and were very good at it.

We built the quote desk system instead. Turnaround moved from days to minutes, and the requests that used to fall off the end of the queue now get quoted. We are not at liberty to publish the client's numbers, and directional claims are worth less than figures, so treat this as context for the engineering rather than the proof. What follows is how the system works, which is the part you can evaluate for yourself.

Work that looks like people is usually rules

In March 2026, Julien Bek, an investor at the venture firm Sequoia Capital, published an essay called Services: The New Software. Its argument, which travelled well beyond investor circles, is that AI's real prize is not selling software tools but doing the work itself. It also gives the chatbot pattern above a vocabulary we now use constantly.

Bek splits professional work in two. Intelligence is the part with rules, however complex: translating a spec into code, mapping a clinical note to a billing code, reading a messy request against a catalogue. Judgement is the part built on taste and years of pattern recognition: what to build next, whether to bend on price to hold an account. His claim is that models can now handle most intelligence work on their own. Our production experience agrees, with one condition that decides everything: it only holds where you can verify the output.

Run the split across the quote desk and the picture changes. Interpreting a garbled request against a known catalogue is pattern matching against rules. Pricing is a lookup with conditions. The genuine judgement, whether to flex on price for a strategic account, is a thin slice at the very end of the process, which is exactly where a human can own it. Nine years of skill was real. Most of it was also automatable, and nobody inside the company could see that, because the work had a face.

Worth saying plainly: those two people still work there. They moved onto the review queue and the exceptions, which is the part of the job that was always the hardest and had been squeezed into the margins by volume. That was the client's decision, not a consequence of ours, and we would build this differently if the plan had been to cut the desk. A system whose corrections train it needs the people who know what correct looks like.

What we actually built

Nothing about the system is exotic, which is the point.

Ingestion normalises email, PDF, and spreadsheet inputs into a single request schema. A model does the extraction, and a validation layer rejects anything malformed before it travels further. Catalogue matching is retrieval against the SKU master, tuned for the shorthand customers actually type, because no customer on earth writes part numbers the way the ERP stores them. Pricing is deterministic code. The model never invents a number, ever.

Every output carries a confidence score. Anything below threshold goes to a human review queue rather than out the door, and the corrections made in that queue become the evaluation set that tells us whether the system is genuinely improving or just moving.

An engineer reading that list will notice there is no novel technique in it. Retrieval, extraction, validation, thresholding. That is the honest state of most production AI, and the difficulty was never in the components. It was in learning which of the client's fifty pricing exceptions were real rules and which were one person's habit, and in the fact that the SKU master and the stock system disagreed often enough to matter.

The hard engineering was verifiability: being able to cheaply tell whether a generated quote is correct before a customer sees it. If you cannot do that for a workflow, you do not have an automation problem yet. You have a measurement problem, and it is the thing to fix first. This is the question that decides whether a project survives contact with production, and it is the one almost everyone skips.

Why no vendor was coming

Bek's essay closes with a map of services markets ripe for AI startups to attack: insurance brokerage, claims adjusting, tax, IT managed services. What those markets share is that they are large, fragmented, and standardised enough to support a venture-backed company. That is precisely the right filter if you run a fund. It is the wrong filter if you run an operations team, and two things fall straight off it.

The first is work companies kept in-house. An outsourced task has a budget line to substitute and a buyer already paying for an outcome, which makes it easy to sell against. But that is a fact about ease of sale, not about where the value sits. An operator already owns the P&L and needs no budget line to displace.

The second is entire industries. Manufacturing, distribution, freight, field service, and wholesale are absent from the map, not because the value is small but because the workflows are not standardised between companies. There is no version of "draft an NDA" that means the same thing at ten thousand firms. Every distributor's quoting process is a function of its own catalogue, its own ERP, its own contract terms, and three exceptions that live in one person's head.

That heterogeneity is why no startup will productise the quote desk. It is also why, once built, the system stays yours. Every correction, every edge case, every customer quirk it absorbs makes it more specific to your operation and harder for anyone to replicate.

Finding your quote desk

Three questions did the ranking work for this client, and they will do it for most.

How much of the task is rules applied to inputs, and how much needs context a model cannot have? Be honest here: people overestimate the judgement in their own work and underestimate it in everyone else's.

Can you check the output cheaply? For the reasons above, this is the question that decides whether anything gets built at all.

And how often does the task happen? Four hundred times a day compounds. Twice a month is a distraction, however loudly someone hates it.

Ranked that way, the right first system is usually obvious, and usually not the one in the slide deck. Where a category is standardised enough that someone has productised it, buy it. Everywhere else, and for most operating companies that is where the majority of the value sits, the system has to be built on your data, your ERP, your rules, by engineers sitting inside the operation long enough to learn how the work actually happens.

The hard part was never the models. It is knowing which workflow to point them at, and that is not knowable from a distance.