Where to start with AI in your company so it does not end as a curiosity

The scenario is usually similar. Someone in the company opens an account with an AI tool, shows the team a few impressive examples, everyone experiments for two weeks, and then everything goes back to the old way of working. What remains is the belief that “AI is interesting, but it does not work for us”.

Most often the problem is not the tool. It is the order: people start with the question “what can it do?” instead of “where in our work do we lose time, and why?”. Below is an order that works the other way round.

Start with the process, not the tool

The first question is not “which tool should we use”, but “which part of the work do we want to improve”. The answer has to be specific: not “sales”, but “preparing a reply to an enquiry from the website”.

The tool is chosen last - to fit the task, the data the company has and what it is allowed to do with that data. The reverse order ends with looking for a use for a tool you have already paid for.

Talk to the people who do the work

This is the step most often skipped. The owner describes the process as they designed it. The person who carries it out every day describes it as it really is - with workarounds, exceptions and the places where everything gets stuck.

The difference between these two descriptions is usually the most interesting part of the whole discovery. That is where the tasks are that repeat, eat up time and are invisible from the top.

It is worth asking directly: what does your day look like, where do you wait for something or someone, what are you doing for the umpteenth time this week, which question do you answer most often.

Measure the starting point before you change anything

Without a number from before the change there is nothing to compare. After the implementation all that is left is an impression, and impressions vary depending on who you ask.

You do not need a reporting system for this. It is enough to measure one thing, for example how long it takes today to prepare a reply to a typical enquiry. For a week, on a few examples, recording the time and the number of corrections.

It is worth measuring in pairs: time together with quality. “Faster” on its own means nothing if the replies have to be corrected later or clients ask about what was missing.

Describe the use case specifically

“AI in marketing” is not a use case. A use case sounds like this: “preparing the first draft of a service description - Anna, four times a month”.

A description like this immediately tells you what is needed:

• who will use it,
• what goes in - which materials the tool receives,
• what comes out - what we expect at the end,
• how often it happens - because that decides whether it is worth doing at all,
• what the risk is - whether the content goes to a client or stays inside the company.

An idea that cannot be described this way is not yet a use case. The same goes for an idea for which the company has no data - then the first task is to put the data in order, not to implement AI.

Choose one use case to begin with

The temptation is to go straight for whatever saves the most. That is usually the wrong choice, because the biggest saving goes hand in hand with the biggest risk - for example a draft proposal with prices.

For the first step it is better to choose something that has:

• low risk - the result stays inside the company or a person reads it anyway,
• little effort - it does not require a month of tidying up data,
• an immediate effect - the team sees the point after the first use.

A good example is a summary of a client call: an overview, agreements, tasks with deadlines. There is one condition - someone has to write the call down or record it. I describe more examples like this, together with the conditions without which they will not work, in the article on AI use cases in sales.

Run a small pilot with a decision date

A pilot should be small enough to be doable and meaningful enough to lead somewhere. If the effect cannot be measured in four to six weeks, the scope is too big.

Before it starts, it is worth writing down a few things:

• one use case and what the pilot does not cover,
• an owner on the company side - the person responsible for it. A pilot without an owner usually fades out on its own,
• the starting point measured before the start,
• success criteria related to that starting point,
• a decision date - the day you decide whether to go further, change the scope or stop,
• stop conditions - what would have to happen to end it early.

Before the team starts using the tool for client-facing content, also agree how you check its answers. I describe a simple way to do it in the article on checking AI answers.

Five mistakes that most often end the attempt

1. Talking only to the owner. The process described from the top differs from the one that actually happens.
2. No measurement before the start. Afterwards you cannot show the effect - neither to yourself nor to a business partner.
3. A use case without data. If the company does not have the materials the tool is supposed to work on, it is an idea, not a plan.
4. A pilot that is too big. It ends with no result and the belief that “AI does not work”.
5. Expecting a specific percentage. No honest person will promise “30% savings” up front. What you can do is measure the starting point and check what has changed.

If you would rather not do it yourself

All of these steps can be done in-house - this article is here so you know in what order. If you would rather have someone talk to the team, measure the starting point and prepare the pilot card, I do that as part of an AI audit. It ends with a decision backed by discovery, not a list of possibilities.