The proposal you already wrote

Deciding not to bid is the first piece of intelligence

An RFP feed on its own is a list of obligations. What makes it worth anything is the judgment applied to each item, and the first judgment is whether to respond at all.

Responding properly is expensive. A serious proposal is days of work from people whose time is the scarcest thing the company has, and every bid answered badly because it was answered in a hurry is worse than not bidding. So the first thing to do with a captured solicitation is score it against what a good bid looks like for this company.

And that definition is theirs, not ours. The customer sets the criteria — what they sell, the contract sizes worth their time, the utilities and regions they want to be in, the technical requirements they can actually meet, whatever else they have learned from bids they wished they had skipped. We apply it and show the working.

That distinction matters more than it might appear. A fit score produced by somebody else's model is an opinion you are being asked to accept about your own business. A fit score produced by your own criteria, applied consistently to several hundred solicitations a week, is a policy you already had and could never enforce at that volume. The second is a much easier thing to trust, and the only one that survives a sales director asking why the system rejected something they liked the look of.

How little time there is for this is the part outsiders underestimate. One customer described his own budget for it exactly: he is the person who filters incoming solicitations, and he did not want to spend more than twenty minutes a day doing it. Ever.

That is the constraint the whole workflow has to fit inside. Twenty minutes a day, against a stream of bids that each represent a possible week of work for his colleagues. Anything that asks him to open a second tool, build a query, or read a page of explanation has already failed — not because he is impatient, but because the arithmetic of his job does not permit it.

Sometimes the answer is no, and that answer is the valuable one. I have written elsewhere that saying no fast is the kindest thing you can do when you are on the other side of a pitch. The same is true here, in a more mercenary form: a fast, well-reasoned no returns a week to your proposal team. A slow no costs the week and loses anyway.

Then most of the answer is already written

The second judgment is less philosophical and more immediately useful.

A proposal is not written from nothing. Most of what any vendor puts in an RFP response — how they approach the work, their safety record, their qualifications, their past performance, how they handle a dozen recurring requirements — they have written before, many times, in previous responses that went out and sometimes won.

So the company uploads what it has — the previous responses, the standing qualifications, the boilerplate that has been through legal — and the application gets deconstructed section by section, each section answered from that material. Roughly eighty per cent of it arrives already drafted. Then a person reviews it, edits it, and decides what to keep — because the last twenty per cent is the part that is actually about this utility, and that is exactly the part someone should be spending their day on rather than retyping a safety statement for the ninetieth time.

The mechanism is worth being precise about, because "AI writes your proposal" is a sentence that could mean almost anything. The RFP is reconstructed inside our platform — its structure, its sections, its questions, as a thing that can be worked on — and each section is answered there. What you get back is not a mysterious finished document. It is the application, laid out, with the answers filled in and visible next to the questions they belong to.

The effect is not a better proposal in the abstract. It is that the time to get a proposal out compresses enormously, which changes which bids are worth answering at all — and so loops back into the first judgment.

Two things worth noting about that machinery. The first is that it is the same engine as the permit product: the deconstruct-the-form-and-prefill-it approach was built for permit applications first and extends directly here, which is the clearest case I have of a side product paying back into the core one.

The second is an echo of the installed-base workflow: once again the raw material is the customer's own history, sitting in their own systems, unused. Their past proposals are an asset nobody had treated as one.

What it cannot do

It does not write the part that matters. Prefill produces the eighty per cent that is the same every time. The remaining fifth — why this utility, this problem, this approach — is the part a proposal is actually judged on, and no amount of drafting from your own back catalogue produces it. A company that treats the prefill as the whole job will submit faster and win less.

I went looking for a harder limit than that — a format that defeats it, a procurement rule about machine-drafted responses, a portal nobody can automate — and did not find one worth writing down. Which is worth saying plainly, because the boundary that actually binds here is not technical. It is that the eighty per cent was never the hard part, and a company that mistakes speed for a case will discover this at a rate of one lost bid at a time.

Next

Everything in this series so far assumes you already know which utilities are worth the attention. The next piece is the one that decides that: screening a market of tens of thousands down to the accounts a single vendor should actually care about — and why the honest end of that process is a much shorter list than anyone expects.