Implementation & leadership
Video · 5 min read
The short answer
Watch: What should leaders actually put in place to move from talking about AI to making useful decisions?
Watch the explanation, then explore the practical implications below.
Begin with a business problem people can recognise
“We need to use AI” is an intention, not a useful implementation brief. A clearer starting point is a recurring problem such as customers waiting too long for quotations or a team repeatedly chasing the information needed to complete a job.
Describe the outcome and establish a baseline. Include elapsed time, hands-on effort, waiting, review and rework. This helps distinguish a task that looks slow from the constraint that actually delays the result.
Involve the people who perform and receive the work
The person preparing a document may not be the person who knows why it gets returned. Follow a recent example from the initial request through to the completed result, including the people who supply information, review it and use the output.
Ask where they search, retype, wait and check. Record what is missing at each handover and what makes an input usable. The exercise may show that generating a draft is straightforward while getting an agreed scope or approval is the real difficulty.
Give testing an owner and protected time
Someone needs responsibility for turning the problem into a bounded test. That may be an internal team working with a technical partner. They need representative records, appropriate access and time with the people who can judge the work.
Agree what the pilot includes and excludes. Define the intended result, review process, difficult cases and circumstances that should stop the workflow. A demonstration based only on clean examples will tell you little about the exceptions people encounter every day.
An example: reducing quotation turnaround time
A quoting pilot might initially aim to generate a first draft faster. Mapping the work could reveal that most delay comes from missing survey information and repeated clarification. A better test may combine a completeness check, a clear request for missing inputs and a draft assembled from approved information.
Measure the quotation process through to the agreed completion point, not just the time needed to generate text. Include reviewer effort and the quality of the final commitment. Keep commercial approval with the authorised person under the agreed rules.
Connect the pilot to the authority to change the process
Before the test starts, identify who can change the workflow if it succeeds. They may need to alter an approval step, remove a duplicate report, allocate training time or agree ongoing support. Those decisions should not be left until after the demonstration.
Define what evidence that person will need to proceed. A useful review can result in adoption, a narrower scope, more testing or stopping. The purpose is to make an informed decision, not to treat continuation as the only acceptable outcome.
Plan the move into ordinary work
Agree who owns the process after launch, who handles failures and how changes to data, permissions or rules are reviewed. Train people on complete activities, including correcting an answer and recovering when information is unavailable.
At CSM, we would connect discovery, a bounded scope, practical testing and controlled use. The people responsible for the outcome should remain involved throughout. Measure completed work and net effort after adoption, and use feedback to improve the process. A successful pilot should establish how useful work will continue when the demonstration is over.
Questions for your leadership team
What outcome are we trying to improve?
State the recurring business problem and establish a baseline for the whole workflow.
Have we involved the people who supply, perform and receive the work?
Use a real example to understand the bottleneck and handover requirements.
Who has time and responsibility to run the test?
Name the owner and secure representative records, access and expert review.
Who can change the process if the test succeeds?
Bring that decision maker into the scope and acceptance criteria from the beginning.
What happens after the pilot?
Agree adoption, training, maintenance and support responsibilities before normal use.
Full video transcript
The full video transcript is included below for reference.
I think you need three things happening inside the business.
First, leadership needs to decide what you’re actually trying to improve. Saying “we need to use AI” doesn’t give people much direction. Saying “our team spends too much time preparing quotes, and customers are waiting too long for an answer” gives them a problem they can work on.
Second, you need the people doing that work involved. They know what slows it down. Maybe preparing the quote isn’t actually the difficult part. Maybe it’s chasing missing information or waiting for someone to approve it. If you don’t involve those people, you can spend a lot of time making the wrong part faster.
Then you need someone with the time and responsibility to test a better way of doing it. That might be a small internal team working with a technical partner. They take real examples, try the process with AI and check whether it actually improves the work.
And those three things need to connect. The people doing the work identify the problem. Someone tests a solution. Leadership decides whether to change the process and gives people the support to make that change.
Otherwise, you get what happens in a lot of businesses. Someone builds a useful demonstration, everyone agrees it looks promising, and then everybody goes back to working exactly as they did before.
So before you start another AI pilot, ask: if this works, who has the authority to change how we do the work? That person needs to be involved from the beginning.
Put these questions to work in your business
Bring a real decision or workflow to a conversation with CSM. We can explore the evidence, responsibilities and practical steps needed to make AI useful for your team.