Where to start with AI in your business

Start from work, not from tools

The common failure is starting with a product and hunting for somewhere to use it. Start instead with a list of things that happen repeatedly in your business and annoy somebody. Ten minutes, no filtering.

Then apply the properties below. Usually two or three survive, and the choice between them is easy.

Four properties of a good first workflow

• You can put a number on it today. Volume, hours, response time, how often it gets skipped. Without a before there is no after, and in three months you will be arguing about impressions.
• It is bounded. A clear beginning and end. "Answer enquiries about availability and pricing" is bounded. "Handle the inbox" is not.
• Errors are visible and cheap. You find out quickly, and the cost of being wrong is an apology rather than a customer or a regulator.
• It is documented, or could be in an afternoon. If nobody can write down how it works, an agent cannot follow it — and the extraction is where much of the value turns out to be anyway.

Three that make an obvious-looking one a trap

• It runs on tacit knowledge. The person doing it says "you just know". They do know — from ten years of context nobody has written down. Automating this starts with a documentation project, and you should decide deliberately whether you want one.
• It touches money or identity. Payments, contracts, anything creating a commitment. Not never, but not first: you want your approval habits established before the stakes are high.
• Nobody has time to review the output. This is the quiet killer. If the only person who can check the work is already at capacity, the approval boundary gets abandoned in week two and you end up with an unsupervised system nobody trusts.

The three that usually win

Across most small and mid-sized businesses, the same candidates come out on top:

• Inbound enquiry handling. High volume, answerable from existing documents, errors immediately visible, and a measurable before. Almost always the right first choice if you have inbound demand.
• Inbox triage and reply drafts. Sorting what matters and preparing the first version, with a person sending. Low risk because nothing leaves unapproved.
• Recurring research or reporting. The weekly thing that happens fortnightly at best. Zero downside — it was not getting done anyway — and it demonstrates scheduled work, which is where most of the compounding sits.

Scope it smaller than feels satisfying

The instinct is to start with something impressive. Resist it. A narrow first deployment gets to production fast, produces evidence quickly, and teaches you your own approval preferences on something where being wrong is survivable.

Concretely: one channel, not five. One category of question, not all of them. Reads autonomous, anything outbound gated. Widen from evidence.

The first ninety days

1. Weeks 1–2. Choose the workflow. Write down the before-number. Write down the procedure.
2. Weeks 3–4. Deploy narrow. Review every output. Expect to correct things — that is the work, not a sign of failure.
3. Weeks 5–8. Capture the corrections as procedures. Widen the boundary where evidence supports it. Review burden should be visibly falling.
4. Weeks 9–12. Compare against the before-number. Decide: scale to a second workflow, or stop. Both are legitimate.

And a case for not starting

If nothing on your list has the four properties, the honest answer is to wait, or to spend the time writing procedures down instead — that has value whether or not AI ever touches it. A deployment built on an undocumented process inherits the ambiguity and adds a machine to it.

For what to measure, measuring AI ROI. For the arithmetic on whether a candidate pays, improving efficiency with AI.