How do you get your team to use an AI system?

The system works. It passed testing, the demo went well, and the team said it looked great. Three weeks after launch, the enquiries are back in the spreadsheet, the invoices are being matched by hand again, and the new system is a tab nobody opens.

That is the most common way an automation project fails, and it has nothing to do with the technology. It was decided before launch, in the choice of process and the way it was built. Here is how to decide it the other way.

Why systems get ignored

Ask the people who stopped using one and you get the same four answers.

• It added a step. The work still had to be checked somewhere else, so the system was 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, once, in silence. Nobody was told, nobody fixed it, and from then on nothing it did was trusted.
• It lived somewhere else. The work arrived in a new tool instead of the inbox or CRM the team already lived in.

Every one of those is a design decision, and every one can be made differently.

Choose a process they want to lose

There is work your team is proud of and work they put off. The first system should take the second kind: the re-keying, the chasing, the Friday afternoon report, the twenty identical replies 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 finance assistant says the Friday invoice run. The account executive says re-typing enquiries into the CRM. The support lead says the delivery-time replies. None of them says the customer call, the supplier negotiation or the complaint that needs a careful reply, because those are the parts of the job they think of as the job.

This is also usually the right process on every other measure, since it's frequent and needs little judgment. What should you automate first? gives you the four questions. The adoption question just adds one more: would the team cheer if this disappeared?

Build it with the people who do the work

The person who matches invoices knows which suppliers send the wrong purchase order number and which customers always query the first invoice. That knowledge is the exception list, and the system is only as good as it. So they are in the room when the rules are written, and they test the system on last month's real cases before it goes anywhere near this month's.

Testing on real cases does two things. It finds the mistakes while they're cheap. And it means the first wrong answer the team sees happens in a test, with them, rather than in production, behind their back. People trust a system they've watched fail and get fixed far more than one that arrives finished.

Keep their judgment visible

A system that quietly makes the decision looks like a replacement. A system that brings the decision to the person, with everything attached, looks like help. The difference is the same work, designed two ways, and only one of them gets used. How do you keep a person in charge of an automated process? sets out the design.

In practice this means the finance lead still approves, the account executive still decides whether to call, the support agent still sends the reply. What's gone is the hour before each of those moments.

Make the new way the easy way

People do what's easiest, and that is a design constraint, not a complaint about them. So the system delivers work where the team already looks: the qualified lead appears in the CRM, the invoice waits in the accounting approval queue, the drafted reply sits in the support inbox. There is no new place to check.

And the old route closes. If enquiries can still be handled from the spreadsheet, some will be, and the system's record will be incomplete, and the comparison will be unfair to it. Agree a date, announce it, and after that the only way to handle the work is the new way.

Tell them what happens to the hours

If a system removes ten hours from someone's week and nobody says what the ten hours are for, they'll assume the worst. Say it before launch. The hours go to the customers who were waiting, to the backlog nobody got to, to the work that needed a person all along. If that isn't true, if the honest answer is a smaller team, then say that too and plan for it, because the team will find out either way, and the system will take the blame.

The first week after launch

Here's what a good first week looks like, from the seat of the account executive whose enquiries the new system now handles. Monday morning, three new enquiries are already in the CRM when she logs in, each with the company, the region, what they asked for and a first reply drafted and waiting for her to read. She changes a sentence in one, sends all three, and is on the phone to the warmest one by half past nine. Before, those three would have been in the shared inbox, unread until someone had a gap, with the record built by hand after the first call.

Wednesday, the system gets one wrong. An enquiry from a university is routed to her as a new business lead when it should have gone to the public sector rep. She tells the operations lead, who owns the process, and by Thursday the routing rule has a line for universities. She tells her colleagues about it at the Friday stand-up, as the fix she got rather than a complaint. That is the moment the team decides the system is theirs.

Friday afternoon, she looks at the old spreadsheet out of habit. It's empty, because the route is closed. Her week had nine more conversations in it than the week before, and the first thing she asks is whether the system could draft the follow-up on the quotes she sent too.

What to do this week

1. Ask each team which single task they'd be happiest to never do again.
2. Pick the one that is also frequent, rule-based and starts from a form, an inbox or a document.
3. Name the person who does it today as the one who writes 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.

If you'd like to talk through which process your team would be glad to lose, bring the answers to the first question to a short call, and we'll tell you which one we'd build first and how we'd introduce it.