Anyone can write the email
Any model can write a good outbound email in four seconds, which is exactly why outbound stopped working. The scarce thing is having something true and specific to say, and the most useful output this workflow produces is the one that tells you there is nothing worth sending.
I believe writing a good cold email has stopped being a skill that sets anyone apart. Any competent model will produce one in four seconds: correctly structured, brief, with a plausible reason for the contact and a clear ask. It will be better written than most of what a sales team sends today.
That is why outbound stopped working. When a well-written email costs nothing to produce, it stops telling the recipient anything, and the recipient adjusts. The question they ask moves from is this written well to does this person know something about me. A language model cannot answer that second question on its own.
So the drafting is the easy part, and it is the part everybody has automated. The hard part comes before it, and that is everything else we build.
The job, as it exists today
A salesperson has a list of accounts and a number to hit. The list is too long to research properly and too short to ignore anyone on it, so they do one of two things.
They write personal notes to the handful of accounts they already know, which works and does not scale. Or they send a template with the utility's name merged into the first line, which scales and does not work. They know it does not work, and they send it anyway, because the alternative is sending nothing, and sending nothing looks like not trying.
The industry's answer has been tooling that makes the second option faster: more sequences, more steps, more variants tested against each other. That raises volume against a falling response rate, which is the same trade the previous decade already made and lost.
Why it is harder here than in most markets
A utility is a public body, and it remembers you. The buyer here is a small, stable, professional community. The operations manager you emailed badly in March is at the same conference in October, talking to the peers you also emailed badly. There is no endless supply of fresh prospects. The market is finite and it talks to itself.
That changes the math behind spray-and-pray. A bad email costs you something. It is a small, permanent deduction from a reputation you need for years, in a market where the number of relevant buyers is smaller than most vendors' contact lists suggest.
And the specifics that make an email land are not in any sales tool. Job titles, firmographics and funding rounds are. What makes a utility person read past the first line is the plant, the project, the committee meeting, the thing they said in public and assumed nobody outside the room heard. That is the reading problem again, this time at the last step of the process rather than the first.
What the workflow does
It works in five steps.
First, it drafts from the account record. The inputs are what the other workflows produced: the signals, the verified contact, the installed base and its clock, the profile. The draft depends on all of them, which is why it comes after all of them.
Second, it writes to the person. The same development at the same utility is a different message to a plant superintendent, a finance director and a consulting engineer, because they worry about different things and are measured on different things. One development gets several drafts.
Third, it produces the form the sale needs. A full email for a cold approach. A three-line version for someone who has met you. A short note for social. A call script for people who would rather pick up the phone, with the two or three objections this account is likely to raise and what is true about each.
Fourth, every claim in the draft traces to a document. That is the rule everywhere in the product. If the email says a capital plan carries a line for something, that line exists, and you can open the page it is on before you press send. It matters most here, because this is the one workflow whose output leaves the building with your name on it.
Fifth, a person approves it. Drafts are written to be edited and are gated on a human before anything is sent. The reason is that the rep knows things the record does not, and the edit they make is usually why the email works.
So that is the workflow: draft from the record, write to the person, fit the format, source every claim, and have a person sign off.
Outbound / Cedar Hollow Water Authority / Draft
What it looks like in practice
This is an illustrative example. It is not a customer, and not a real utility.
You have received the generic version of this email a hundred times. I noticed your utility is investing in infrastructure modernization. Our solutions help utilities like yours reduce costs and improve resilience. Do you have fifteen minutes on Thursday?
The grounded version says: your board approved a condition assessment of the north pump station in March, the report went back to the board in August with a rehabilitation recommendation, and the capital plan now carries a line for it in the next fiscal year. We have done this work at utilities of your size. Before the specification is written, here are two things worth deciding early, and here is why one of them is usually decided wrong.
The second one is not better because the writing is better. The writing is about the same. It is better because it shows that somebody did the reading, and that is the one thing in the message the recipient cannot get from anyone else that week.
The thing we will not build
We do not send it.
We have drawn this kind of line before, on the CRM and on the bid feed, and by now it is a deliberate position. We do not build the sending infrastructure: the sequencer, the mailbox warm-up, the deliverability management, the unsubscribe handling, the domain reputation.
Those are real disciplines, and there are companies that do nothing else and do it well. A vendor with a working sales team already owns one. Replacing it would mean a migration, a procurement cycle and an argument with whoever chose it, in exchange for a worse version of something that already works.
The context is the part nobody else has, so that is the part we build, and the draft lands in the tool the team already opens every morning.
There is a commercial argument for doing the opposite, because sending is where the recurring revenue and the lock-in are. It is the same argument that would have had us rebuild the CRM, and it is wrong for the same reason. I would rather we be the part of the workflow that is hard to replace than the part that is easiest to swap out.
What it cannot do
It cannot manufacture a reason to call. The draft is built from what the record supports. Where the record is thin (no project forming, no contract coming up, no committee discussion worth quoting), the workflow says so and says what it looked at, rather than reaching for the strongest available filler and calling it an angle.
We treat that as quality control. A system that always produces an email will, some of the time, produce the generic one with better vocabulary. Do that at a volume no human could manage, in a market this small, and you have automated the thing that stopped working.
So the useful output is sometimes not yet, and here is what to watch for. That is a different instruction from nothing here, and much more useful than a paragraph of polite filler sent under your own name.
And it does not know what happened in the room. The rep who visited in February, the procurement officer who is difficult, the consultant who has a history with your equipment: none of that is in the public record, and all of it changes what should be written. The draft is a first draft, assembled from what can be known at a distance, and the person sending it should treat it that way.
Related
- One utility, all the way down: the profile a grounded draft is downstream of.
- There is no decision-maker: the verified contact the draft is addressed to.