Inside this article
- A handover works when it is planned from the first day: how much your team will run itself is named before the build starts.
- Your team should receive documentation, training on the workflows they now use, and a handoff packet for each part they take over.
- You do not have to take everything. Ownership can be decided part by part, with the rest kept as a managed service.
An AI workflow that only its builders can change is a dependency. It may work well today, but the first time the process shifts or a vendor changes a field, someone has to call the people who built it.
Most leaders in the IT channel know this from other projects, which is why "can we run it ourselves?" comes up early in any AI conversation. The answer should be yes, to whatever extent you choose. This article covers what a good handover contains, who should receive it and how to tell when your team is ready.
When should the handover be planned?
At the start. The handover is one of the things worth naming before any work begins, alongside the workflow, the system of record, the measure and the governance.
There is a practical reason. If your team is going to change the workflow's rules themselves, they need to be in the working sessions where those rules are set. If they are going to look after a connection, they need to see it built. Deciding this at the end means teaching it all again from the beginning.
In a PRESHai implementation, how much your team will run itself is named on day one. It can be a rough answer. "We want to own the daily running and decide about the rest later" is enough to shape who attends what.
What should your team receive?
Four things make up a handover.
Documentation. What was built, how it works and how to change it, written for the people who will run it. The test of good documentation is whether the workflow owner can follow it without an engineer in the room.
Training. Sessions on the workflows your team now uses, on real work. General AI training has its place, but it does not teach a dispatcher how to review this agent's routing proposals.
Handoff packets. For each part you take over: what it is, who owns it and what to watch. A workflow has several parts, such as the agent's rules, the connections, the approvals and the reporting. Each one gets its own packet and its own named owner.
A choice of scope. You decide how much you run yourselves. The training and adoption page describes how this works in the Transfer phase.
Who on your team should take it over?
Start with the workflow owner, the person who answers for the work the workflow does. They have been deciding things since the first phase, so they already know why it behaves the way it does.
Beyond the owner, think about three kinds of responsibility and put a name to each.
Someone approves the work day to day. This is usually the people who did the task before: technicians, coordinators, reps. Their job has changed from doing the work to checking it.
Someone can change how the workflow behaves. When the escalation rule changes or a new service line is added, this person updates the workflow. It is often the owner or a team lead.
Someone looks after the connections. This is usually whoever administers the systems involved, such as the PSA or CRM administrator.
In a smaller business, one person may hold two of these. That is fine, as long as each has a name and a backup.
How should the team be trained?
On their own workflow, with their own cases.
Adoption comes from the workflow itself. When AI is built into the work, the work arrives done and ready for review. The habit your team needs is checking and approving it. That is a much smaller change than learning to prompt an assistant from a blank box, and it is the habit training should build.
Take a service desk where an agent now proposes the type, priority and queue for each new ticket. Training for dispatchers covers how to read a proposal, what a good one looks like, when to reject, and what feedback helps. Training for the service desk manager covers how to read the record of runs, how to spot a pattern in rejections and how to change a rule.
Managers need one more thing: a view of who is using the workflow and where it is being bypassed, so they can follow up.
Do you have to take over everything?
No. Ownership can be decided part by part.
The split above is one example. The team owns daily use and approvals, and the workflow owner makes changes to rules and wording. Upkeep of the connections and the regular reporting and governance reviews stay with a managed service.
That split suits teams that know their process well and have little spare engineering time. A business with a strong internal IT team might take the connections too. A business in the middle of a busy period might take only the daily approvals for now and revisit the rest later.
The point is that the question has more than two answers. "Do we run it or do they?" is too coarse. Ask it for each part.
How do you know your team is ready?
Try a few checks before you call the handover done.
- Can the workflow owner explain, without notes, what the agent may read and change and what needs approval?
- Can someone on your team make a small change to the workflow and see it take effect?
- Can someone find the record of a specific run and say what happened in it?
- Does everyone who approves work know what to do when a proposal looks wrong?
- Is there a name against each part, and does each person know what to watch?
If the answer to any of these is no, that is where the next training session goes. A handover is complete when the people who run the workflow can change it without asking the people who built it.
What happens after the handover?
The workflow keeps changing, because the business around it does. Vendor systems change their fields and sign-in. The tools gain new abilities. Your own process moves.
Someone has to keep up with that. If your team has the time, the documentation and handoff packets give them what they need. If not, this is what Managed AI is for. It is an ongoing service: each month includes a new workflow, reporting on usage and results, a strategy briefing on what is new and what to do next, and training sessions that keep your people current.
Either way, training does not stop at handover. New people join, and the workflow they learn should be the current one.
Where to start
If a build is ahead of you, decide now who will own each part afterwards and put them in the room from the first session. If a workflow is already running and only its builders can change it, list its parts and ask who on your team could take each one.
To talk it through, tell us who would own the workflow. We will go through what they need to run it and extend it, and how we work shows where handover sits in the full process.
