Make every AI pilot end on a fixed date. Pick one task your business repeats every week, and name one person who is responsible for getting it working. Then put a date on the calendar. On that date the tool is either kept as part of how you run or killed on purpose. Pilots that have no end date don't fail. They drift, because nothing ever forces a decision, and drifting costs you more than a clean failure would.
Why your pilots never finish
Pilots stall because nothing requires them to stop. A typical small business "tries" an AI tool like this: someone signs up for a trial and tests it on a few emails. They show it to a colleague, then get pulled back into client work. Three weeks later the login is still active, the tool still counts as being "evaluated," and nobody can say whether it works. Nobody decided against it. Nobody had to decide anything, so it just sits there.
That is a structural problem, and buying better software won't fix it. A pilot without an end date has no point where anyone has to check whether it worked, so it never gets checked. The tool keeps half a seat at the table and a share of everyone's attention. It also gets in the way of the next idea, because "we're already trying AI for that" closes the conversation.
The claim of this piece is simple and you can test it: **a pilot with a named owner, a single repeated task, and a keep or kill date will reach a decision. A pilot missing any one of those three will not.** Try it on your next tool and see if it holds.
Rule one: one repeated task, not a category
The first fix is to make the scope narrow. "Use AI for marketing" is a category, and a category can't be tested. "Draft the Friday client update email from the week's project notes" is a task. It happens on a schedule, it produces a specific output, and you can compare the AI version with the version a person would have written.
Repetition matters most. A task that comes up every week gives you a new test every week. A task that comes up twice a year gives you two data points before the deadline, and you can't decide anything from two data points. Good first candidates look like these:
- Turning call notes into a follow-up email for each new lead - Sorting the shared inbox into "needs reply today," "needs reply this week," and "file it" - Writing first-draft product descriptions from a supplier spec sheet - Summarizing the weekly job board into a list of jobs for the field crew
Each of these has a clear input, a clear output, and a person who already does it by hand. The person who already does it is the one who can tell you whether the AI version is good enough. If your process isn't written down yet, write it down first. A model can only follow steps that someone has stated.
Rule two: one named person who ships it
The second fix is ownership. "The team is evaluating it" means nobody is. Put one person's name next to the pilot, and make their job specific: get this task running in the tool and in daily use by the date. Exploring the tool or forming an opinion about it doesn't count.
"Ships" is the important word. Shipping means the task is actually being done through the new workflow, on real work, every time it comes up. Running a demo or getting one impressive output in a test doesn't count. The owner chooses the prompt or template, decides where the output goes, and writes the one-page note explaining how the workflow runs so someone else can cover it during a vacation.
The owner also needs time set aside for this. Suppose you block 2.5 hours per week for the owner over the pilot window. That's enough to set things up, fix failures, and tighten the instructions. It's small enough that the pilot can't quietly take over their real job. Adjust the number to fit your business, but write some number down. Unbudgeted time ends up spent on whatever is most urgent, and a pilot is never the most urgent thing.
The owner shouldn't be the most enthusiastic AI person in the building. It should be the person who does the task today, or the person who would be most annoyed if the new version got it wrong. Enthusiasts forgive a tool's failures. The person who actually does the work won't.
Rule three: a date on the calendar, with two allowed outcomes
The third fix is the date itself. Book a 30-minute meeting on the calendar now, before the pilot starts. A two to four week window works for most weekly tasks: it's long enough to see the tool handle ordinary weeks, a busy week, and at least one odd case. When the meeting comes, there are exactly two outcomes.
**Keep** means the tool becomes part of how the business runs. The workflow gets written down, the owner stays responsible for it, and it gets a light check every 30, 60, and 90 days to make sure it's still doing the job.
**Kill** means you stop on purpose. Cancel the login, record in a couple of sentences what didn't work, and free up the owner's time for the next candidate.
"Extend the pilot" is not one of the outcomes. Extending is how a pilot stalls in the first place. If the result really is unclear, the most likely cause is that the task was too vague or the measurement was missing. In that case the right move is to kill this version and start a new pilot with a narrower task and a new date. A new pilot means you've made a decision. An extension just puts it off.
What gets measured before the date
You can't hold a keep or kill meeting without evidence, so decide what you'll measure on day one. Usually that's three things:
1. **Time per run.** How long the task took by hand before, and how long it takes now, including the time spent checking and fixing the AI output. A draft that needs heavy editing can save nothing. 2. **Error type.** The specific ways the output goes wrong. "It got the client's name wrong twice" is useful. "It's sometimes off" isn't. 3. **Actual usage.** Whether the task really went through the new workflow every time it came up, or whether the owner went back to the old way when things got busy.
The third measure matters most. When people stop using a tool under pressure, it's because they don't trust it, and they'd rather not say so out loud. If the owner skipped the tool during the one hectic week of the pilot, you already know most of what the meeting is going to find.
For illustration, imagine a landscaping company testing an AI tool on its weekly crew schedule summary. Before the pilot, the office manager spends about an hour each Monday on it. By week three, the AI draft plus checking takes twenty minutes, it has gone wrong twice (both times on jobs moved because of weather), and it was used every single Monday. That's a keep, with one note added to the instructions: check every weather reschedule by hand. Now change the scenario so the manager skipped the tool on the two busiest Mondays. That's a kill, or a narrower redesign, no matter how good the other drafts looked.
Killing a pilot is a result, not a failure
Killing on purpose is a good outcome, and you should treat it that way. A pilot that ends in a deliberate kill gives you three things. You learn what this tool can't do for this task. You get the owner's time back. And you clear space for the next attempt. A pilot that drifts gives you none of those, and it keeps holding a spot in everyone's head.
Small businesses have a hard time killing tools because a kill feels like admitting the money and effort were wasted. That money and effort is gone whether or not you decide. What you get back is attention. A business that runs four short pilots in a quarter, keeps one, and kills three is ahead of a business that has had one pilot "in progress" since spring.
Write the kill note as carefully as a keep note. Two or three sentences are enough: what the task was, what went wrong, and what would have to change before you'd try again. The next time someone suggests the same tool, that note saves you from running the same failed experiment twice.
A one-page pilot charter you can copy
Put all three rules on one page before the pilot starts. If something doesn't fit on one page, the scope is too big. Use these fields:
- **Task:** the one repeated task, described as input and output - **Owner:** one name - **Time budget:** hours per week the owner has set aside for it - **Baseline:** how long the task takes by hand today - **Measures:** time per run, error types, actual usage - **Decision date:** a specific calendar date, already booked - **Allowed outcomes:** keep or kill
Pin it wherever your team actually looks, whether that's the shared drive, the project board, or the wall above the printer. The point is that anyone in the business can see who owns the pilot and when it ends.
Start this week
Choose the pilot that has been "in progress" the longest and put a date on it. You don't need a strategy offsite or a new tool. Name the task, name the owner, and book the meeting two to four weeks out. When the date comes, decide keep or kill. Most stalled AI efforts in small businesses don't need better technology. They need a deadline that someone owns.
Related
- smb-ai-strategy-one-workflow - measuring-time-saved-on-one-ai-workflow - write-down-your-process-so-ai-can-follow-it