The bid you already knew about

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, the specification comes out looking like something you could win — and then you still have to see that it published, and respond to it, on time. Being early does not exempt you from the paperwork. It changes your odds inside the paperwork.

And 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

Not because the information is 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, and when we mapped it properly for one company it came apart into five separate frictions, none of which is solved by another subscription.

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. No unified view, 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 — and 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 human being 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 rather than asking them to drop it. That is not politeness. 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 is the third time in this series the same decision has come up. Not the CRM; not the sending infrastructure; not the bid feed. Each time the answer has been to sit on top of something the customer already runs rather than to ask them to move.

Judge relevance against this customer, not in general. 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, not more. 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 genuinely 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: 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; the associated documents, so nobody has to go hunting for the addenda; any compliance signals buried in the requirements; and the deadline, early enough to be acted on.

A filter you cannot interrogate is just a black box with better manners, and nobody trusts a black box that is telling them to spend a week writing a proposal.

Two consequences of taking that seriously. 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 rather than to check it, and those are different things. 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 rather than admired.

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 is asking to be believed, and it will be, right up until 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 belongs in this series rather than in somebody's product catalogue. 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 a different object entirely. One is a task. The other is the closing chapter of something you have been reading.

The RFP is also a scorecard

Here is the thing I did not expect, 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.

Which means the workflow I was reluctant to build turns out to be 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 rather than against nothing — along with the things that actually 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 it has the useful property that 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 a thing you can look at. Parser drift shows up on a screen, never in silence.

The award record does the same job one step later. Who won, at what value, on what terms — feeding 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 in this series is what decides whether that is worth anything.

Next

Capturing a solicitation and deciding what to do about it are different jobs, and the second one gets its own piece: whether a given bid is worth answering at all, and how much of the answer you have already written.

After that, the workflow that decides which utilities are worth any of this in the first place — screening a market of tens of thousands down to the accounts a single vendor should actually care about.