Once the team knows an AI agent is coming, a second question appears, and it is more practical than the first: what exactly will I do differently on Monday morning? A team that was told the truth about the plan but not given a clear role will still hesitate. Cases will wait because nobody is sure whether to take them over. Wrong answers will go uncorrected because nobody knows where to report them.
This article is for the team leader who has already explained the change and built trust and now has to prepare the daily work. It concerns four things: roles, the handover of a case to a person, training and feedback. The operations side, such as the runbook and escalation owner, is covered in handover to a new team.
1. Define the roles next to the agent
Before launch, write down who does what. In most small teams, three roles are enough, and one person can hold more than one.
- Case owner: takes over a case when the agent passes it on, and finishes it. Usually this is a person who already does the job today.
- Reviewer: checks a sample of the agent's work, corrects it and marks the type of mistake. In the first weeks this may be everyone; later a rotating person.
- Process owner: decides when the agent's rules change, reads the reports and talks to the vendor or the technical team. This is the person you named when you described the process.
Add one sentence per role about what the person may decide alone. A reviewer who may correct a draft answer but not change a price needs to know that boundary in advance. The EU AI Act expects people who oversee an AI system to have the competence, authority and support to do it (Article 14). The same is a good test for a small company: does the reviewer have the time and the right to say "stop"?
2. Design the handover of a case to a person
The most visible moment for customers and colleagues is when the agent says, "I will pass this to a colleague." If that moment is badly designed, the whole agent looks bad, however good the rest is. Decide three things.
When does the agent hand over? Write a short list of triggers: the customer asks for a person, the agent is unsure, the topic is on a list of excluded subjects, the same question was asked twice, a complaint or a legal threat appears, an amount is above a limit. The triggers should be simple enough for a colleague to explain.
What does the person receive? A handover without context is the most common failure. The person should see, in one place, the summary of the case, what the customer asked for, what the agent has already said or done, the documents it used and the reason for the handover. The test is simple: can the case owner continue without asking the customer to repeat anything?
Who takes it and how fast? Name a queue and a time expectation, and tell the customer what to expect. If the agent hands over at 6 p.m. and nobody looks until 9 a.m., say so in the message. Where the customer has a right to a human alternative, as discussed in what to tell customers, the route to a person must work every time, not only when the agent decides.
Try the handover with ten invented cases before launch, including awkward ones. It is the cheapest test you can run, and it often shows missing information in the summary or a queue nobody watches.
3. Train on real cases, in short sessions
Slides about "how AI works" help little with daily work. What staff need is practice with the agent on cases from their own process. A useful plan for a small team fits into three sessions of about 45 minutes.
- See it work. Show the agent on ten typical cases. Point out where it is strong and where it already fails, including the failures you found in testing.
- Correct it. Give everyone a set of cases with deliberately wrong or weak answers. People find the errors, classify them (wrong fact, missing document, wrong tone, should have been handed over) and record them in the same way they will after launch.
- Take over. Practise receiving a handed-over case, continuing it and closing it, using the handover template from the previous section.
Add a one-page guide: what the agent can do, what it must not do, how to report a problem and who to ask. Keep it where people already work, not in a folder nobody opens. The EU AI Act asks organisations to ensure a sufficient level of AI literacy among the people who operate AI systems (Article 4); practical sessions like these are a proportionate way to do it, but check with legal or HR what your situation requires.
Do not forget the people who join later. A new colleague should go through the same three sessions in their first weeks.
4. Make feedback easy and visible
Feedback often fails for two reasons: it takes too long and nothing visibly happens afterwards. Fix both.
Make it one minute. A button, a shortcut or a simple form with three fields is enough: what was the question, what did the agent say, what was wrong. A category list speeds up the sorting. If reporting requires opening a ticket system and writing an essay, people will stop after the first week.
Close the loop. Once a week, the process owner reads the reports, groups them and decides what to change: a document, a rule, a handover trigger or a vendor setting. Then they tell the team what was changed. Even one line, such as "three reports about the returns period led to a corrected document," shows that reporting matters. The operational review after launch is a natural place for this, and the reports feed the reliability checks you started before launch.
Protect the reporter. If staff think that reporting a mistake will be used against them or a colleague, the reports dry up. Say clearly that the reports are about the agent and the process, not about people. This matters especially for reviewers, who will find mistakes every day in the first weeks.
5. Talk about the fear of being replaced, with facts
The concern did not disappear after the first announcement. It returns with every new feature, every budget meeting and every article about layoffs. What helps is not reassurance but concrete information that you update.
- Say which tasks move to the agent and which stay with people, in terms of hours per week if you can measure them.
- Say what the freed time is meant for. If the answer is "more complex cases and quality", show it in the work plan, not only in a speech.
- Say what you do not know. If the plan may change after a year, say that you will tell the team before it does.
- Offer people a real route to the new roles. A person who becomes the reviewer or process owner gains a skill that the team will need as long as the agent runs.
Do not promise outcomes that depend on decisions above your level. Promise what is in your hands: honest information, training, a say in the pilot and a heads-up before any change. Research on workplace change, such as the Prosci ADKAR model, treats ability and reinforcement as steps separate from awareness, which is exactly what roles, training and feedback provide. See also change management for technology adoption.
6. Start small and check readiness before launch
A staged rollout gives the team time to learn. In the first phase the agent prepares drafts and people send them. In the second it works alone on simple cases and hands the rest over. In each phase check whether the people are ready, not only the technology.
Questions for the team leader before each phase:
- Does everyone know their role and what they may decide?
- Have we tested the handover with awkward cases?
- Have all affected people completed the practice sessions?
- Can anyone report a wrong answer in under a minute?
- Who reads the reports, and when?
- Does the team know what we will do if the agent has to be switched off?
A short checklist
- Name the case owner, reviewer and process owner, and write what each may decide.
- Define the triggers for handover to a person and the information that goes with a case.
- Name a queue and a time expectation, and tell the customer.
- Hold three short practice sessions on real cases and write a one-page guide.
- Set up one-minute reporting and a weekly review that tells the team what changed.
- Update the answer to "will I be replaced" with facts whenever the plan changes.
- Check people's readiness before each phase of the rollout.
A team that knows its role, can take over a case without asking the customer to start again and sees its feedback change something will make the agent better. A team left without these will work around it, quietly, and you will not see why the results are poor.
