Everything you sold has a clock on it
Every pump, meter and membrane a vendor has ever installed will be replaced on a schedule that is roughly knowable, and almost nobody acts on it, because the information sits in their own systems in a form nobody reads. This is the workflow that turns an installed base into a calendar, and the contract cycle that decides whether you can do anything about it.
A vendor selling equipment into water utilities is sitting on a forecast of its own future revenue and mostly cannot read it.
Every pump, blower, meter, valve and membrane that company has installed over thirty years is still out there, aging on a schedule that is roughly knowable. Each one will be replaced. Some of those replacements are three years away and some are next spring. The company knows what it sold, when, and to whom, because it invoiced for all of it.
Then nothing happens. As one customer put it about their own installed base: they knew the equipment would be replaced, they knew roughly when, and they were really not acting on it.
The job, as it exists today
It has two halves, and only one of them is about your own kit.
The first half is your installed base: what you sold, where it is, how old it is, and therefore when the conversation about replacing it should start. That is well before the utility writes a specification, because by then it is a bid you are one of several answering.
The second half is everybody else's. Which competitor's equipment sits in the stations you did not win, who holds the maintenance contract on it, and when that contract comes up for renewal, because until it does you cannot displace anyone no matter how good your case is.
Most vendors have a rough sense of the first and almost none of the second.
Why nobody does it
The data is theirs and it is unusable. This is the part I found surprising. In the first two workflows the difficulty was that the information sat outside the company, in documents nobody reads. Here it sits inside the company (in an ERP, a CRM, a warranty database, thirty years of invoices) and is just as unread. My own description of it at the time was that the data is sitting in silos, or in no usable format, and nobody is mining it.
Nobody is mining it because mining it is a project. Someone has to reconcile serial numbers against installations, work out which of those sites still exists under that name, apply a service life per product line, and then keep the whole thing current. That is a quarter of work for an analyst nobody has hired, to produce a list that is stale a month later.
The second half is hidden. Your competitor's installed base is not in your invoices. It is scattered through award records, board approvals, bid tabulations and maintenance discussions in the public documents. You can see it in principle and cannot read it in practice, which is the same problem the monitoring workflow exists to solve.
What the workflow does
First, take in what the vendor already knows. Either they send the data (a dump in whatever shape it happens to exist, and it is never a tidy shape) or we integrate with the CRM or ERP it lives in and read it directly. Neither route is more legitimate than the other, and most companies start with the first, because sending a file requires nobody's permission and an integration does.
Second, put a service life against each line. That number comes from the vendor, not from us. They know what their equipment lasts, by product line and often by duty. An engineering organization has usually held that for decades, even where the commercial side has never used it. Our job is to map it onto the installed base rather than to invent it, and that matters: a replacement schedule built on a manufacturer's own engineering judgment can be argued with a customer in a way that one we modeled could not.
Third, read the utility's replacement behavior. This is where the public record comes back in, and it is what stops the calendar being naive. Two utilities with identical equipment of identical age behave completely differently: one cycles its stations on a systematic program, the other runs them until something fails on a Sunday. The minutes tell you which kind you are dealing with: whether there is a rehabilitation program with a cadence, whether the same asset has been complained about at three consecutive meetings, whether they hold spares or scramble.
A twelve-year-old pump in a utility that replaces on schedule is a date. The same pump in a run-to-failure utility means a phone call after the failure, and you only get that call if you are the name they already have.
Fourth, map the competitor's base and its contracts. Who supplied the equipment you did not, who maintains it, and when that arrangement expires. The expiry date is the piece most of the rest depends on.
Last, emit a dated action. The output is an account, a specific reason it is live now, and the window in which someone can do something about it, rather than a spreadsheet of aging assets.
Installed base / Southeast territory / Replacement calendar
Raw-water pumps ×4
Lift stations ×7
Filter valves
Blowers ×3
Booster pumps ×2
The alert everyone asks for, and the one that matters
The obvious output is the end-of-life nudge: tell me twelve to eighteen months before this equipment is due, so I can be in the conversation before the specification is written. Customers asked for that feature by name, more than once, and it is useful.
On its own, though, it produces a salesperson arriving at a utility that cannot buy from them yet, because somebody else has a standing contract with two years to run.
That is the second clock, and in this market it governs. A maintenance or supply agreement typically runs four or five years. Until it expires the incumbent keeps the work more or less regardless of merit. So the useful question is when the equipment date and the contract date line up, and what you do in the years between, more than when the equipment needs replacing.
We can read that clock, and it is one of the more satisfying things the public record gives you. Service and operations contracts are awarded in public and renewed in public: the award appears in the minutes, the term is usually stated, the extensions are voted on. So who holds the work at a given utility, and the window in which it next comes up, is recoverable. Two separate customers asked for this in almost the same words, one wanting to know who holds each outsourced operations contract and when it ends, the other wanting to time a displacement to an incumbent's renewal date.
The clock you do not own
There is a harder version of this, and it is the thing that made me take the whole workflow seriously.
A manufacturer went looking at a utility where a great deal of its own equipment was installed (machines it had built, sold and delivered) and found that the maintenance on those machines, and the spare parts, had been going to a competitor for years.
So you can be the incumbent on the hardware and not the incumbent on the revenue that follows it. The equipment is yours, the relationship is somebody else's, and nothing in your own systems tells you, because your systems record what you sold and have no view of what happened next. The competitor did not beat you to a sale. They turned up afterwards, in a market where the purchase is one event and the servicing is twenty years of them.
This is the second clock again. The question is who owns the relationship around the equipment between now and its replacement, and that is answerable from the public record, because service contracts are awarded in public and renewed in public even when the original sale was not.
There is an answer to the years in between, and it came from a customer rather than from us. While a standing contract is running, you can often still get in underneath it as a subcontractor to whoever holds it. It is not the whole prize, but it is presence in a plant you would otherwise not enter for two years, at the exact moment the next cycle is being planned.
What it cannot do
This is where the monitoring boundary returns, and it bites hardest here.
Make, model and serial number are not published. For your own equipment that does not matter, because you have the records. For a competitor's, it means the picture is assembled from award records and discussion rather than from an asset register. You can often establish who supplied a station and roughly when, and you frequently cannot establish exactly what is in it.
So the competitor half of this workflow is coarser than the half built on your own data, and any product claiming otherwise is guessing.
We treat asset-level detail on a competitor's equipment as out of scope. Where it happens to surface in the utility's own documents (a model named in a maintenance discussion, a make listed in a bid tabulation), we will take it, because it is public. We will not go looking for it by other means, and I would not sell a plan that depends on having it.
AquaIntel does this by putting your own service lives against your installed base, reading each utility's replacement behavior and contract terms from its public record, and turning the result into a dated list of accounts to act on.
Related
- The bid you already knew about, catching the solicitation an expiring contract eventually produces.
- Nobody reads the minutes, the public record the award history is read from.