The delta is the document
Something happens at a water utility every week: a contract is awarded, a solicitation goes out, an engineering director retires, a budget line moves, a consent order lands, a bond passes. This is the report that tells a territory manager what happened at every target account in the past week, with the source, what it means for what they sell, and the follow-up already attached. It is also about why the work is separating the movement that matters from the movement that does not.
Something happens at a water utility every week. A board meets and awards a contract. A request for proposals goes out. An engineering director retires, or a new one is appointed. A budget amendment moves a project up a year, or off the capital plan altogether. A consent order lands, or a permit comes up for renewal. A bond issue or a state loan is approved, and a project that was talk for three years is suddenly funded. A milestone on a plant upgrade slips. An operations manager tells the board, for the third meeting running, that the same station keeps failing.
All of that is public, and each item changes what a vendor should do next at that account. It is also scattered across agendas, minutes, budget books, procurement portals and regulatory filings, at forty or four hundred utilities, and nobody on a sales team has the hours to read all of it.
So the report in this piece does one plain thing. For every utility you care about, it tells you what happened there since you last looked: the awards, solicitations, personnel changes, budget and capital-plan moves, regulatory actions, funding decisions and project milestones we found, each with the document it came from, what it means for what you sell, and the follow-up it produced. It is how a territory manager stays on top of target customers without relying on what a rep happens to remember, and of everything we build it is the thing customers typically subscribe to.
I believe the hard part is not collecting the movement. It is deciding which of it matters, reading it against what the reader sells, and attaching the action before anyone has to ask. The rest of this piece walks through how we do that.
The job, as it exists today
Somebody manages a team of people who each own a set of accounts. They do not work the accounts themselves. Their job is to know, across all of them, what changed: which situations moved, which went quiet, which need a person on a plane, and which of the things they were told last month turned out to be nothing. Then they have to be able to say that upward, in a sentence, on a Monday.
Today they do this by asking. There is a weekly call, a pipeline review, a round of any updates on your accounts?, and what comes back is what each rep happens to remember, weighted toward whatever they touched most recently. An account nobody called in six weeks gets reported as quiet. In a meeting that sounds the same as nothing happened there, but it only means nobody looked.
A scheduled report is for that gap, between an account being quiet and nobody having looked.
Why most of these fail
They go to everyone, so they are written for no one. A single digest sent to the whole commercial organization has to include everything that might matter to anybody. So it gets long, then it gets skimmed, and within a month people stop reading it. The problem is that there is no specific reader.
They publish a fixed quantity rather than what moved. A newsletter goes out because it is Thursday, at roughly the length it was last Thursday. The bodies it watches keep no such schedule. Utility boards meet monthly, and in any given week most of them have done nothing at all. A report committed to a constant length has to fill the weeks between meetings with something, and once you have padded it twice, your reader has learned that the contents do not matter much.
And they report the current state instead of what changed. Most dashboards and most reports describe the state: here are your accounts, here are their attributes, here is the pipeline. Somebody who saw it last month does not need that again. They need the delta, which is a much smaller document and a much more useful one.
What the workflow does
There are five parts to it.
First, it runs on the utility's cadence. Boards meet monthly, budgets are annual, rate cases run to their own clock, and no single account produces something every week. But a territory manager owns forty accounts, each on its own clock, and across forty of them something moved this week. So the report goes out weekly and its length changes: some weeks it carries five accounts, some weeks one. What stays fixed is the threshold for what gets in. A report that is allowed to be short is one the reader can trust when it is long. This is the same principle as the monitoring layer, which runs when the utility publishes rather than when we feel like looking.
Second, it is written to a role. A territory manager, an executive and a rep each need something different. The rep already had their version, as a task in the system they work in, which is the write-back workflow. The manager's version is the same facts arranged as a picture of a territory. The executive's is shorter still and mostly about where the money and the risk are.
Third, it reports change and ranks it by consequence. It includes only the things that moved something: a budget line appearing, a person leaving, a contract entering its final year. It also includes an opportunity we flagged three months ago that somebody else has quietly resolved. That is bad news, and it belongs in the report because nobody would volunteer it on a call.
Fourth, every item carries its source and its action. Each line links to the document it came from and to the task that already exists because of it. So each line can be checked and has already been acted on, and the reader is not being asked to go and do something. That is what keeps it from being an alert.
Fifth, it accounts for every account, not only the ones where something happened. Something is always moving somewhere across forty utilities. So the report names what was read at every account and what it came to, which is how you tell nothing here rose to consequence from nobody looked. That accountability is what the report is really for, and I come back to it below.
So that is the workflow: the utility's cadence, one role per version, change ranked by consequence, source and action on every line, and nothing left unaccounted for.
Reports / Weekly account report / Southeast territory
What it looks like in practice
This is an illustrative example. It is not a customer, and not a real utility.
A territory has forty accounts, and over a week there is movement at a dozen of them: meetings held, agendas posted, budgets amended, people moving. Three of those movements have consequences for you. One utility appoints a consultant for a study in your area, one loses the engineering director who was your route in, and one publishes a capital plan that no longer contains a project it contained last year.
The report is those three, in that order. Each is a short paragraph with the document attached, what it means for this account given what you sell, and the follow-up already sitting on somebody's list. Below them, the other thirty-seven are accounted for: what was read, and why none of it changed the picture.
A report that promoted all forty into findings would be worse in every way.
An alert with a longer fuse
I have argued, about nearly everything we build, that a stream of notifications mostly gets ignored. So the obvious objection is that a scheduled report is an alert with a longer fuse: having refused to build an inbox, we built a slower one.
I think the objection is right about the form and wrong about the reader. This matters, because if I am wrong about it then this workflow should not exist.
An alert interrupts the person who has to act. To act on it they have to leave the message and go somewhere else, so alerts pile up unactioned, and the better the system gets the faster the pile grows.
A report informs somebody who is not going to act on the individual items at all. The manager is not going to chase the consultant appointment. The rep is, and the rep already has a task for it. What the manager needs is the shape of the territory: enough to decide where attention goes, ask a better question on the Monday call, and notice that one region has gone quiet in a way that is about the region rather than the utilities in it.
So the report is a byproduct of work that has already been delivered somewhere else, and that is why it can be a document rather than a queue. It is also the test I use. If your reader has to act on the report itself, you have built an inbox.
What it cannot do
It will not promote movement into consequence. Something is always happening at a utility. Meetings are held, agendas are posted, line items move, people change jobs. There is always enough to report, so the discipline is in declining to report most of it, which is the same rule the build log on this site follows: you do not pad.
The pressure to inflate is large, and it is commercial. A report listing ten developments looks like a product earning its keep. A report saying three of these matter, and here is what was read to establish that looks thinner to a certain kind of buyer. The temptation is to lower the bar for what counts as consequential until the number looks healthy.
Do that twice and the reader stops trusting it for good, because the whole value of the report is that an item appearing in it is worth their attention. Padding breaks the ranking, and the ranking is what they are paying for.
That is why the accounting behind the three is worth as much as the three. In a pipeline review, nothing at that utility rose to consequence and nobody looked sound the same until somebody is reading everything, every week.
And it reports; it does not manage. It will tell a manager that an account moved and that a task was created. It will not tell them whether the rep did anything about it, whether the conversation went well, or whether the relationship is in trouble. None of that is in the public record, and all of it matters more than what is. The report is one input to a judgment that stays with a person.
Related
- Nobody reads the minutes: where the developments in the report come from, and why nobody reads them by hand.
- Nobody logs in to your dashboard: the rep's version of the same facts, as tasks in the system they already use.