The Tool Worked. The Deployment Failed.

What building an internal AI tool taught me about workflows, deployment, and why obvious value isn't enough.

The painful workflow in the consulting team

I worked in a consulting team that did large housing portfolio analysis. Clients sent us property data, and we turned it into analysis and reports.

The whole analytical process basically lived in Excel. These were files that had become small software systems. Every client shared data differently. Asset groups had to be built from messy inputs. Then the outputs had to be checked again and again, because one small mistake early in the file could flow into the whole analysis.

We weren’t doing this because the team was unsophisticated. It was the opposite. People had built clever checking logic into Excel. Multiple linked sheets. Long formulas. Pivot tables. Conditional formatting. Lookup logic. Review tabs. Exception tabs. Cells that depended on other cells three sheets away. It was impressive, but it was also fragile.

More importantly, we spent a huge amount of time doing repeatable work.

My first attempt at automation was a success

Not long after I joined the team, I started trying to automate the workflow.

The first version was not a grand AI product. I simply used ChatGPT to help me write VBA, the coding language in Excel, to automate some multi-step formulas. I wanted to remove a repeated pain from my own workday.

Instead of spending hours building formulas, concatenating checks, and repeating the same steps, the automation let the team press one button and let the spreadsheet do the work.

The tool was immediately adopted by the entire team because it saved hours of painful work and eliminated manual errors. The automation lived inside the workflow that people already understood.

This was the cleanest deployment I have ever experienced. The pain and the solution were obvious. The tool lived inside the existing system. The value was immediate.

I set out to automate the entire workflow

I knew it was just a start. I wanted to automate the whole asset group building process. I had left this full-time job due to personal reasons, but I now had more time to build the solution.

The first Excel automation had worked because the scope was narrow and the criteria were clear. But the whole process was different. It needed to handle more steps, files, exceptions, and more of the actual workflow. A generic template or VBA logic in Excel could not solve it.

I redesigned the workflow and built a system to accommodate the client data. The new tool could interpret data in different formats, handle multiple checks, anticipate exceptions, and demonstrate the results clearly.

The hardest part wasn’t writing code. It was translating years of unwritten operating knowledge into something a computer could execute.

It was the tool I had wished existed.

Building the product with the team felt natural

I built an initial prototype and sent a demo video to the team leader.

He was impressed and brought the team into the conversation. For the first time, the project stopped being only something I was building. It became a live deployment discussion with real users.

That meeting was energizing. We talked through what was possible and which parts of the process mattered most. The team asked for features and edge cases, and I understood immediately.

After that, I kept building.

After only three rounds of feedback, the product was ready to deploy. Nobody was asking whether the product worked anymore. Instead, people were discussing how their daily work would change once it was deployed. The conversation shifted to internal IT, rollout, and what else could be automated next.

That was the moment I thought the hard part was over.

The tool was ready. The deployment failed.

The team described the tool as transformational.

I knew exactly how much value it would create because I had done the job myself. The tool eliminated 20 to 30 hours of repetitive work on every client project, and this was only the first step.

Confident that the value was obvious, I finally sent my commercial proposal.

The response caught me completely off guard.

The director told me they had no budget. He had assumed I was building the tool for free, not to sell it. If I wanted to charge for it, they were simply not interested.

That was the moment I realized I had confused usefulness with deployment.

I spent weeks proving the tool worked and almost no time validating whether they would actually pay for it. I assumed that if the value was obvious enough, the commercial conversation would naturally follow.

What I misunderstood about deployment

One thing I completely ignored was how difficult it is to replace an established way of working.

The team’s workflow had evolved over many years through client demands, edge cases, internal reviews, IT approvals, and countless small decisions. It wasn’t perfect, but it worked.

From my perspective, I had built a much better tool. From the team’s perspective, adopting it meant replacing a workflow they had trusted for years with something entirely new.

The technical solution wasn’t the hardest part. The real challenge was convincing the team to move away from a system that already worked well enough.

A product can solve a real problem, delight its users, and still fail to deploy.