A company can buy access to several AI tools, train its employees and still have no idea a few months later whether the investment has delivered any value. This usually happens when implementation starts with choosing technology rather than defining the problem it should solve. Here is how to approach the process so you can achieve the intended result and avoid disappointment.
Do not start by asking: “Which tools should we buy?”
Simply deciding that “we are implementing AI” says nothing about the problem that needs to be solved. When a company starts by browsing tools, it quickly encounters dozens of similar offers and promises. It then becomes difficult to tell what will genuinely help the team and what will become another application that the company pays for but hardly anyone uses.
A model, platform or AI agent is a means to an end, not the starting point. The same tool may work well for preparing proposals but be entirely unsuitable for handling complaints or organising notes and databases. Without understanding the process, the company ends up comparing features whose relevance it cannot yet assess.
The first question worth asking is: which task regularly takes employees a lot of time, follows a reasonably repeatable pattern and produces an output that is easy to check? Good candidates may include:
preparing a first draft of replies to similar customer enquiries,
organising meeting notes and extracting decisions and action points,
creating simple product descriptions from available materials,
finding information in an approved document repository,
preparing draft proposals from a form or brief,
assigning requests to the right categories and people.
Each example concerns a specific task rather than the general idea of “using AI”. This makes it possible to define the scope of the pilot, appoint an owner and decide how the results will be evaluated.
How do you choose a process for the first pilot?
A company will usually identify several areas where AI could help. Not all of them will be equally suitable as a starting point. Compare the options against a few straightforward criteria:
Frequency – a task performed every day or several times a week is more likely to produce a noticeable benefit than one that occurs only once a quarter or less often.
Repeatability – the easier it is to describe the steps, required data and expected result, the easier it will be to build a solution that works predictably.
Ease of review – begin with tasks whose output a person can assess quickly. For example, someone can read an AI-generated message before sending it or compare a meeting summary with their own notes.
Availability of source material – AI needs a reliable point of reference. This may include current procedures written in a clear format, approved examples, price lists, documentation or organised data. If the information is scattered and inconsistent, it must be put in order first.
Cost of an error – a process that affects security, legal obligations, payments or important business decisions is rarely a good testing ground for a first attempt. A mistake in a working summary is easy to correct. An incorrectly approved payment or permission change can have serious consequences.
A good first AI use case does not need to be the most ambitious one. Above all, it should allow the company to establish three things quickly: whether the solution helps, whether the team wants to use it and what is required for it to operate safely.
First step: conduct a brief process review
Begin by taking a careful and honest look at how the selected task is handled today. The review should answer several questions:
What starts the process, and what result should it produce?
Who performs each activity, and how much time does it usually take?
Which data, documents and systems do employees use?
Which parts are repeatable?
Which parts require human judgement?
Which mistakes occur most often, and what are their consequences?
How can someone tell whether the result is correct?
Does the process involve confidential data, personal data or information subject to access restrictions?
The answers often show that there is no need to automate the entire process. Sometimes improving a single step is enough. For example, if a salesperson spends two hours preparing a proposal, AI can create the first draft from an approved template and information from the brief. A person still checks the scope, price and terms but no longer starts with a blank document every time.
This type of review is best carried out with the people who actually perform the tasks. They know where problems arise, which data is missing, what requires caution and which activities consume the most time. If only managers who have no day-to-day involvement in the process discuss its automation, it is difficult to expect a useful outcome. The first attempt by the team to follow the new procedure may immediately reveal significant gaps and complications.
Off-the-shelf tool, integration or custom AI agent: how do you choose?
Only after describing the process can the company determine what kind of solution it really needs. If the task is to prepare meeting notes, a feature in software the team already uses may be enough. If information must be collected from email, a spreadsheet and a CRM system and then saved elsewhere, an integration will be necessary. A custom AI agent makes sense when it needs broad access to company knowledge, must complete multi-step tasks and has to follow defined rules.
The most advanced option is not always the best one. If a simple feature removes a specific task from an employee's workload, there is no reason to build a separate system. On the other hand, a standard AI chat will change little if someone must collect data from several places, explain the entire situation and then transfer the result to other tools every time.
When choosing the technology, determine where the required data is stored, which actions the solution should perform and which decisions should still require human approval. Only then can you select a tool that genuinely makes work easier instead of adding to the team's workload.
Define a specific objective before implementation and testing
“We will use AI” is not a specific objective, so it provides no basis for judging whether the implementation has succeeded. The objective should describe a change in the team's work.
It could be a reduction in the time needed to prepare a draft proposal, fewer requests being assigned to the wrong person or faster access to answers in company documentation. Record the starting point as well. How many minutes does the task take today? How many corrections does it usually require? How often does an employee need to search for information in several places?
Not every result can be reduced to a single number. Qualitative questions are useful too:
Does the output contain all the required information?
Does the employee save time after review and corrections are taken into account?
Does the solution also work correctly with less typical cases?
Does the team understand when it can rely on AI and when the task must be completed manually?
This approach prevents a company from judging a solution solely because it performs well in a presentation. Demonstrations usually rely on prepared data and simple examples. Only a pilot involving real tasks will show whether employees actually save time, how much correction the output requires and what happens in less typical situations.
Start with a small pilot, not the whole company
Do not launch the first solution across the entire company or give it unrestricted access to live systems. It is safer to test it outside the main process or with a small group that can evaluate the results carefully and report any problems.
When planning the pilot, define:
which data the AI may use,
which actions it may perform independently,
which outputs must always be approved by a person,
who owns the pilot and collects feedback,
how to stop the solution and roll back any changes it has made.
For example, an assistant handling customer enquiries may initially do nothing more than prepare suggested replies. It does not send them or change any information in the system. An employee sees the source material, checks the message, corrects it if necessary and only then decides whether to send it.
These limits do not undermine the purpose of automation. They make it possible to collect real examples, identify weak points and determine how much oversight the process requires. The solution can be given more autonomy later if its results are consistent and the company knows how to respond to errors.
What does the company learn from the first tests?
The first pilot should answer a basic question: does the solution genuinely make the selected process easier? It will often also reveal what prevents the solution from working well. The problem may be outdated materials, conflicting instructions, the absence of a clearly appointed owner or rules known to only part of the team.
If AI provides one price on one occasion and a different price on another, the cause may be three versions of a price list saved in company documents. A similar problem arises when the team uses different proposal templates. Before expanding the implementation, the company must first organise its sources and decide which version of the information is authoritative.
The pilot also shows whether the solution fits the way people actually work. If an employee must manually collect data from several places, explain it to the tool in detail and then spend a long time correcting the output, the implementation may add work even though it was intended to reduce it. That is why the company must assess not only the quality of the AI output but also the entire process of using the new procedure.
From one process to a sensible implementation plan
After several weeks of testing, the company should be able to answer a few straightforward questions: what works, how much work has been eliminated, where human judgement is still required and which problems appeared along the way. If the result is positive, the scope can be expanded or the company can move to another process. If not, nothing is lost: improving one small project is easier than withdrawing several solutions deployed across the organisation.
This creates a plan based on the company's own experience rather than a vendor's promises. Each subsequent implementation can build on earlier decisions about data, security, accountability and evaluating results.
