Your team and an AI implementation: how not to lose people along the way
AI implementations rarely fall over on the technology. They fall over when the team that is supposed to work with the system hears about it in an email a week before launch. This piece is about the part of the project you cannot outsource — we can prepare the agent, but someone inside the company has to have the conversation with the team. Below is what we see in projects that went well, and in the ones that stalled.
- Resistance comes from uncertainty about your own role, not from dislike of technology.
- A team that sets the escalation rules becomes a co-author of the implementation instead of its subject.
- Silence from management on the subject of headcount gets read in the worst way possible.
Where resistance comes from
Almost never from a belief that the technology is bad. Almost always from one question nobody asks out loud: will I still be needed here after this. As long as it hangs there unanswered, every request for help mapping a process sounds like a request to prepare your own replacement — and people respond exactly as you would expect: in generalities.
That has direct consequences for the design. The knowledge of where the exceptions sit in a process lives in the team and nowhere else. If the team does not hand it over, the escalation rules get built from the official process description, which is always tidier than reality. You see the result in week three of the pilot, as a run of situations "nobody expected".
Four things worth saying early
What happens to jobs. Whatever the answer is, saying it plainly beats saying nothing. An information gap gets filled with the worst-case scenario, and at that point cooperation ends before the project starts.
Which process, and only that one. A narrow, named scope reassures people more than assurances do. "We are starting with B2B returns, nothing else changes" is checkable; "we are improving customer service" is not.
Who approves the agent's decisions. Knowing that a human has the last word in disputed cases turns the system from a threat into a tool. Show it on a concrete example rather than stating it as a promise.
What the team does with the time it gets back. If the answer is "the same, only more of it", the implementation will win no allies. If it is work nobody currently has time for, name that work in advance.
The cheapest change you can make to an automation project, and at the same time the one that most affects the quality of the escalation rules — because knowledge of the exceptions is not documented anywhere else.
Training: short, but mandatory
Beyond the practical reasons, there is a regulatory obligation here: Article 4 of the AI Act requires companies to see to AI literacy among the people operating the system. In practice, a short session for the team working with the agent, documented with an attendance list, is enough. The content is simple: what the system does, what it does not do, how escalation works, and who to report wrong answers to.
That last point matters more than it looks. A team with a clear, fast route for reporting the agent's mistakes will catch more of them in the first month than any monitoring will — provided the reports actually change the rules. If they do not, the reports stop after two weeks and come back only as the sentence "it does not work anyway".
Frequently asked questions
When should you tell the team about the implementation?
Before the audit, not before the pilot. The audit requires conversations with the people running the process anyway, so word will get out regardless — better it comes from you with full context than from the corridor.
What if the implementation really does mean cuts?
Then say so plainly and early, rather than promising nothing will change. The team will spot the gap between the statement and reality before the pilot ends, and it is that gap — not the cuts themselves — that destroys trust in the projects that follow.
Do you run the training?
Yes, it is part of the implementation and usually takes one session. The conversation about roles and jobs has to come from someone inside the company, though — that is not a part you can hand to a vendor, and attempts to do so are visible from a mile off.