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 its 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 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 and 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 get, under this year's rules, for this specific project.
The cost of finding out is roughly the same whether the utility serves eight hundred thousand people or eight thousand. So 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, at a price point that lets a small community have somebody look at what funding is available to them. That is a good business and a useful one. It is also a description of a market failure: the utilities with the least capacity to navigate this are the ones for whom outsourcing it makes the least economic sense.
The work itself goes in steps. She has to know the programs exist, and read this year's rules rather than last year's. She tests a utility's population, income and system characteristics against each set of thresholds. She has to know which programs stack and which are mutually exclusive, and track 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 what usually happens is 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. All of it is public and none of it is convenient. It is the same reading problem as everywhere else in this market, pointed at the money.
Eligibility is decided by rules. 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. The model 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. The model thought so is no basis for a small utility spending three months on an application.
Definitions never travel. Whether a community counts as disadvantaged is a different determination under each program, computed under that program's own definition and cited to it. If you let one definition stand in for another, you get a confident, plausible, wrong answer.
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, and 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 I would rather say so than present each as its own clever thing. Take a structured document apart, work out what each section needs and where that comes from, and fill what can be filled from what is already known. 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, instead of a blank form and a deadline. For a manager doing this in the evenings, that 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, and 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 tells you what to fix. So does a match requirement nobody has budgeted for, and so does a program that would fit except that it requires a plan the council has not adopted, which means the barrier was never financial.
I have seen the same pattern in the filtered-out bid queue and in the accounts a monthly report declines to promote: what the system rejected carried more information than what it selected. I did not plan that, and I no longer think it is a 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. 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.
The same physical work can often sit under more than one heading, though. 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. Her observation was that invoking security switches a switch, because the work stops being upkeep and starts being protection.
This needs care, because it could read as a trick. Relabeling a project to slip it past somebody is something else. 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 for the utility, which is the customer here. That creates an obvious problem, and I should state it.
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 move by a single position. The utility still gets the straight answer, including the one that says none of these are worth your time this cycle.
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 moves. That relationship stays clean as long as information flows in that direction and the ranking does not bend.
What it cannot do
The utility submits it, and that is not a formality. What comes out is a draft: the utility reviews it, finalizes it, and puts its own name to it. The consultant was blunt on this point. 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 has to be earned. 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. In practice, 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 instead of an inference, and building a system that will say not covered took more discipline than building the matching did.
It gives guidance. 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.
AquaIntel matches each utility against funding programs by rule, explains the near misses as well as the matches, and prepares the application from what the utility has already published.
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.