There is no decision-maker

A sales engineer described his problem to me last winter in a way I have not been able to improve on:

A lot of sales guys go, "well, if I just knew the right people to call, I would call them." I'm not afraid of calling on people. It's just how do you penetrate them, and how do you know who they are and where they are.

Not a confidence problem. Not a pitch problem. He knew what to say and he was happy to pick up the phone. He just did not know whose phone.

The job, as it exists today

You have a list of utilities worth approaching — from the monitoring workflow, or from your own territory. Now you need the human beings.

The obvious version of this is a lookup: find the org chart, find the title, find the address. Every other industry solved that a decade ago with contact databases, and salespeople selling into ordinary companies do not think of it as a problem worth discussing.

This market breaks it in three separate places.

Why nobody does it

The title you are looking for does not exist. A customer put it more bluntly than I would have dared:

There's such a variety of titles in organizations. There's no one title. There's no one decision-maker. We're shooting at a target that in one organization it may be procurement director, in another it may be senior, and it may be a title completely unknown.

He is describing a structural fact, not a research difficulty. These are independent public bodies, tens of thousands of them, with no shared org design. The person who decides on a pump is a utilities director in one town, a public works superintendent in the next, and a board that meets monthly in the third. There is no title to filter on because there is no standard to filter against.

The org chart was never published. Most utilities of any size have a hierarchy that everyone inside understands and nobody has ever drawn. It exists in who reports on what at meetings, who signs which memo, who is copied on the engineering report.

And the tools that work everywhere else stop at the city limits. The large contact databases are genuinely good — at companies. Their coverage of American water utilities is decent for the biggest systems and thin to absent below that, which is precisely inverted from where the market is. A vendor selling into the long tail is asking who runs a three-person office in a town of nine thousand. That question has an answer, published in agendas and staff reports and minutes. It is simply not in anybody's database.

Then there is decay. Someone retires, someone moves, a role is merged into another, and nobody sends you a note. A contact list is a photograph of an organization that has already changed.

What the workflow does

Find the people in the documents. The corpus the monitoring workflow reads is full of names in context: who presented to the board, who signed the report, who the memo was addressed to, who answered the question about the failing pump. This matters more than it sounds. A name that appears next to a decision tells you something a directory entry never does — not merely that a person exists, but what they were doing.

Derive the structure. Since the org chart does not exist as a document, it gets reconstructed: names, roles, and who defers to whom across hundreds of mentions, assembled into our best account of what the hierarchy looks like. It is an inference, and it should be read as one. It is also, for most utilities, the only version of that picture anyone has drawn.

Work out the organization's email convention. Utilities rarely publish a staff directory with addresses. But enough addresses leak — in an agenda packet, a scanned letter, a contact box on a project page — to reverse-engineer the format. Gather the confirmed ones, rank the candidate patterns by how often each holds, and you have the shape of that organization's addressing.

Generate candidates, ranked. Apply those patterns to the people you have names for but no address, and each gets a small number of possibilities with a confidence attached, plus a note of whether that exact string already appeared somewhere in the corpus. Phone numbers come the same way, from the documents, where they are there at all.

Verify, and label what you could not. Some candidates get confirmed against a source or a delivery test. Those are marked verified. The rest stay candidates and are shown as candidates — the same verified-versus-unverified split the general contact tools use, for the same reason.

The rule underneath all of it is one line in our own internal documentation, and it is the most important sentence in this article: predictions are candidates until confirmed by a source or a bounce test; never write a predicted address into the contact graph as a verified fact.

How we learned to write that rule

By getting it wrong.

Early this year we shipped contact data to a customer with a wrong email address in it, and the customer found it before we did. What he said has stayed with me:

One email ID was wrong. If you use one of the large LLMs, they'll probably get like 80 to 90 per cent correct, but it's not accurate.

Eighty to ninety per cent correct is a good score and a bad product. A list where nine addresses in ten work is not a list you can hand a salesperson, because they cannot tell which nine — and the tenth costs them a bounce, a retry, and some part of their confidence in everything else on the page.

The instinctive fix is to get better at guessing. That instinct is wrong, and chasing it would have kept us at ninety-five per cent forever. The fix is to stop asserting what you have not confirmed. Once the output separates verified from candidate, the verified set can be trusted completely, and the candidates remain useful, because someone who knows a line is a guess treats it as one.

What changed was not the accuracy of the prediction. It was the honesty of the label.

There is no committee either

The title of this piece has a second half.

Once you accept that no single person decides, the obvious correction is to find the group that does — the buying committee. That is closer, and still wrong, because a utility does not have a buying committee. It has a different one depending on what you are selling. The people who decide on treatment chemicals are not the people who decide on pumps, who are not the people who decide on software, and the budget the money comes out of is different in each case.

So the output is a stakeholder map, drawn per product category rather than per organization: who sits on the buying committee for this kind of purchase, who influences it without sitting on it, who actually decides, and who holds the budget.

The three-way split holds inside each of those maps. Someone will use the thing. Someone signs for it. And — the one outsiders miss — a consulting engineer wrote the specification months before either of them was involved. Sell to the first and you get enthusiasm without budget. Sell to the second and you enter a procurement process you were never shaped into. Miss the third and the specification already describes somebody else's product.

Some of that decay we catch. Changes in the leadership layer — the senior roles that turn over most visibly and matter most to a first approach — are tracked, so a director leaving surfaces rather than sitting in the map as a fact that stopped being true.

Below that level we do not, yet. A supervisor moving between departments passes unnoticed until something in the documents contradicts the record, and the further down the structure you go the older the picture is likely to be. It is on the roadmap, and until it ships the right way to read the lower half of one of these maps is as of the last time this organization wrote something down.

The mistake almost everyone makes

The default motion in this market is volume. Get a large list, write one reasonable email, send it to everyone on the list, and accept a low response rate as the cost of doing business. Spray and pray, and hope something lands.

It does not work here, and the reason is specific rather than moral. A utility is not a consumer and not a startup; it is a public body with a particular plant, a particular set of problems it has been minuting for years, and a budget cycle it cannot deviate from. A message that could have been sent to any of ten thousand of them announces, in its first line, that you know nothing about this one. The people receiving it have seen a hundred of those. The correct response to a generic email about pumps is to ignore it, and they do.

What works is the opposite, and it is uncomfortable because it looks like doing less. Pick a small number of utilities — ten or twenty that genuinely matter to you — and know them properly. Their pain points, their situation, what they have been arguing about at board meetings, what they have already tried. Then write to those people about that.

I am aware how this sounds coming from someone who sells intelligence on tens of thousands of utilities. The screening workflow exists precisely to cut that number down, and the honest end of that process is not a list of five hundred accounts to email. It is a list of ten or twenty to actually understand. Everything else in this article is in service of the second list.

Which is what the drafting is for

A stakeholder map is still only knowledge. The reason to build one is that it makes the writing possible.

Because the same system holds the utility's context and the seller's, it can draft the approach rather than leaving it to whoever opens the record: an email pitched at the actual state of the relationship and at what this particular utility is dealing with. A first approach to someone who has never heard of you is a different letter from a follow-up to a person you met at a conference, which is different again from a note to an account you have sold to for a decade. Sequences rather than single sends, because a first email going unanswered is the normal case and not a failure.

That is a campaign designed where the context lives, which is the only place it can be designed well — and if you are writing to twenty utilities rather than two thousand, being right about each one is affordable.

What it cannot do

It does not send anything. The campaign is designed in our system and handed to yours — you plug in whatever outbound infrastructure you already run, and the mail leaves from there. That is a deliberate line rather than a missing feature. Deliverability, domain reputation and consent are somebody's whole job, they are already solved inside our customers' stacks, and a company that starts sending mail on other people's behalf has quietly become a different company. The same instinct that decided not to become the CRM applies here.

And the whole method rests on something leaking. Patterns are inferred from addresses that appear in public documents, so a utility that has never published a single staff address gives you nothing to infer from. That is rare in a system of any size and common at the very bottom of the market — inconveniently, the same long tail the general databases also miss. For those, the workflow still tells you who the people are, because names appear in minutes whether addresses do or not. It cannot tell you how to reach them, and it says so rather than guessing.

Direct lines and personal addresses are out of scope for the same reason as the asset registers in the last piece: they are not public, and the routes to them are ones I would rather not build on.

Next

The next piece takes the workflow that knows what a utility already owns — which equipment, installed when, and whose contract is coming up for renewal.