Minus 78% Time, Minus 95% Errors: An Agentic Process a Decade Before LLMs

In 2016 we had no language models. No assistants, no vector databases, no word "agent" in today's sense. We had PHP, a CRM, and a sales team assembling every commercial proposal by hand, every day.

For that team we built an internal service — a proposal generator. It cut proposal preparation time by 78% and errors in sent documents by 95%. That is exactly the order of magnitude shown today on AI pilot slides. With one difference: we had nothing that could write text.

What preparing one proposal actually involved

A rep would get a request and start assembling the document: open the price list, work out the cost on a calculator or in their head, then go into the product catalog for photos. The catalog was large, built for warehouse lookup rather than sales, and finding three matching images took longer than writing the whole proposal. The document itself was laid out in Word, however each rep knew how. One proposal took anywhere from half an hour to half a working day.

The defects this produced were not random. They repeated, and they can be listed.

Arithmetic. Manual calculation always produces errors — only the frequency varies. A discount calculated off the wrong base. A forgotten tax line. A mixed-up unit of measure. It surfaced at the invoicing stage, or never surfaced and was paid for out of margin.

Incomplete terms. The proposal would price the work itself but leave out everything else: delivery, installation, custom adjustments. The client found out about the extra costs only after deciding to buy. From there, two options, both bad: either the company eats the difference itself, or it opens a conversation trust never fully recovers from.

Missing contact details. The document went out without the responsible rep's phone number or email. A client with a question had to go hunting for someone to ask. Some didn't bother.

Photos. Some reps used whatever image the catalog returned first; others used none, because searching took too long. The same service, proposed by two different reps, looked like it came from two different companies.

Layout. Everyone formatted differently: their own fonts, alignment, heading colors. The brand identity lived in the brand book — a document the client never saw. It was absent from the ones the client did see.

Look at the third column. Four defects out of six go unnoticed by anyone inside the company. Only the client sees them — and doesn't report them, just stops responding.

Why this was never a writing problem

None of these defects trace back to wording. The problem was assembly: how many manual steps a rep performed between "the client asked" and "the document is ready," and how many of those steps could go wrong.

The number matters not on its own but because it is stable: different studies with different samples have reproduced it for over a decade. A sales team is a function that spends most of its time not selling. And the most expensive part of that "not selling" is manually assembling documents nearly identical to the one before.

What kept breaking after the proposal was sent

Assume the document was assembled correctly. The second half of the journey has its own breakdowns.

The proposal never arrived. The attachment was forgotten. The email landed in spam. It was sent from a personal address and got filtered. The rep is certain the job is done; the client is certain they've been forgotten. Neither knows the two versions disagree.

The proposal reached the wrong person, or the wrong version. A mixed-up name, someone else's company name, terms left over from a previous deal. One such mistake costs more than the half hour it saved: it tells the client their proposal is a copy, and that they are just standing in line.

No one knew what happened next. The email went out, and then silence. The rep would call blind a week later, or not call at all. The manager couldn't tell "not responding because not interested" from "not responding because it was never opened."

That last point looks trivial until you look at the cost of the delay.

The study is fifteen years old, and that is its strength: the technology has changed completely since, and the relationship held. Response speed isn't about courtesy. It's a conversion multiplier that works regardless of how good the proposal itself is.

What we actually built

The second version of the service worked like this. The system did the math: the rep selected line items, and cost, discounts, taxes, and additional charges were filled in by rule, not memory. Photos were pulled from the catalog automatically, linked to each line item. Layout was the same for everyone — the brand identity lived inside the document, not next to it. Mandatory blocks — the rep's contact details and the full terms — couldn't be skipped: without them, the document wouldn't assemble.

Sending was a single action from the deal card. The email reached the client in three to five minutes, and the document was filed to the deal automatically. From there, the service tracked whether the email was opened and whether the client clicked the links inside it. Those events triggered the next steps: one follow-up email if the client opened it, a different one if they hadn't opened it within three days. If the email went unopened, or landed in spam, the rep got a notification — telling them not to push harder, but to check the channel.

And separately, statistics accumulated: by rep, and by which offers were drawing the most demand.

Text generation stayed the simplest part of this design. The value came from the rules and the events.

The numbers, before and after

The remaining 5% of errors were, as a rule, things the system could never have caught: a misunderstood client request, or the wrong line item picked at the start. Everything that could be formalized was formalized, and stopped breaking.

2026: the same mistake, one layer up

Today's AI pilot is built along embarrassingly similar lines. The team measures answer quality on evals (evals — benchmark task sets used to test a model), argues over prompts, chooses between models, and runs a demo where the assistant outperforms a human employee. The demo succeeds. The process doesn't change.

Read that line about feedback again. It describes exactly the gap we closed in 2016 — phrased in 2025's language. A system that doesn't retain an event and feed it back stays a demo, no matter how smart the model inside it is.

Both pieces of work say the same thing, though written by different people using different methods. The effect — or its absence — comes down to three things, and none of them is about answer quality:

• whether the result reaches the system of record (system of record — the system where the company's authoritative data about a deal, document, or client lives), or stays in a chat window no one reopens the next day;
• whether an event is generated that feeds back and triggers the next action — with a human in the loop (human-in-the-loop — a setup where a person approves or rejects the decision) wherever the cost of an error is high;
• whether what happens inside the loop is visible: not "the team likes it," but numbers broken down by person, scenario, and failure.

A gap is where the work is formally done but the result doesn't move forward. In 2016 that was an email with no attachment, and a price with no installation cost. In 2026 it's a flawless assistant response that never got logged anywhere and never notified anyone.

Four questions to ask before launching an AI process

Frequently asked questions