Five ways a small-business pilot dies

Most of them are dead by week six

The failures are not exotic and they are not about the technology. They repeat, they have tells you can spot early, and each has a cheap fix if you catch it in the first fortnight.

1. There was no before

The most common death, and the quietest. Three months in, somebody asks whether it is working. Nobody can answer. The tool is neither cancelled nor trusted; it just sits on the bank statement.

The tell in week one: you cannot say how many hours the task took before you started.

The fix: the five-day tally, and refusing to start until you have it. If you have already started, tally now and compare against the same week last year from your records.

2. The wrong task was chosen

Usually the impressive one rather than the frequent one. The annual capability statement instead of the forty enquiries a day. A brilliant demo, four hours saved once a year.

The tell: the task happens fewer than twice a week, or the saving is real but the total is under about twenty hours a year.

The fix: frequency beats impressiveness. Every time.

3. The checking cost was never counted

Drafting drops from eight minutes to one, so it feels like a seven-minute saving. The verification takes five, and nobody times it, so the actual saving is two minutes. Meanwhile the effort of switching, pasting and reading feels like more work than before, and it might be.

The tell: somebody says “it’s quicker but it doesn’t really feel quicker”. That sentence is a measurement, and it is usually right.

The fix: time the whole loop on ten items, not the generation. If checking is more than half the original task time, choose another task.

4. The tool arrived before the problem

A good demo, a colleague’s recommendation, a free trial. The tool is bought and then a use is found for it. The use is always slightly forced, and the thing dies when the free trial ends.

The tell: you can name the tool before you can name the task and its hours.

The fix: write the task, the hours and the alternative on paper before you look at any product. Then look. Also check whether software you already pay for does it, which it often does.

5. The person who cared left, or got busy

One person learned it. Nothing was written down. They go on leave, or a big order comes in, and three weeks later nobody remembers the prompt that worked or the two rules that kept it safe. Use decays to zero and nobody makes a decision to stop.

The tell: the working prompts live in one person’s chat history.

The fix: the one-page file (prompts, mistakes, rules) updated whenever something surprising happens. Ten minutes a week.

The sixth death: it worked and nobody noticed

Worth naming separately because it is the saddest.

A change saved four hours a week. Nobody measured it, so the hours dispersed into the general fog of the week rather than into anything deliberate. Six months later the owner is exactly as busy, cannot point to a benefit, and cancels the subscription during a cost review.

Saved time does not accumulate on its own. It gets absorbed. If you want the four hours to become anything (an earlier finish, a new product line, the thing you never get to) decide in advance what they are for and put it in the diary. Otherwise the honest description of your successful pilot is that you now do slightly more of everything.

What survives

The pilots that are still running a year later share very little in the way of tooling and almost everything in the way of habits: a written baseline, a task chosen for frequency, a timed checking pass, a named owner, a file of what was learned, and a date in the diary to look at it again.

None of that is about AI. It is what running a small change through a small business looks like when it is done properly, and it is why the businesses that get value here are usually not the ones with the best tools.