Skip to content
Vinod Jose

5 min· building· ai· water

The proposal you already wrote

On the RFP fit-check and response pre-fill. Answering a request for proposals properly costs days of the scarcest people in the company, so the first useful judgment is whether to answer it at all. The second is that most of what you are about to write, you have written before.

Deciding not to bid is the first piece of intelligence

I believe 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 takes days of work from the people whose time is scarcest in the company, and a bid answered badly because it was answered in a hurry is worse than no bid. So the first step with a captured solicitation is to score it against what a good bid looks like for this company.

The customer defines what a good bid looks like, and we apply it. They set 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 meet, and whatever else they have learned from bids they wished they had skipped. We apply those criteria and show the working.

This matters because of who has to trust the result. A fit score from somebody else's model is an opinion about your own business that you are asked to accept. A fit score from your own criteria, applied the same way to several hundred solicitations a week, is a policy you already had and could never enforce at that volume. That is much easier to trust, and it is the only version that holds up when a sales director asks why the system rejected something they liked the look of.

TWO JUDGMENTS BEFORE ANYONE WRITESfit scoreyour criteria · yes / no80%from prior responses20%this utilityprefill the recurring sections; write the part that is about this utility
Two judgments before a scarce person writes anything: whether to bid at all, and which parts of the answer already exist. The fifth that is genuinely about this utility is the only part that was ever hard.

People outside the job underestimate how little time there is for this. 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.

The whole workflow has to fit inside that. Twenty minutes a day, against a stream of bids that could each mean a week of work for his colleagues. If it asks him to open a second tool, build a query or read a page of explanation, he will not use it, because his day simply does not have the time.

Sometimes the answer is no, and that is the useful answer. 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 holds here, for more practical reasons: a fast, well-reasoned no gives your proposal team a week back. A slow no costs the week and loses anyway.

TWO WAYS TO DECLINEa fast, reasoned noreturns the weeka slow nospends the week and loses anywaydeciding not to bid is the first piece of intelligence
A slow no costs the week and loses anyway. What makes this worth automating is not the decision but the arithmetic of the day it sits in, which does not permit opening a second tool to reach it.

Then most of the answer is already written

The second judgment is more practical still. 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 workflow runs in steps:

  1. The company uploads what it has: previous responses, standing qualifications, and the boilerplate that has been through legal.
  2. The RFP is reconstructed inside our platform, with its structure, sections and questions laid out as something that can be worked on.
  3. Each section is answered there from the uploaded material. Roughly eighty percent of it arrives already drafted, with each answer next to the question it belongs to.
  4. A person reviews it, edits it and decides what to keep.

The last twenty percent is the part about this particular utility, and that is where someone should be spending their day, rather than retyping a safety statement for the ninetieth time. So that is the process: the application laid out with its answers filled in, where you can check every one.

THE APPLICATION, LAID OUTANSWERED FROM PRIOR WORK1applicant information2project summary3need and opportunity4approach and plan5impact and outcomes6budget and resourceswritten for this utilitythe eighty percent was never the hard part
Not a mysterious finished document: the application laid out section by section, with the recurring answers already in place. The open row is the work; everything above it has been written before.

The main effect is speed. The time to get a proposal out drops a lot, and that changes which bids are worth answering at all, which takes you back to the first judgment.

Two more things about how it works. It is the same engine as the permit product: the approach of taking the form apart and prefilling it was built for permit applications first and extends directly here. That is the clearest case I have of a side product paying back into the core one.

It also echoes the installed-base workflow: once again the raw material is the customer's own history, sitting in their own systems, unused. Their past proposals were an asset nobody had treated as one.

What it cannot do

It does not write the part that matters. Prefill produces the eighty percent that is the same every time. The remaining fifth (why this utility, this problem, this approach) is what a proposal is judged on, and no amount of drafting from your own back catalog produces it. Submitting faster does not make a bid better.

I went looking for a harder limit than that, such as a format that defeats it, a procurement rule about machine-drafted responses, or a portal nobody can automate. I did not find one worth writing down. The limit that binds here is not technical: the eighty percent was never the hard part.

If you want to try this on your own pipeline, start with the criteria. Write down what a bid worth answering looks like for your company, then look at last quarter's RFPs against it and count how many you would have skipped. AquaIntel makes both judgments: it scores each RFP against your criteria, and for the ones worth answering it drafts most of the response from what you have already written, for a person to review.