Building the AI Assistant Took Weeks. Getting People to Use It Took Months.

The build took weeks. Then adoption stalled.

That gap, between a tool that works and a tool people use, is where many internal AI projects get stuck. Here is what closed it for me.

The problem nobody owned

In my current role I lead product for a customer identity platform. Teams across more than 200 product lines build on it: developers, product managers, customer care and delivery. They all had the same questions. How do I set up single sign-on for this client? Which API do I call? Why is this configuration failing?

My team answered those questions, one ticket at a time, every week. It was a steady drag on the people who should have been building the platform. It was also nobody’s job to fix. It was not mine either. I run identity, not AI.

The waste was visible and unowned, so I built a retrieval-based assistant grounded in our platform documentation, so teams could answer their own integration, configuration and how-to questions.

Why shipping it was not enough

People already had a way to get answers. They asked a person. It was slow, but it worked, and it came with a track record. My assistant was an unfamiliar tool with no history, asking them to change a habit.

I had shipped a tool. That is different from launching a product. A launch has onboarding, a feedback loop and someone responsible for whether it gets used. A tool that has only shipped has a link.

What moved adoption

I sat with teams to see where they got stuck. Not a survey. Watching people work showed me the questions they actually had and how they phrased them.

I used it live on troubleshooting calls. When someone brought me a problem, I typed their actual question into the assistant in front of them and the answer came back on the spot. That did more than any demo I ran. People did not need to be told it was useful. They watched it be useful on their own problem.

I walked people through real questions, not features. Nobody cares that an assistant uses retrieval. They care that it answered the question that blocked them yesterday.

I found a champion in each business line. One person per team who had seen it work and would point colleagues at it. Adoption spreads through people a team already trusts.

I fed every failure back into retrieval. When the assistant got something wrong or could not answer, that became work for us, and the fix showed up in the next answers.

How I knew it was working

I watched two things.

The first was the support requests reaching my team. They went from more than 60 a week to about 10 to 12 a week on average. The organization got back more than 50 hours a week of manual effort.

The second was the failed answers. I defined the quality bar and the evaluation criteria myself and monitored response accuracy against real usage, not a benchmark. Real questions are messier and more specific than any test set, so real questions were the test set.

What I would do from day one next time

Plan the launch before the build. Name the habit you are replacing, the first ten people who will use it, and the champion in each team. That plan is more work than the retrieval pipeline, and it decides the outcome.

Measure the work that stopped arriving. Usage counts are flattering. The number that matters is how many questions no longer reach a person.

Treat bad answers as product work. Every wrong answer is a requirement. If they go into a backlog nobody reads, people stop trusting the tool faster than you can fix it.

Show it on someone else’s problem. A demo on your own example proves you can use it. A live answer to their question proves they can.

The lesson I keep coming back to

The build took weeks. Adoption took months, and that was the real work.

Inside a company, adoption is the product. An internal AI tool lives or dies on whether people trust it enough to change a working habit. The model, the retrieval and the interface all matter, but they are the part you can finish in a sprint. Trust is earned one answered question at a time, mostly in other people’s meetings.