The bid you already knew about
The whole argument of this company is that once a request for proposals is published it is already too late, so building a workflow that captures published bids looks like a contradiction. Customers asked for it anyway, and working out why taught me the most useful thing I know about how this market works.
Everything I have built rests on one claim: by the time a utility publishes a request for proposals, the useful part of the opportunity is over. The specification has been written, usually with help from an engineering firm, and whoever was in the room while it was being written has already won something the bidding cannot give back. I have said that on more calls than I can count, and I meant it.
So a workflow that captures published bids ought to be the last thing this company builds. Customers asked for it anyway, repeatedly, and the reason they gave was better than my objection.
Being early does not excuse you from the bid
The mistake in my original position was treating early engagement and bid response as alternatives. They are sequential.
You work an account for two years, you shape the thinking, and the specification comes out looking like something you could win. Then you still have to see that it published, and respond to it, on time. Being early changes your odds inside the paperwork, and you still have to do the paperwork.
The failure mode is grim, because it is invisible. A customer described their version of it plainly:
When we find out about bids a lot of times, it's too late. We'll keep answering to it, putting our best proposal together — or probably influence the RFP or create great relationships. It limits our ability to grow.
That is a company doing the right long-term work and still losing bids for purely clerical reasons. Nobody writes that up as a lost deal. It goes in the record as we bid and did not win, when what happened is that they found out on a Thursday for a Monday deadline.
Why nobody does it well
The information is not hidden. Published bids are, by definition, published, and there is a whole industry of aggregators selling access to them. Several of my customers already subscribe to one.
The problem is on the other side of collection. When we mapped it properly for one company, it came apart into five separate frictions, and another subscription solves none of them.
Somebody reads everything by hand. A dedicated person works through municipal bids (hospitals, schools, road resurfacing, utilities) looking for the handful that touch what the company sells, buried in thousands of listings that mostly do not.
The sources do not agree with each other. A bid platform subscription, a second bid platform subscription, federal databases, state procurement sites, individual utility pages. There is no unified view and no cross-reference, and no way to know whether the gap between two of them is a real gap or a duplicate.
Nothing separates relevant from adjacent. There is no automatic way to tell a bid that needs what you make from one that needs equipment, or civil works, or something unrelated that merely uses the same vocabulary. That judgment is entirely in the screener's head.
Distribution is manual too. Whatever survives gets forwarded by hand to reps across territories. This is the part I keep coming back to, because it is where the whole thing quietly fails: prioritization matters more than volume, and volume crowds it out. A rep who receives forty items receives none.
And the route to the buyer is not one route. The same opportunity may reach the utility through a system integrator, a distributor or an engineering consultant, and which pathway it travels changes who you should be talking to about it.
Every one of those is a person spending real hours on work that produces nothing except the absence of a missed deadline.
What the workflow does
Capture from wherever they appear, including where you already look. If a customer subscribes to a bid database, we integrate with it instead of asking them to drop it. The reason is practical. Those feeds are good at what they do, the customer has already paid for the year, and replacing a working source with our own version of the same thing would be a lot of effort spent arriving back where we started. Where the feeds have gaps (a state they cover thinly, a utility that posts to its own site and nowhere else) we build a pipeline for that gap specifically.
This decision keeps coming up. We made the same call on the CRM, on the sending infrastructure and now on the bid feed: each time the answer has been to sit on top of something the customer already runs and not to ask them to move.
Judge relevance against this customer. A solicitation for membrane replacement is noise to a metering company and the whole quarter to somebody else. Relevance is a function of what you sell, where you sell it, what size of contract is worth your time, and which utilities you already have a position in.
Send fewer. The default behavior of a feed is to forward everything and let you sort it out, which is how a subscription ends up as a folder nobody opens. The job here is the opposite, and the shape of a night's work makes the point better than an argument: a couple of hundred solicitations captured, a dozen or so relevant, and three that need a person to make a decision about them. The value is not in the two hundred. It is in the three.
And say why. Every surfaced solicitation arrives with four things attached. First, why this bid, in plain terms: you have sold into this utility twice, the specification names a process you run, the value sits in the range you win in. Second, the associated documents, so nobody has to go hunting for the addenda. Third, any compliance signals buried in the requirements. And fourth, the deadline, early enough to be acted on.
Without the reasons, nobody is going to trust a filter that is telling them to spend a week writing a proposal.
Taking that seriously has two consequences. The first is that what was filtered out has to be as visible as what came through. A screener who cannot audit the rejections has been asked to trust the system instead of checking it. The second is that not everything divides cleanly. Bids the system is confident about go straight to the person who should see them. The middle band goes to a review queue where a human decides, quickly, in a list built to be worked through.
That is the same design as the verified-and-candidate distinction in the contact workflow, arrived at independently and for the same reason: a system that hides its own uncertainty gets believed, including the day it is wrong about something that mattered.
Connect it to what you already knew. This is the part the aggregators cannot do, and it is the reason this workflow is worth building at all instead of buying from somebody's product catalog. A published solicitation arriving cold is a deadline. The same solicitation arriving attached to eighteen months of board minutes, the consultant who was engaged, the budget line that appeared last spring and the two people you have already spoken to is the last step in something you have been following all along.
Bids / RFP 26-114 / In context
The RFP is also a scorecard
I did not expect this part, and it is the reason I stopped resisting this workflow.
If the monitoring workflow claims it can see a procurement forming two years out, that claim needs testing. The published solicitation is the test. It is the moment the prediction either landed or did not, stated publicly, with a date on it.
Capture the bids and you can ask the only question that matters about early signals: of the opportunities that eventually published, how many did we flag, and how far ahead? That is a measurable thing, and until you are capturing the end of the story you cannot measure it at all. So the workflow I was reluctant to build is how the rest of the system gets graded.
The filtering can be graded too, and against a fair standard: the person who was doing it by hand. Run both in parallel for a month, compare what each surfaced, and you get precision and recall against a human baseline. You also get the things that matter operationally, like whether it routed to the right person and how long it took to raise the alert. That is a more honest test than any accuracy figure quoted in isolation, and the incumbent process is the benchmark. If the screener catches things the system misses, that is the answer, and you go and fix it.
There is a quieter kind of grading that matters just as much. Every source this thing reads can change without telling you (a portal reorganizes, a page template shifts, a feed starts returning slightly different fields), and a scraper that has silently stopped finding anything looks exactly like a quiet week. So the health of each source is surfaced as something you can look at, and parser drift shows up on a screen.
The award record does the same job one step later. Who won, at what value and on what terms feeds back into the installed-base picture as the next entry in that utility's equipment history and the start of somebody's contract clock.
What it cannot do
It cannot make a late bid early. If a solicitation publishes with a three-week window and you have never spoken to the utility, capture gets you into a race you are running from the back. The workflow tells you the race exists. Everything upstream of it is what decides whether that is worth anything. At AquaIntel, each captured solicitation arrives with that upstream history attached: the minutes, the budget line, the consultant who was engaged, and the reason it was sent to you.
Related
- The proposal you already wrote: whether a given bid is worth answering, and how much of the answer already exists.
- Fifty thousand is not a market: deciding which utilities are worth watching in the first place.