The delta is the document

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.

Every one of those is public, and every one of them changes what a vendor should do next at that account. They are 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 this piece is about does one plain thing. For every utility you care about, here is 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.

The work in it is not collecting the movement. It is deciding which of it matters, reading it against what the reader actually sells, and attaching the action before anyone has to ask. That is the whole article.

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 to be able to say that upward, in a sentence, on a Monday.

The way this is done today is that they ask. A weekly call, a pipeline review, a round of any updates on your accounts? — and what comes back is a summary of what each rep happens to remember, weighted heavily toward whatever they touched most recently. Accounts nobody called in six weeks report as quiet, which is indistinguishable in a meeting from nothing happened there, and is not the same thing at all.

That gap — between an account being quiet and nobody having looked — is what a scheduled report is actually for.

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, which makes it long, which makes it skimmed, which makes it decorative within a month. The failure is not the volume of information. It is the absence of a 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 spends the difference on the gap between meetings, and once you have padded that twice, your reader has learned that the contents are not load-bearing.

And they report existence rather than change. Most dashboards and most reports describe the current state: here are your accounts, here are their attributes, here is the pipeline. But somebody who saw it last month does not need the state. They need the delta, and the delta is a much smaller and much more interesting document.

What the workflow does

It runs on the utility's cadence, not ours. 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 does not own one account, they own forty, each on its own clock — and across forty of them, something moved this week. So the report goes weekly and its length does not: some weeks it carries five accounts, some weeks one. What holds constant is the threshold, not the volume, and a report allowed to be short is the only kind that can afford to mean something when it is long. This is the same principle as the monitoring layer, which returns when the utility publishes rather than when we feel like looking.

It is written to a role. What a territory manager needs is not what an executive needs, and neither is what the rep needs — 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 underlying facts arranged as a picture of a territory. The executive's is shorter still and mostly about where the money and the risk are.

It reports change, and it ranks by consequence. Not everything that happened — the things that moved something. A budget line appearing. A person leaving. A contract entering its final year. An opportunity we flagged three months ago being quietly resolved by somebody else, which is bad news and belongs in the report precisely because nobody would volunteer it on a call.

Every item carries its source and its action. The link to the document it came from, and the task that already exists because of it. A report where each line is checkable and already acted on is a different object from a report that asks the reader to go and do something about it — and this is the distinction that keeps it from being an alert.

And it accounts for all of them, not only the interesting ones. 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 what separates nothing here rose to consequence from nobody looked. That is the accountability the document is actually selling, and I will come back to it.

What it looks like in practice

An illustrative example — 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 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. Behind them, the other thirty-seven are accounted for: what was read, and why none of it changed the picture.

The version of that report which would be worse in every way is the one that promotes all forty into findings.

Isn't this just an alert with a longer fuse?

I have argued, about nearly everything we build, that a stream of notifications is a very sophisticated way of being 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.

That objection is right about the form and wrong about the reader, and the distinction is worth being precise about, because if I am wrong about it then this workflow should not exist.

An alert interrupts the person who has to act. Its failure is that acting requires leaving the message and going somewhere else, so it accumulates 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 allocate attention, 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 not the delivery mechanism for the work. It is a byproduct of work that has already been delivered somewhere else. That is why it can be a document rather than a queue, and it is also the test: if your reader has to act on the report itself, you have built an inbox, and every inbox ends the same way: unread.

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. So the difficulty is never finding enough to report. It is declining to report most of it, which is the same discipline the build log on this site runs under: you do not pad.

The pressure to inflate is enormous and entirely 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 document is worthless permanently, because its whole value rests on the reader believing that an item appearing in it is an item worth their attention. Padding does not merely add noise; it destroys the ranking, and the ranking is the product.

Which is why the accounting behind the three is worth as much as the three. It is the difference between nothing at that utility rose to consequence and nobody looked, and those remain the same sentence in a pipeline review 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 which is in the public record, all of which matters more than what is. The report is one input to a judgment that remains entirely a person's.

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.