Choose a first task the team can assess
The first task needs a recognised purpose, an observable result and someone able to distinguish correct work from an inadequate response. Avoid starting with a decision the team already struggles to explain. The pilot should teach people how to work with AI in a concrete situation whose consequences they can follow.
Imagine a team receiving sales enquiries and spending time organising information before preparing proposals. An initial use could summarise the request, identify the service mentioned and flag questions needing clarification. The salesperson still decides what to offer, understands the commercial conditions and can assess whether that preparation is useful.
In this hypothetical example, the pilot does not need to send messages or change prices to provide value. It could reduce reading time and make information easier to find. Limiting the task also clarifies whether a failure comes from the summary, the original information or the human decision that follows.
Ask the person performing the work to help define the test. A team leader may understand the objective, while those receiving enquiries recognise ambiguous wording and common exceptions. Their involvement improves the examples and avoids presenting a ready-made solution to a process nobody has observed in sufficient detail.
To prepare your next step, explore Assessing business readiness for AI.
Write down what remains the team's decision
Before starting the pilot, identify who checks the result, who resolves exceptions and who authorises actions affecting the customer or company. Record those roles in simple, accessible language. Introducing AI should clarify responsibility, including the supervision work that now needs to happen alongside the preparation or execution performed by the tool.
For sales support, the assistant might prepare a summary, the salesperson check the enquiry and a manager approve a special condition. That division should match the company's real process. Adding AI does not automatically give the person configuring the tool authority to change commercial rules or commitments made to customers.
Defining who approves each part of an automation project helps avoid unclear responsibilities. If a result reaches a manager without indicating whether it has been checked, they may assume a review that never happened. The status of each piece of work needs to travel with its content.
Set aside time for this initial review. Giving people tool access while retaining the same workload may encourage rushed acceptance or cause the test to be abandoned for lack of availability. The pilot needs room to observe, correct instructions and discuss cases where a response sounds convincing but does not serve the task.
Run a supervised trial with different cases
Use representative cases and compare results against criteria defined before the experiment. Include incomplete inputs and situations requiring refusal or referral. The team should observe both response quality and its own ability to check the work, explain errors and recover when something goes wrong, rather than only measuring successful automatic completion.
A set of sales enquiries could include a clear request, one with missing information and another asking for terms outside the offer. Define the expected behaviour for each. For the incomplete case, the correct response might be a list of questions without a commercial recommendation, and that should count as an appropriate result.
The criteria for testing an automation before handing it to the team help organise this experience. Observe whether the system respects scope, matches information to the correct request and makes incomplete results visible. A collection of attractive responses does not demonstrate that the relevant exceptions have been handled.
Confirm effective access and the information available for the task too. Behavioural instructions do not replace appropriate permissions, and the pilot owner should understand what the tool can consult or change. Where necessary, ask the technical team to demonstrate those limits, including attempts that the application should refuse.
Expand scope only for an operational reason
After the trial, decide which additional responsibility would address a specific need and what evidence justifies testing it. The next step could save a draft, organise a queue or perform a limited internal action. A good initial experience does not authorise every action connected with the same process or customer.
If enquiry summaries work well, the next step could store them against the correct record for easier reference. That introduces a new check: confirming the customer association and preserving existing information. Approving the quality of the summary does not prove that writing it into the system has been implemented correctly.
Decisions affecting money, commitments or recipients need their own limits. The example of setting boundaries before changing advertising budgets shows why authorisation should reflect consequences. A team can accept help analysing a campaign while keeping the investment decision with a person who is responsible for the business outcome.
Define what would trigger a reduction in scope: relevant errors, increasing corrections, insufficient information or inadequate supervision. Returning to preparation only may be appropriate while the process is corrected. The pilot is not a promise of continually increasing autonomy; it is a way to discover a workable division of responsibility.
Prepare continuity before widening access
Before making the process available to more people, check whether another person can use it, recognise its limitations and request help when needed. Document its purpose, examples and approval requirements. Expansion should preserve the lessons from the pilot without depending entirely on the continued presence of the person who originally configured it.
Arrange a supervised handover to someone who was not involved in building the process. Ask them to handle a normal case and an incomplete case, explaining what they would do next. Their questions reveal what needs improving in the instructions, presentation of results or allocation of responsibility before adding more users.
Choose a simple way to collect problems and improvement decisions. A report should help locate the case and explain the difference between the observed and expected result without spreading sensitive information through unnecessary channels. Someone needs responsibility for reviewing that feedback and deciding which changes should enter the process.
Introducing AI becomes more robust when the team can explain the benefit and limits of its chosen task. Starting small may provide enough information to decide the next step or conclude that the use is not worthwhile. The outcome to seek is a team able to work better and remain accountable for what it delivers.