Internal Tools That People Actually Use

A tool gets built. It gets rolled out in a meeting, with a walkthrough and a link. For a few weeks people use it. Then a spreadsheet reappears, someone starts keeping notes in a document again, and within a few months the tool is open in nobody's tabs.

Nothing broke. The build was fine. It failed at adoption, which is where most internal tools fail, and adoption is decided by things that have very little to do with how well the thing was made.

What the spreadsheet was actually asking for

A real estate brokerage we work with had a shared spreadsheet for listings that had not hit the market yet. On paper it was their edge: know about a property before it is public and you can put the right buyer in front of it first.

In practice, agents stopped trusting it, then stopped using it. The usual explanation is discipline. People are busy, data entry is boring, someone needs to enforce the process. That explanation is wrong often enough to be worth distrusting.

Look at what the spreadsheet asked of an agent, and what it gave back. It asked for a dozen fields, typed correctly, about a property they already knew. It gave back a row. To actually understand the listing, the agent still had to open the MLS for the details, Zillow for the price history, and a map for the neighbourhood. The spreadsheet took work and returned almost nothing. Its value only arrived later, in theory, for somebody else.

That is not a discipline problem. It is an exchange rate, and it was terrible.

The exchange rate at the moment of entry

Here is the claim, and it is narrower than the usual advice about listening to your users. Adoption is decided at the moment of data entry, by what the tool gives back in that moment. Not later, not in aggregate, not in the report someone else reads on Friday.

Most internal tools fail this test in the same way. They are designed as places where information is stored so that a process can happen elsewhere. To the person typing, that is pure cost. Every second spent on the form is a second not spent on the work, and the payoff is somebody else's.

The tools people reach for pay them immediately. You enter an address and the system hands back the price history, the comparable sales, the census profile, the parcel record, the photographs. The entry is no longer a tax on the way to the value. It is the fastest way to get it.

That was the fix for the brokerage. Same data, same team, same discipline. The structured fields stayed, because consistent data is what makes anything else possible. What changed is that filling them in now returns a complete picture of the listing in one place, so going to the tool first became the quickest way to answer the question the agent already had.

How to tell which one you are building

Ask a specific question about the tool you have or the one you are about to commission: what does the person filling this in get, before they click save?

If the honest answer is a confirmation message, you are building a tool people will tolerate until they do not. Some things that count as a real answer:

• Information they would otherwise have gone to fetch, assembled for them
• A calculation they were doing by hand
• Visibility of something that was previously invisible, like where a request actually is
• Removal of a step, rather than the addition of one

None of those are dramatic. Adopted internal tools tend to feel almost boring, because they quietly remove annoyances that had become background noise.

Start rough, because the exchange rate is hard to guess

You will not get the exchange rate right from a requirements document. What people say they need and what actually saves them thirty seconds at the wrong moment are different things.

So build the smallest version that pays someone back for using it, put it in front of them, and watch. Polished tools that miss are harder to correct than rough ones that are directionally right, because when something looks finished people stop telling you where it does not fit. They adapt to it, quietly, and then they leave.

Keep the feedback loop short enough that people see their input show up. That is the second half of adoption: a tool the team shaped is theirs, and a tool delivered to them is management's.

Before any of this, check that you need one

All of the above assumes the decision to build was made well. Often it was not, and no amount of careful rollout rescues a tool that should not exist. What's Actually Worth Automating deals with that question directly, and the honest answer is frequently that something smaller will do.

The quieter version of success

Good internal tools rarely generate excitement. The measure is not praise, it is whether anyone would notice if the tool disappeared. If removing it would send people back to copying data between systems or chasing information that used to be at hand, it is doing its job.

The brokerage spreadsheet passed that test in reverse. It disappeared in practice long before anyone admitted it, and the work carried on around it. That is worth watching for, because a tool nobody mentions is either working quietly or already gone, and those two look identical from a distance. The full story of that rebuild, and the platform it became, is in the case study.