Internal tools survive when they live inside a workflow that already exists: the inbox, the Monday doc, the support queue. They die when they ask the team to adopt a new one. Placement beats features, and it isn't close. The graveyard of internal tools is full of clever software nobody opened twice, and almost none of it died for technical reasons.
The placement rule
Consider two versions of the same quoting assistant. Version one is a new web app with its own login; it demos brilliantly, gets bookmarked by three people, and is forgotten by week four, because using it requires remembering it exists at the exact moment of need. Version two lives inside the inbox where quotes already get written, drafting a reply the moment a quote request arrives. Nobody adopts version two. It's simply there, inside a behaviour the team already has. Same model, same logic, opposite outcomes, and the only difference is placement.
Adoption is a placement problem long before it is a UX problem.
Five shapes that keep working
The answer tool pulls from your own documents and answers questions in the chat channel the team already uses. Its real product is uninterrupted senior people: every question it answers is a shoulder not tapped. Its failure mode is stale sources, so it needs one owner who keeps the documents current, a smaller job than it sounds.
The drafter produces the first version of a repetitive document (proposals, job ads, follow-up emails) and a human finishes it. The target is seventy percent done, with the expert's judgement spent on the thirty percent that matters. Teams that aim it at a hundred percent stall; teams that treat the human finish as a permanent feature ship in weeks and keep shipping.
The watcher monitors a source (competitor sites, review platforms, an industry board) and posts a summary where the team already talks. The router reads incoming requests and files them to the right owner, which sounds trivial and quietly removes the daily triage argument from a shared inbox. The checker reviews outbound work against a checklist before it ships: quotes against the pricing rules, articles against the style guide, artwork specs against the printer's requirements. Every business we meet has at least three of these five waiting to be built.
Why tools die
Three causes cover most of the graveyard. The tool launched beside the workflow instead of inside it, so using it required a habit change nobody signed up for. The features were demo-driven, chosen for what impresses in a meeting rather than what the Tuesday version of the task needs. Or nobody owned it after launch, so the first stale answer or broken integration went unfixed and trust never recovered. Note that "the model wasn't good enough" doesn't make the list. Capability is rarely the binding constraint on internal tools; care is.
How to pick your first one
Find the task someone does weekly with mild resentment, where the input and output are both text, and where a wrong answer is cheap to catch. That's your first build. Ship it in weeks, put it where the work already happens, give it an owner, and resist the temptation to add features before it has users. The scoreboard is simple: is it being opened in week four without anyone prompting, and has someone asked for the second tool? If both are yes, you've built the muscle. If either is no, fix placement before you fix anything else. And if you're weighing what to build first, your first build shouldn't be a chatbot.
The compounding part
The first tool that sticks changes the conversation. The team stops asking whether AI is useful and starts pointing at the next resented task, which is a far better project pipeline than any workshop produces. Follow the requests, keep each build small enough to ship in weeks, and within a year the tools are load-bearing: not a transformation programme, just a business where the repetitive work quietly stopped being done by hand.
