How do you get your team to use a new AI system?

The system works. It passed testing, the demo went well and the team said it looked good. Three weeks after launch, orders are being keyed from the email again, invoices are being matched by hand and the new system is a tab nobody opens.

In a company without a change-management team, nobody's job is to stop this happening. The operations manager who sponsored the project is also running the warehouse, and the team lead who should champion it has a queue to clear. So adoption has to be designed into the system and the launch, in ways a busy manager can run. This guide covers how.

Why new systems get ignored

Ask the people who stopped using one and you'll usually hear one of four reasons.

• It added a step. The work still had to be checked somewhere else, so the system became one more place to look.
• It threatened someone. The person whose job it touched had no say in it and every reason to find its mistakes.
• It got something wrong and nobody said. The mistake wasn't explained or fixed, and from then on nothing the system did was trusted.
• It lived somewhere else. The work arrived in a new tool instead of the inbox, CRM or ERP the team already works in.

Each of these comes from a decision made during the project, and each can be decided differently.

Choose work the team wants to lose

Every team has work it's proud of and work it puts off. The first system should take the second kind: re-keying orders, chasing missing purchase order numbers, the Friday report, the twentieth reply about delivery times. Nobody defends that work, so nobody fights the system that takes it.

Ask the question directly and the answers are specific. The accounts assistant names the supplier invoice run. The sales coordinator names typing enquiries into the CRM. The service lead names the delivery-time replies. None of them names the difficult customer call or the supplier negotiation, because those are the parts they think of as the job.

This work usually passes the other tests too, because it's frequent and needs little judgment. Which AI use case to fund first sets out four questions for choosing. Adoption adds a fifth: would the team be glad to see this go?

Build it with the people who do the work

The person who matches invoices knows which suppliers quote the wrong order number and which customers always query their first invoice. That knowledge is the list of exceptions, and the system is only as good as that list. Put them in the room when the rules are written, and have them test the system on last month's real cases before it touches this month's. If that knowledge lives with one person and nowhere else, it's a risk in its own right, which we cover in what happens when the person who runs a process leaves.

Testing on real cases finds mistakes while they're cheap to fix. It also means the first wrong answer the team sees happens in a test, with them watching, instead of in live work. People trust a system they've watched go wrong and get fixed far more than one that arrives finished.

This takes time from someone who's already busy, so their manager has to make room for it. Take something else off their plate while the system is being built and tested, or the testing is what gets squeezed.

Keep their decisions visible

When a system makes decisions out of sight, the team reads it as a replacement. When it brings each decision to a person with everything attached, they read it as help, and they use it.

In practice the accounts assistant still approves the payment run, the sales coordinator still decides which enquiry to call first and the service agent still sends the reply. The system takes away the gathering and typing that used to come before each of those moments.

Make the new way the easy way

People do what's easiest, so design for that. Deliver the work where the team already looks: the new enquiry appears in the CRM, the matched invoice waits in the approval queue, the drafted reply sits in the ticket. If the system needs a screen of its own, keep it for the exceptions.

Then close the old route. If orders can still be keyed from the email, some will be, the system's record will have gaps and any comparison will be unfair to it. Agree a date with the team, announce it, and from that date the work goes through the new system. Keep a way back for real emergencies, with a named person who decides when to use it.

Tell them what happens to the hours

If a system takes ten hours out of someone's week and nobody says what those hours are for, they'll assume the worst. Say it before launch. The hours might go to the customers who were waiting, the backlog nobody reached or the work that needed a person all along. If the honest answer is that you'll need fewer people as you grow, say that too and plan for it, because the team will work it out either way and the system will take the blame.

Run the launch without a change team

You don't need a programme. You need one owner, usually the manager of the team that uses the system, and a short routine for the first month:

• Before launch: one message to the team saying what changes, where the work now lands, who to ask and the date the old route closes.
• Every day in the first week: ten minutes at the stand-up for anything the system got wrong or made harder.
• Every week in the first month: the owner goes through the corrections and exceptions with whoever runs the system and agrees the changes.
• At the end of the month: compare the reading you took before launch with today's, and share it with the team.

Take a hypothetical sales coordinator whose enquiries the system now reads and logs. On Monday she finds three new enquiries already in the CRM, each with the company, what they asked for and a drafted reply. She edits one sentence and sends all three before half past nine. On Wednesday the system sends her an enquiry from a university that should have gone to the public sector account manager. She mentions it at the stand-up, the routing rule is changed by Thursday, and on Friday she's the one asking whether the system could draft follow-ups on her open quotes.

Fixes have to be visible like that. When someone reports a problem on Wednesday and sees it fixed by Friday, they tell their colleagues, and that's usually when a team starts treating the system as its own. Planning this routine before go-live is part of deploying a system well.

What to do this week

1. Ask each team which single task they'd be happiest never to do again.
2. Pick the one that is also frequent, follows rules and starts from a form, an inbox or a document.
3. Name the person who does it today as the one who helps write the rules and tests the system.
4. Decide where the work will land after launch, inside a tool the team already uses.
5. Set the date the old route closes, and write down what the saved hours are for.

Get the next article when it's published.