What makes an internal tool people actually adopt

Internal tools have a uniquely hard adoption problem: unlike a consumer product, users often didn't choose to use it, aren't paying for it, and can usually find a workaround. If the tool is even slightly harder than the old way, people will quietly revert — and no amount of internal mandate fully prevents that.

It has to be faster than the workaround, not just more correct

'More correct' rarely wins on its own. If the new tool takes longer than the spreadsheet or the shared inbox it's replacing, people will use it only when someone is watching. Adoption depends on the tool being genuinely quicker for the most common task, even if that means initially supporting fewer edge cases.

It has to fit how the role actually works

Internal tools are too often designed around an idealised process rather than how the work actually happens. Time spent watching the real workflow — including the messy parts — usually reveals what the interface actually needs to support.

Common adoption killers

• Requiring data entry that duplicates something already recorded elsewhere
• Adding approval steps without removing an equivalent amount of manual work
• Launching without training or a clear 'why this matters' explanation
• Ignoring frontline feedback after launch because the build phase is 'done'

Treat launch as the start, not the finish

The tools that get adopted are rarely perfect on day one. They're the ones where feedback in the first few weeks is taken seriously and acted on quickly, so early friction gets resolved before it hardens into 'this tool doesn't work for us' — a reputation that's very hard to undo later.

Ultimately, adoption is a product problem, not a training problem. If people revert to the old way despite training, the tool — not the team — usually needs to change.