Rolling It Out Inside a Company

A working system that nobody uses is the most common outcome of an AI project, and it is almost never a technical failure. It is a failure to notice that you are changing how people work, and that people did not ask you to.

One number matters more than any other at launch: how many people are still using it thirty days later. Not how the demo went, not how the launch email landed. Everything below is aimed at that number.

Pick a boring first project on purpose

The first thing you ship sets the terms for everything after it. It should be chosen for how safely it can fail, not for how impressive it is.

That means: one team, a task they already resent, a wrong answer that is obvious and cheap, and a person who was going to check the output anyway. If it works, you have a reference inside the company, which is worth more than any vendor case study. If it fails, it fails in a corner, and you learn what your organization actually gets wrong.

Ship it as a draft, not a decision

Almost every first version should produce something a person reviews and sends, rather than something that goes out on its own. This is not timidity. It buys three things at once. Exposure stays near zero. The review queue generates your eval data for free. And the people whose work is affected keep a hand on the wheel while they are deciding how they feel about it.

You can move to automatic later, for the narrow slice where the override rate has been near zero for a month. That is a decision made from evidence rather than optimism, and it is a much easier one to defend.

The conversation nobody wants to have

Automate part of someone's job without talking to them about what it means, and they will work out the implication on their own. Their version will be worse than the truth. They will also be the one who could have told you about the exception that breaks your system, and they will not.

Have the conversation early and be specific rather than reassuring. What this takes off their plate, what it does not touch, what happens to the time, and who decides. If you cannot answer honestly, that is worth knowing before you build, because it will surface anyway in a less controlled form.

The reliable pattern in my experience: the people closest to the work are the least threatened by automating the tedious parts, provided they were asked. It is being surprised by it that produces resistance, not the automation itself.

Name an owner or it will rot

Every system needs one named person who notices when it breaks, decides whether a change is worth making, and can turn it off. Not a committee. Not the consultant who built it.

An unowned system does not fail loudly. It drifts. A vendor changes a format. The output degrades slightly. People start correcting it by hand. Six months later everyone is back to the old way, while the system still runs and still costs money. Nobody reports this, because nobody owns it.

Ownership is a small commitment if you scope it honestly: watch four numbers, respond when they move, review it quarterly. Write it down next to the system's entry in the register.

Expand by pull, not push

Once one team has something that works, the temptation is a company-wide rollout with training sessions. Resist it. Mandated tools get used the way mandated tools always get used.

Instead, make the first result visible and let the second team ask. Show the numbers in whatever forum already exists, including the disappointing ones. Then help whoever asks next, and make helping them cheap by reusing what you built.

This is slower for the first two projects and much faster by the fifth. A team that pulled the tool toward itself already wants it to work. Adoption is not a communications problem. It is a demand problem, and demand comes from a colleague saying it saved them Thursday afternoon.