AI consulting · Playbook

How to run a first AI pilot in a small business: the six-week plan we use

Most first AI projects fail for the same reason: they start with a tool and go looking for a problem. A pilot that works starts with one job, one number and a decision date. This is the plan we run with clients, and you can run it without us.

A small team planning work at a table
Pick the workflow before you pick the tool.

Before week one: pick the right workflow

The best first pilot is boring. Look for a task that scores well on all five of these:

  • Frequent. It happens dozens of times a week, so small savings add up.
  • Text-heavy. Emails, forms, documents, notes. Current AI is strongest with language.
  • Checkable. A person can tell in seconds whether the output is right.
  • Low-stakes when wrong. A bad draft costs a minute, not a client.
  • Owned. One person cares about it and will use the result.

Good candidates: drafting replies to common customer questions, pulling fields out of invoices or applications, summarizing call notes, triaging a shared inbox, drafting first versions of routine reports. Poor candidates for a first pilot: anything that commits money automatically, legal or medical judgment, and anything nobody does often.

Week 1: measure the baseline and agree the number

You cannot show a saving you did not measure. Spend this week timing the task as it is done today, on real work, and counting errors or rework. Then write down the success measure and get the owner to agree it:

Example pilot measures. Pick one primary number; track one quality guard.
WorkflowPrimary measureQuality guard
Customer email repliesMinutes per replyShare of drafts sent with no edits or light edits
Invoice or form intakeDocuments processed per hourField error rate against a checked sample
Inbox or ticket triageTime to first responseShare routed to the wrong person
Report draftingHours per reportReviewer corrections per report

Also agree the decision rule now, before anyone is attached to the result: for example, “if minutes per reply fall by a third with no rise in complaints, we roll it out.”

Week 2: sort out data and access

Collect the material the AI needs to do the job well: your policies, product information, past good examples, templates. Decide what it must never see. Pick a provider whose contract keeps your material out of model training, or run an open model on your own server if the data is sensitive. Set up accounts in your name, with a spending cap.

Write a one-page rule for staff: what the pilot tool is for, what not to paste into it, and that a person checks everything before it goes out.

Weeks 3 and 4: build the smallest thing that does the job

Resist building a platform. The first version should sit where the work already happens, often as a draft that appears in the inbox, a button in a form, or a shared document, and it should show its sources so the person checking it can verify in one click. Test it on last month’s real cases before it touches live work.

Week 5: run it beside the people who do the job

Staff use the tool on live work for a full week, with every output reviewed before it goes anywhere. Log the time, the edits and every bad answer. The bad answers are the most valuable data you will collect: they tell you whether the problem is missing information, a poor instruction, or a task AI should not be doing.

Week 6: measure and decide

Compare against the week-one baseline using the rule you agreed. There are only three honest outcomes:

  • Scale it. It hit the number. Harden it (access control, logging, monitoring, cost limits), train the rest of the team and pick the next workflow.
  • Fix it. It came close and the bad answers point to a clear fix, usually better source material. Run two more weeks.
  • Stop it. It did not work. You have spent six weeks, not a year, and you know something real about where AI does and does not fit your business.

What usually goes wrong

  • No baseline, so the result is a feeling, not a number.
  • Too big a first task, so it never finishes.
  • No owner, so nobody uses it after the demo.
  • Answers with no sources, so staff cannot trust them and quietly stop checking, or stop using it.
  • Data in the wrong place, because nobody wrote down what not to paste.

None of this needs a large budget. It needs one workflow, one number and the discipline to decide on the date you said you would.