Bottom-up AI experiments get stuck as point solutions

The first automation I built for Evolve was a script that flagged abandoned carts worth chasing. It worked from day one. It would also have been forgotten within a month if it had stayed a script.

A pilot that saves someone an hour a week is easy to greenlight and just as easy to ignore. Most AI programmes stall exactly there: a shelf of small wins that never add up to a change in how the business runs.

The pile of pilots

Give a company permission to experiment with AI and it will produce ideas fast. A summariser for the weekly report. A drafting assistant for one team's emails. A chatbot bolted onto the website. Each one gets built by whoever was closest to the annoyance, tested for a few weeks, and either quietly adopted or quietly dropped.

None of that is wasted. It is how a business finds out where language, judgement or messy information are actually getting in the way. The problem is what happens next, which is usually nothing. Each pilot stays exactly the size of the team that built it, because nobody above that team was ever asked to fund the workflow change the pilot was pointing at.

Why the cart recovery script did not stay a script

The abandoned cart tool is still a point solution in the strict sense. It watches one signal and produces one output.

What kept it from becoming a forgotten pilot was everything built around it after the first version worked. High-value carts get checked against Shopify orders so the sales team is never chasing a sale that already happened. Results land on a dashboard and in a shared sheet instead of a private log. The recovery message goes out through the same support tool the team already lives in, so following up costs nothing extra.

That surrounding work is not a bigger version of the same pilot. It is a decision about where the workflow itself needed to change, made by someone who could see the whole path from a webhook firing to a customer getting called.

The missing layer is not more experiments

Running more pilots does not produce that decision. It produces more pilots.

The layer that is usually missing is somebody with enough view across marketing, support, data and operations to look at ten small wins and ask which two are actually worth redesigning a workflow around. That is a different skill from running the experiment. It is closer to editing: most of the ideas get starved on purpose so a few can get the budget, the data access and the weeks of integration work a point solution never asked for.

  • A summariser nobody asked to fund properly stays a summariser forever.
  • A cart-flagging script that gets a dashboard, a data feed and a place in the sales workflow stops being a script.

The difference is not the model. It is whether someone treated the pilot's result as the start of a redesign or as the end of the exercise.

This is not a return to writing a strategy document

It would be easy to read this as an argument for the thing I have argued against elsewhere: commission a strategy, hand it down, wait for transformation.

That is not what changes the outcome. What changes it is much smaller and much more specific: one person, or a tight group, holding enough context across functions to see which of the bottom-up discoveries deserve real weeks of work, and saying no to the rest so those weeks are actually available. A portfolio of five properly resourced systems beats fifty pilots competing for the same afternoon of everyone's attention.

The rule

Bottom-up experiments are how a business finds its real friction. They are not how it decides what to fix.

Someone still has to hold enough scope to look at the pile of small wins and choose the few that deserve a redesigned workflow, real data access and real time. That choice is the work. The pilots are just how you find out what is worth choosing.