Where to start with AI in business:
a practical map
Which processes are worth automating first, what you actually need (data, people, budget) and how to tell whether an idea is a good candidate.
12 minute read
The most common problem is not choosing the tool: it is choosing the first problem. Almost every company that stalls in the first six months does so for the same reason — they start with a project that is too large, too critical, or too vague. This guide is a map to help you avoid that. It does not talk about "digital transformation"; it talks about what to do on Monday morning.
The right question
is not "how do we use AI?"
The wrong question is "how do we use AI?" It is wrong because AI is a solution in search of a problem, and you end up inventing projects to justify the tool. The right question is: "which activities cost us time every week, are repetitive, and produce text or data?"
All three conditions matter together:
- Repetitive and frequent. If an activity happens twice a year it is not worth automating, even if it is tedious.
- Based on language or semi-structured data. Language models are good with text, emails, documents, PDFs, and messy tables. They do not replace business management software or a spreadsheet with precise formulas.
- Low criticality if an error occurs. For your first project, do not choose something where a mistake costs you a client or a penalty. Choose something where a mistake costs a re-read.
Frequency versus impact:
where to really start
Before choosing, map your candidate activities on two axes: frequency (how often it happens) and impact of the time saved. Four zones emerge.
| Low frequency | High frequency | |
|---|---|---|
| Low impact | Ignore. Not worth the effort. | Automate with simple rules — AI not needed. |
| High impact | Evaluate case by case — often a person is better. | Start here. Maximum return, manageable risk. |
The bottom-right quadrant is your starting zone: things that happen often, where each occurrence steals minutes that add up to hours. Typical examples in an SME: answering recurring information requests, summarising technical documents or specifications, extracting data from supplier PDFs, translating business correspondence, reformatting content for different channels.
How to tell whether an idea
is a good candidate
For every idea that looks promising, run it through five questions. If you answer "no" to even one of the first three, stop.
- Is the input available in digital form? If the information lives only in someone's head or on unscanned handwritten sheets, it needs to be digitised first.
- Is there a "good example" of what the output should look like? If no one in the company can describe what a correct answer looks like, the model will not be able to guess it.
- Can a person verify the error in a few seconds? Someone needs to be able to spot at a glance whether the output is wrong. If checking takes an hour, the time saving disappears.
- Does the volume justify the investment? Estimate how many times a month it happens and how many minutes it costs each time. Below a few hours per month, it often does not make sense.
- Can we start small? The idea should be broken down into a first minimal version that delivers value on its own, without depending on everything else.
Data, people, budget:
in the right order
Data
The word "data" is more frightening than it needs to be. For early projects you do not need a data lake or an integration project. You need the input information to be accessible and readable: a folder of PDFs, an exportable Excel sheet, emails in a mailbox, records from a business system that exports to CSV. The real work is not "having lots of data" — it is having the few data points the use case needs, clean enough to be used.
A practical check: take ten real examples of the input. If you yourself, looking at them, cannot derive the desired output without asking a colleague for help, the problem is not the AI — the information is simply not sufficient.
People
The most underestimated factor. An AI project in an SME needs three roles, which can be covered by two people:
- The person who knows the process (the domain expert). They know what a correct output looks like and can spot errors. Without them, nothing gets validated.
- The person who gets their hands on the tool (an internal technical person or enthusiastic tinkerer). You do not need a data scientist: you need someone comfortable with an API, a spreadsheet, a script, or a no-code tool.
- The person who decides and keeps the project small. The most important role is saying "this is enough, let's put it into use" before the project grows without bound.
Budget
This is where the most pleasant surprise lies. The cost of models today is almost always the smallest item. Language model APIs are pay-per-use, at fractions of a cent per request on economical models, and a serious first experiment often costs less than a dinner out. The real cost is people's time: understanding the process, preparing examples, validating results, and integrating everything.
Practical rule: for the first project, budget zero for "buying AI" and put the entire budget into internal working hours. If the use case does not hold up without spending on licences, it is probably too large to be the first one.
A sequence that works,
without wasting the early time
- Weeks 1–2 — List and choose. Write down 8–10 candidate activities, put them through the five-question test, and choose one. Just one.
- Weeks 3–4 — Manual prototype. Before writing any code, try the use case "by hand" using a chat interface: paste in a real example and see whether the model produces an acceptable result. If it does not work here, it will not work automated either.
- Weeks 5–8 — Minimal version in use. Automate only the part that delivered value in the prototype. Keep a person "in the loop" who reviews every output before it is used.
- Months 3–4 — Measure and build confidence. Collect numbers: how often the output was correct first time, how much time you saved. Only with numbers can you decide whether to expand.
- Months 5–6 — Expand or change course. If the numbers are good, reduce human oversight and move to the second use case. If they are not, you have learnt a great deal at very low cost — change direction without regret.
What wastes
the first six months
- Starting with the "strategic" project. The use case that excites leadership is almost always the most complex and risky one. Save it for later.
- Wanting to automate everything at once. Having a human in the loop is not a failure — it is the correct way to start. Trust is earned with numbers, not in advance.
- Confusing demo and production. A demo that works on three carefully chosen examples is not a system that works on a thousand real cases. The difference is all the work in between.
- Skipping validation. Without someone saying "this output is correct / incorrect", you will never know whether the tool works, and sooner or later someone will trust a wrong answer.
- Buying the platform before you have the problem. Annual licences signed before the first real use case is validated are money that locks you into a direction not yet proven.
In summary
Choose a repetitive, frequent activity made of text or data, where an error costs little; try it by hand before automating it; keep a person to validate; measure; then decide whether to expand. The first six months are not for building the definitive system — they are for understanding which system is worth building.
Frequently asked
questions
How long does it take to get the first automation into use?
Typically four to eight weeks if you follow the plan: 1–2 weeks to choose the use case, 2 weeks for the manual prototype, 4 weeks for the minimal version in use. More than the code, what matters is the availability of an internal person to validate and the quality of the sample data.
How much does it cost to get started? Do you need a large AI licence budget?
No, and this is the most pleasant surprise: the cost of the models is almost always the smallest item. A first experiment on economical models costs fractions of a cent per request — often less than a dinner out. The real cost is the internal time to set up and validate.
What if no one in the company knows how to programme?
For the first use case you do not need to programme. An internal enthusiastic tinkerer who is comfortable with spreadsheets, APIs, and no-code tools (Make, Zapier, n8n) is enough. Only when the use case is established and volumes grow does it make sense to move to a custom script.
What happens if the first project does not work?
If you kept it small, you have learnt a great deal at very low cost: which type of process is not suitable, which data is missing, where the real pain lies. Change use case without regret. The real problem is when you start with a six-month project: there, failure burns time and trust.
Can I skip the manual prototype phase?
No. If the use case does not work when you try it by hand in the chat with 10 real examples, it will not work automated either. Skipping this phase is the fastest way to waste days of work automating a case the model cannot solve.
Would you like to talk through
your specific case?
A 30-minute call to get your bearings. No pre-packaged demos.
Write to us at [email protected]