Anatomy of a quoting automation rollout: what eleven weeks actually looks like.

Consider a mid-sized manufacturer with a quoting problem: incoming RFQs arrive on three channels — email, a web form, and phone. Each gets manually entered into a quoting tool by hand, by one of three people, with responses turning around in twenty-four to seventy-two hours. The CFO wants turnaround under four hours.

This is a composite scenario describing how that kind of rollout typically unfolds — week by week, where it breaks, and what the numbers actually tell you when it lands.

01. Week one is rarely what you expect

The first useful conversation in a week-one kickoff is rarely with the team that owns the workflow. It tends to happen at the edge — with whoever is closest to the incoming requests.

This is the person who knows, before anyone in operations, which incoming requests are "easy" — repeat orders from existing customers, standard part numbers, predictable margins — and which are "hard" — new customers, custom specs, anything urgent. The pricing team is typically not asking them. But they should be.

A well-run week-one session treats this person as a source of ground truth. In an afternoon, they can produce a more accurate triage taxonomy than anything in the existing CRM. That taxonomy is the eval set you need — even if you do not know you need one yet.

The pattern shows up in every corner of operations: the person closest to the intake knows things the org chart does not.

This is the first lesson in any rollout like this, and it is not technical. Talk first to the people who handle the inputs. They have been compressing the business into mental models for years. Those mental models are the eval set you are about to need.

02. The eval is boring and saves the project twice

Before any model touches a real RFQ, a working eval set for this kind of rollout looks like forty historical quotes — selected with the intake person and the pricing lead — with their actual outcomes attached. The agent produces a quote within tolerance of the historical answer, or it does not go forward.

Building this is unsexy. It is also what lets the project sleep at night.

Evaluation typically catches two regressions that would otherwise ship. The first is usually a product category where the model underprices with high confidence — by an amount that, across a quarter, would erode more margin than the project saved. The second is usually a class of urgent jobs the agent prices at standard rates, because urgency is not captured in the input fields.

Without evaluation, both ship. With evaluation, both surface in week six and get patched before the rollout.

03. The hardest part is not the model

Once the agent works — comfortably, by week seven in a typical rollout — what follows is the part nobody budgeted for: change management. The pricing team will not trust the system at first. This is rational. They have been mispriced by people for years; now it is a machine.

The pattern that works is three steps, none of them technical:

• Agent outputs are drafts, not decisions. Every quote has a "send" button that requires a human to press it. For four weeks, that button is the project.
• Build a one-sided audit trail. Every quote the agent produces is visible alongside the policy sections it used. The pricing lead can spot-check ten quotes a day in fifteen minutes.
• Let the team override — and log the overrides. Every override becomes an eval case. The agent improves quickly on the cases the humans care about most.

By week nine, a well-run team is sending agent drafts unchanged for easy categories and reviewing only the hard ones. By week eleven, sixteen-minute turnaround is the operating reality.

04. Two near-misses that end projects like this

In a rollout like this, the obvious risks — model drift, hallucination, integration failure — are not what kill launches. The two near-misses that actually end projects are:

A deadline that slips early. A board date moves three weeks forward, and the "pilot" becomes "a result we have to announce." The team that holds the line on this survives. The team that does not ships without evaluation, and writes a different postmortem.

A team member who starts wondering if they are being replaced. This one is solved — directly, in a one-on-one — by their manager. Budget that conversation. It will happen. Avoiding it is a way of cancelling the project.

05. What the number actually means

Sixteen minutes is the headline. The CFO gets the board win. But the numbers that matter more are:

• The intake person's afternoon. It comes back. The routine data entry stops, and they often start — on their own initiative — flagging customer behaviour the CRM was not capturing. That is a separate, smaller project.
• The pricing team headcount. It does not change. The hours spent re-keying go to harder pricing decisions on the jobs that needed judgment.
• Margin variance in the high-complexity product category. Tightened by three points — almost entirely because of the regression evaluation caught in week six.

The headline number ships the project. The shadow numbers are why the project was worth doing.

A short closing

If you are setting up a project like this, what to know before you start is not technical. It is:

1. Talk first to the people closest to the intake. They know more than the org chart says.
2. Build the eval set with them, not separately.
3. Treat the change management conversation as a deliverable, not a side effect.
4. The shadow numbers — time returned, variance tightened — are what compound.

The model was the easiest week of the project. The other ten were people, process, and the unfashionable habits that make a rollout survive.