How to Prepare Your Team Before You Automate Anything
MIT Project NANDA studied enterprise AI adoption in 2025 and found that roughly 95 percent of generative AI pilots produced no measurable business return. The useful part is the explanation. The shortfall was attributed to how organizations adopted the tools rather than to model quality, and generic deployments did worse than systems built into one specific workflow.
That is a people finding, not a technology finding.
If you have decided to automate something, and you may already know which process, most of what decides the outcome happens before anything is built. Preparing your team for AI comes down to six moves: document the process as it runs today, tell the people who run it what is changing and why, answer the replacement question out loud, name one owner for the transition, run the old and new versions side by side for a fixed period, and measure the number you said you would measure. Each one is below.
The system nobody uses
Almost every business has bought something that now sits idle. A CRM with three fields filled in. A project tool two people log into. A scheduling system everyone works around by texting each other instead.
The software usually worked. Nobody was told why it existed, who it was supposed to help, or what it replaced, so the team kept doing the job the way they already knew how. The rollout failed, not the tool.
Automation raises the stakes on that pattern. An automated workflow only produces value when the work actually flows through it, and a process people quietly route around is wasted money plus a second, invisible process running beside it.
Document the process before you change it
Not a flowchart. A plain written description of who does what, in what order, and where the work passes from one person to another.
Write down:
· Every step, in the order it happens
· Who performs each step
· What triggers the next step: an email, a signature, a phone call, or someone noticing
· Where the work waits, and what it is waiting on
· What gets retyped from one system into another
· What happens when something goes wrong, and who handles it
If nobody has written this down, automate nothing until someone does.
Automating an undefined process produces a faster version of the same mess, and it strips out the informal judgment that was quietly holding the undefined parts together.
The person to write it is the person who does the work, not the owner's memory of it. The step everyone describes as routine is usually the one with three exceptions nobody wrote down.
Tell the team what is changing and why
Not a presentation. A conversation, held before the build starts, covering three things.
The specific task being automated. Name it in plain terms. "The reminder emails we send when a signed document has not come back" is a task. "Digital transformation" is not.
What the team stops doing, step by step.
What the team keeps doing. This is the half that gets skipped, and it is the half people are listening for.
Have the conversation early. If the first time your staff hears about the project is the day it launches, they will assume it was designed around them rather than with them, and they will be partly right, because nobody asked them what the process actually involves.
Answer the replacement question directly
Everyone in the room is thinking it and most will not say it out loud: is this replacing me?
Answer it early and answer it plainly. Automation handles the repetitive steps: the reminders, the routing, the information moving between systems, and the assembly of the same document in the same format every cycle. The person handles the judgment, the exceptions, and the relationship with the customer.
Then say what the recovered hours are for. If the same team will handle more volume without adding people, say that. If someone spending three hours a week copying data between systems gets those hours back for work that needs a person, say that. Vagueness here reads as bad news, and the team will fill the silence with the worst version of it.
Pick one person to own the transition
One person on the team. Not the vendor, not whoever happens to sit closest to IT, and not a committee.
The right person knows the current process well enough to notice when the automated version behaves differently, and they should be the first user rather than the supervisor of users. During the transition their job is to test it, report what breaks, and become the person everyone else asks before they ask you.
Give them room for it. A transition added to a full workload becomes the thing that slips.
Run the old process and the new one side by side
For a defined period. Two weeks, four weeks, one full billing cycle, whatever matches the rhythm of the work. Set the end date before you start.
Running both is how you find the cases nobody mentioned: the customer who gets a different version of the document, the exception the office manager has handled by hand for years, the step that only happens in the last week of the quarter.
The end date matters because parallel running is two processes doing one job. Without a date it becomes permanent, which is how a business ends up paying for automation while still doing the work by hand.
Measure the number you said you would measure
Before the build, write down the number that should change and what it is today. Days to complete. Items sitting unfinished while they wait on someone.
Hours per week spent on the task. How often the step gets missed entirely.
Check it at the end of the parallel period, then again ninety days later.
This is the discipline the NANDA finding points at. A pilot with no baseline cannot show a measurable return, because there was never anything to measure against. If you are still deciding which process to take first, which business processes to automate first (https://www.prismagentsolutions.com/blog/business-processes-to-automate-with-ai) covers how to rank them. If you are weighing whether you need a tool or an advisor, the difference between AI tools and AI consulting (https://www.prismagentsolutions.com/blog/ai-tools-vs-ai-consulting) works through that decision.
What this looks like in one real workflow
The pattern is clearest where the same sequence repeats with every client. In an accounting practice, the document chain runs from the signed engagement letter through the information request list to the recurring monthly deliverable, and the same handoffs happen on every engagement. Automating that chain is not mainly a software question. It is a question of whether the team agrees on what the steps are and who owns each one. The document chain inside an accounting firm (https://www.prismagentsolutions.com/blog/ai-automation-for-accounting-firms) walks through one version of it end to end.
Your version will use different documents. The preparation is the same.
Where to start
Pick the process you were already thinking about. Write it down as it runs today, in order, with the handoffs marked. Show that description to the person who does the work and ask what you got wrong. Then decide the single number that should be different in ninety days, and record what it is today.
That is the readiness step, and it costs a conversation and an afternoon rather than a budget.
If you want a second set of eyes on it, a free AI assessment starts with how your business actually runs and what your team currently does, before any system is designed or recommended. The version worth building is shaped around your workflow rather than pulled off a shelf.
Frequently asked questions
How do I get my team on board before we automate a process?
Bring them into the description of the current process before any decision is announced. The person doing the work will name constraints an owner cannot see from the outside.
What should I document before bringing in automation?
Step order, the owner of each step, the trigger that starts the next one, the waiting points, the information retyped between systems, and how exceptions get handled. If any of those is unclear to you, it is unclear to an automated system too.
How long does it take for a team to adjust to a new automated workflow?
Plan a defined parallel period rather than a fixed adjustment time. Two to four weeks, or one full cycle of the work, is a common window.
What if my staff resists the change?
Resistance is usually specific rather than general. Ask what they think will break. The answer often names a real gap in the design, and gaps are cheaper to fix before launch than after.
Do I need to train everyone on the technology, or just the people who use it?
Train the people who touch the workflow. Everyone else needs to know what changed, who owns it, and where the work goes now.
