Field Notes · Series 01: The Gap · Part 2 of 5

A platform nobody fills is an expense.

How a well-built system becomes shelfware, and whose job it was to prevent it.

Huk Innovation Group

The day a system ships is the day everyone involved treats as the finish line. The final invoice clears. The training session happens. Somebody takes a screenshot of the dashboard for the board deck. The vendor's team rolls off to the next engagement, and for about six weeks the thing genuinely gets used, because it is new and because someone is watching.

Then the quarter turns. Two of the five people trained have changed roles. The workflow the software assumed turns out to have three exceptions nobody surfaced during discovery, and the exceptions get handled the old way, in a spreadsheet, beside the new system rather than inside it. Usage does not collapse. It erodes, which is worse, because erosion does not trigger anything. Nobody files a ticket to report that a platform is slowly becoming furniture.

A system is not an asset until it is full

Accounting will call the platform capital. Reality is stricter. A system is a container, and a container is worth what is in it: the orders moving through it, the customers living in it, the daily traffic it was designed to carry. Empty, it is not neutral. It is a monthly bill, a security surface, a training obligation, and a standing reminder that the last big initiative did not land. An unfilled platform is not a wash. It is an expense with a story attached.

Which is why shelfware is not really a software problem. Nothing in the build was wrong. The requirements were met, the tests passed, the documentation is good. What is missing sits on the far side of the delivery date, and it was never anybody's line item.

The three ways it empties

The first is no demand behind it. A booking system with nobody booking. An ordering portal with no order volume routed into it. The software works exactly as specified. The pipeline meant to feed it was a different firm's contract, or no one's.

The second is no behavior change around it. The system encodes a process the company never actually adopted. Staff keep the old habit because the old habit still works and nobody is measured on which path they take. Two systems now run in parallel, and the real one is whichever people trust at four in the afternoon.

The third is nobody accountable for utilization. Someone owns uptime. Someone owns the renewal date. No one owns the question of whether the thing is carrying the volume that justified buying it, and questions without owners get answered late, usually by an invoice.

Nobody is ever assigned the job of making sure the system gets full. So the system does not get full.

Whose job it was

Ask directly, after the fact, and every answer is reasonable. The vendor scoped a build and delivered a build. Adoption was not in it, and pricing it in would have meant staying a year with no mechanism to be paid for staying. The agency was pointed at lead volume, not at whether those leads landed inside the new system rather than in somebody's inbox. The internal champion had a day job. The executive who approved it moved on the moment it went live, which is what approving something means in most companies.

Each of those is a defensible position. Together they add up to a platform running at a fraction of its purpose. Accountability follows scope, and utilization sat outside every scope on the table. That is the structure the first essay described, seen from the technology side.

What filling actually requires

Three things, and none of them are software.

Demand aimed at the system, not near it. A campaign that fills a booking platform has to be built to route into that platform and measured on bookings created rather than clicks delivered. That is a growth decision made in service of a technology asset, which is precisely the decision nobody is positioned to make when growth and technology are two separate vendors with two separate contracts.

The process written down before it is automated. Software encodes a process. If the real process lives in the heads of the two people who are good at it, exceptions included, then what gets encoded is a guess, and the guess is what staff route around. Writing it down first is unglamorous, and it is most of the work.

A utilization number with a name on it. Not a dashboard nobody opens. One figure, agreed at purchase, reviewed on a cadence, owned by a person: the volume this system has to carry to be worth what it cost. When that number is visible and owned, erosion stops being invisible.

None of the three are things a build contract naturally contains, which is why they have to belong to someone whose scope spans both sides of the gap. The next essay turns the picture around and takes the growth side: what happens when the demand is real, the campaigns work, and the operation receiving them quietly drops what arrives.

This argument, in production

We built for this argument before we wrote it down. Two of the systems in our workshop exist because a platform that nobody fills is a bill:

  • The Huk Blueprint PlatformWriting the operation down before anything automates it: score the business, close the gaps, draft the playbooks, and prove unit economics a stranger could run.
  • The Huk ScoreboardUtilization with a name on it: one committed number, its baseline, its target, and every move made against it.

We build these and we run our own operation on them. That is the same test we would want you to hold us to.

Tell us what is not getting used If you are paying for a system running at a fraction of what it was bought for, that is worth a conversation before the renewal. Or keep reading: the Field Notes library