10 min· building· ai· water
We don't have the budget
A sales lead at a leak-detection company came to a demo with one question from his CEO: can you connect utilities to funding? Two years of conversations had ended the same way, at 'we don't have the budget'. The money usually exists, fragmented across programs nobody has the hours to work through. This is the workflow that finds the match and then fills in the application — and the one whose customer is the utility rather than the vendor.
In January a sales lead at a company that sells leak detection to water utilities came to a demo with one question from his CEO. Do you have a way of connecting utilities to funding?
His situation was the usual one. The pipes under most American cities are a century old in places, they leak, and no utility can tear up every road to replace them, so a system that finds the leaks is an easy conversation to start. He had dozens of utilities in his pipeline at different stages, and after two years of those conversations his summary was that it always comes down to budget. He was clear-eyed about what we could do about that: whether a utility has a budget is down to the utility, and nobody outside it has that answer. But if we could tell him what a given utility could get funded for, his CEO would buy that. The account profile we had actually come to demo was nice to have.
He was describing the sentence that ends conversations in this market, and everybody selling into it has heard it in the same flat tone.
We don't have the budget.
It is usually not a negotiating position and it is usually not quite true either. There is a great deal of money available for American water infrastructure — state revolving funds, federal loan programs, rural development, hazard mitigation, community development money, a long tail of state schemes. What is missing is not the money. It is the hours required to find out which of those a particular utility could actually get, under this year's rules, for this specific project.
That gap has a shape, and the shape is that the cost of finding out is roughly the same whether the utility serves eight hundred thousand people or eight thousand. Which means it is trivial for the large ones and prohibitive for everybody else.
The job, as it exists today
To find out what answering him would take, I went to a grant consultant who does exactly this work, alone, for municipalities in one state.
Her practice exists because of the arithmetic above. She deliberately serves the communities that are, in her words, too small for it to be worthwhile for the consulting firms to go after — offering a price point that lets a small community have somebody look at what funding is actually available to them. That is a good business and a useful one, and it is also a description of a market failure: the utilities with the least capacity to navigate this are the ones for whom navigating it is least economic to outsource.
What that work involves is discovery, interpretation, packaging and coordination. Knowing the programs exist. Reading this year's rules rather than last year's. Testing a utility's population, income and system characteristics against each set of thresholds. Knowing which programs stack and which are mutually exclusive. Tracking cycles that open and close on dates published in no single place.
For a large utility that is somebody's job. For a small one it is the utility manager, in the evenings, and the honest outcome is usually that they apply for the program they applied for last time.
What the workflow does
It assembles the funding picture from the public record. What the utility has borrowed and for what, what it has been awarded before, what its capital plan commits it to, how its rates and coverage look. Public, and not convenient — the same reading problem as everywhere else in this market, pointed at the money.
Eligibility is decided by rules, not by a model. This is the sharpest design line in the product. A language model reads program documents and turns them into structured rules; that is extraction and it is what models are good at. It does not decide whether a utility qualifies. That runs through the rules, deterministically, and can be traced — because eligibility is a claim somebody will act on, and the model thought so is not a defensible basis for a small utility spending three months on an application.
Definitions never travel. Whether a community counts as disadvantaged is not one fact; it is a different determination under each program, computed under that program's own definition and cited to it. This is exactly the sort of thing that produces a confident, plausible, wrong answer if you let one definition stand in for another.
And it explains in both directions — why each program matched, and why the near misses did not.
Then it prepares the application. Matching is only the first half of the job. On its own it leaves a utility exactly where the consultant finds them: now knowing which program to apply to, and still facing the package. So the second half assembles it — the documents that program requires, the forms filled from the utility record already held, the standard sections drawn from what the utility has itself published.
This is the same machinery as the proposal pre-fill and the permit package, and it is worth saying plainly rather than presenting each as its own clever thing: take a structured document apart, work out what each section needs and where that comes from, fill what can be filled from what is already known. Three different documents, three different regimes, one capability. Once you have built it for a regulator you have most of it for a funder.
What the utility receives is a pre-filled application to review, finalize and submit, rather than a blank form and a deadline. That is the difference between a shortlist and an outcome — and for a manager doing this in the evenings, it is most of the reason the application gets filed at all.
Funding / Marlow Creek Water Department / Programs
The near miss is the product
A list of what a utility qualifies for is table stakes. Any competent system produces one.
The list of what it nearly qualifies for is the one people read twice, because it is the only part that tells you what to change. Missing a threshold by a small margin is not a rejection, it is an instruction. So is a match requirement nobody has budgeted for. So is a program that would fit except that it requires a plan the council has not adopted — which tells you the barrier is not financial at all.
That is now three workflows where the thing the system rejected carried more information than the thing it selected, after the filtered-out bid queue and the accounts a monthly report declines to promote. I did not plan it as a theme and I have stopped treating it as coincidence.
The category is the whole game
The most useful thing the consultant taught me is not in any program document.
Funding follows capital. A project that reads as maintenance is structurally hard to fund — and maintenance, as she put it, is the biggest battle in this sector, because municipalities will approve a large visible project and then quietly forget the upkeep it commits them to. Getting money for the upkeep is pulling teeth.
But the same physical work can often sit under more than one heading. A program framed as maintenance is a hard sell to a council; the same program framed as resilience, or as security, is a different conversation entirely — her observation was that invoking security switches a switch, because it stops being upkeep and starts being protection.
That is not a trick, and it is worth being careful about the difference. It is not relabelling a project to slip it past somebody. It is that public budgets are organized by category, most work legitimately belongs to more than one, and which category you file under decides which pots you can reach. A practitioner knows this. A system that only matches on stated project type will never surface it, and that is a real limit on what automated matching can do without somebody who has done this before sitting next to it.
Whose side this is on
Almost everything I have written here is for a vendor selling into this market. This one is not: the customer here is the utility. That difference creates an obvious problem and it would be dishonest to leave it unstated.
The same company cannot rank funding programs for a utility while selling market intelligence to the vendors who want that utility's business, unless the separation is structural rather than a promise. So the ranking is not influenced by vendor relationships, and a vendor is in a utility's funding workspace only if that utility asked them to be.
The connection that is legitimate runs back to the sentence at the top of this article. A vendor's conversation stops dead at we don't have the budget, and today it stops there permanently, because the rep has no idea what the utility might qualify for and no standing to find out. What they want is to be able to say: here are things you could plausibly get funded for, and here is somebody who does this properly. That is a better outcome for everyone in the room, and it does not require the ranking to bend by a single position — the utility still gets the honest answer, including the honest answer that says none of these are worth your time this cycle.
Funding is the timing valve of this market. A project gets built when it gets paid for, and procurement follows capital rather than need. So a vendor watching funding is watching the thing that actually moves. That relationship is honest as long as information flows in that direction and the ranking does not.
What it cannot do
The utility submits it, and that is not a formality. What comes out is a draft: the utility reviews it, finalises it, and puts its own name to it. The consultant was blunt about this neighbourhood — automated documents in a regulated process carry exposure somebody has to be willing to own — and she is right. The answer is the one the permit article arrives at from the other side: the machine assembles, a person owns the submission. The difference here is that the person owning it is the applicant rather than a licensed third party, which makes the review lighter and does not make it optional.
Coverage is earned, not claimed. Every program has to be loaded, verified against its own source, and kept current as rules change — which is ongoing human work at an ongoing cost. The practical consequence is that coverage of programs is far narrower than coverage of utilities: we can describe utilities across several states while holding verified program rules for a much smaller footprint, mostly one state plus the federal channels. So a request outside that footprint has to return not covered rather than an inference, and building a system that will say not covered took more discipline than building the matching did.
And it is guidance, not determination. Nothing here tells a utility it is eligible or that it will be funded. Only the program decides that. What it can say is that on the published rules, as verified on a stated date, this is how the utility appears to sit — and where the uncertainty is.
Related
- Ninety percent of a permit is cookie cutter — the other document built the same way, for a regulator rather than a funder.
- Nobody reads the minutes — the reading problem, pointed at agendas instead of program rules.