You built a few automations. They work. You're saving hours every week. You feel like you've discovered fire, and now you want to share it with the whole village.
We get it. We've been there. And we've watched the next part play out at dozens of companies: the enthusiastic automation champion charges into a team meeting, pulls up their Zapier dashboard, starts demoing triggers and actions, and watches everyone's eyes glaze over within three minutes. Two weeks later, nobody's using any of it, and the champion is quietly resentful.
Automation adoption is an organizational challenge, not a technical one. The building part is actually the easy part. Getting a team of humans to change how they work? That's where things get interesting. This post is about how to do that without burning out, alienating your colleagues, or becoming the company's unpaid integration helpdesk.
The Overeager Champion Problem
Before we get into what works, let's talk about what doesn't. Because odds are good you're about to make this mistake (or you've already made it).
▶💬The overeager champion: A cautionary pattern
The pattern goes like this: someone on the team discovers automation, gets excited, and builds 20 Zaps over a weekend. They automate the team's email notifications, the CRM updates, the project creation flows, the invoice reminders, the Slack alerts. They wire everything together in a frenzy of productive enthusiasm.
Monday morning, they proudly announce to the team: "I automated a bunch of stuff this weekend!"
The team's reaction is not what they expected. Instead of gratitude, they get confusion. "Wait, why am I getting these Slack messages now?" "Who changed how leads get added?" "I was in the middle of updating that process and now there's an automation running on the old version." "This thing just created a duplicate contact for a client I already set up."
Here's what went wrong: the champion automated processes that belonged to other people without involving those people. They optimized for technical efficiency and ignored organizational reality. And they built 20 things that only one person understands, which means they've just created 20 new single points of failure.
We've seen this exact scenario at least a dozen times. The aftermath is always the same: the team loses trust in the automations, the champion gets frustrated that nobody appreciates their work, and half the Zaps get turned off within a month. It's not that the automations were bad. It's that the rollout was backwards.
(If this sounds like we're speaking from personal experience, it's because we are. We made this exact mistake early in our career. Built a beautiful set of automations for a team that didn't ask for them. Learned the hard way that "technically correct" and "organizationally useful" are different things.)
Start With Their Pain, Not Your Enthusiasm
The single most effective way to get someone interested in automation is to solve a problem they already know they have. Not a problem you've identified for them. Not a problem that's theoretically important. A problem they complain about regularly.
Don't lead with "let me show you Zapier." Lead with "you know that thing you hate doing every Friday? The one where you export the CSV from QuickBooks, clean it up in Excel, and then paste it into the report template? What if that just happened automatically?"
That's a different conversation. The first version is about technology. The second version is about their time, their frustration, their Friday afternoon. People don't care about automation as a concept. They care about getting two hours back.
This is core belief #1 from the SMB playbook: automation is an economic decision, not a moral one. You're not trying to convert people to a philosophy. You're trying to show them a concrete return on a specific investment of their attention. Frame it that way and you'll get a lot further than any demo ever will.
Find Your Champions (You Only Need One or Two)
You don't need to train everyone. Not yet, anyway.
Look for the people on your team who meet two criteria: they're curious, and they're frustrated. Curious means they're willing to try something new. Frustrated means they have a problem worth solving. The combination of those two things is rocket fuel for adoption.
You probably already know who these people are. They're the ones who say things like "there has to be a better way to do this" or "I wish these two systems talked to each other." They might not know what automation is, but they know they're tired of manual work.
Invest in those one or two people heavily. Sit with them. Help them build their first automation. Let them pick the workflow (their problem, not yours). Walk them through the logic. Let them click the buttons. When it works, let them own it completely.
Here's why this matters more than an all-hands training session: peer influence beats top-down mandates every time. When Sarah in accounting tells Mike in sales "I automated my invoice reconciliation and it saves me two hours a week," Mike pays attention in a way he never would if that message came from a company-wide email or a mandatory training session. Sarah is credible because she's a peer dealing with similar kinds of frustrations. A training deck is not credible. It's homework.
The Show, Don't Tell Approach
We've sat through plenty of automation demos. Most of them go like this: someone opens the platform, shows the workflow editor, explains what triggers are, explains what actions are, walks through field mapping, and by minute seven the audience is mentally composing their grocery list.
Here's what works instead: build one automation that saves one person two hours a week. Don't explain how it works. Just turn it on. Let them experience the result.
That moment of "wait, it just does that now?" is the most powerful sales tool you have. It's visceral. It's immediate. And it requires zero understanding of the underlying technology. The person doesn't need to know what a webhook is. They just need to know that the thing they used to do manually now happens by itself.
After they've experienced the benefit for a week or two, they'll come to you with questions. "How does it work?" "Can it also do this other thing?" "What if I wanted to add a step?" Now you have a willing student instead of a captive audience. That's a completely different teaching dynamic.
▶📋Real example: Property management ticket routing
One client we worked with had a property management team that was manually creating maintenance tickets in three different systems every time a tenant submitted a request. We automated it so the request flowed into all three systems automatically. The operations manager didn't need a training session. She needed one week of watching tickets appear in the right places without her touching anything. After that, she was asking us to automate five more processes. She sold the rest of the team on it better than we ever could have.
Handling Resistance (And It Will Come)
Not everyone will be excited. That's normal and healthy, actually. Skepticism about new systems is a survival mechanism in most organizations, because they've all been burned by the last "this will change everything" initiative that quietly died six months later.
Here are the objections you'll hear and how to handle them honestly:
"I don't trust it." Fair. You shouldn't trust it blindly either. The answer here isn't "trust me, it works." The answer is "let's verify together." Show them the run history. Let them spot-check the output against what they'd have done manually. Give them a week of parallel operation where the automation runs but they also do it the old way, so they can compare. Trust is built through evidence, not promises.
"What if it breaks?" It will break. Everything breaks eventually. The question isn't whether it will break but what happens when it does. Show them the error notifications. Show them how the platform alerts you when something fails. Show them the retry logic. And be honest: "When it breaks, here's who gets notified, here's how we fix it, and here's the fallback process in the meantime." That's a much more reassuring answer than "don't worry, it won't break."
"I could just do it myself." Yes. You could. The question is whether you should. This is a good moment to do some napkin math together. "This task takes you 15 minutes and you do it 20 times a month. That's five hours. Over a year, that's 60 hours. Is this the best use of 60 hours of your time?" Sometimes the answer is actually yes (if the task requires real judgment that the automation can't replicate). But usually, the math speaks for itself.
"This is going to replace me." This one deserves a real answer, not a dismissive one. Automation replaces tasks, not people. But we understand why it feels threatening. The honest response is: "This takes the repetitive parts off your plate so you can spend more time on the parts of your job that actually need your brain. The company still needs you. It just doesn't need you doing data entry." If someone's entire job is the repetitive task being automated, that's a bigger organizational conversation that goes beyond automation tools.
A Training Framework That Actually Works
If you do get to the point of formal training (and you should eventually, once you have some wins under your belt), here's a framework that respects people's learning curves:
Phase 1: Awareness. This isn't a hands-on session. It's a 15-minute conversation about what automation is, what it can do, and (critically) what it can't. Show two or three examples of automations already running in the business. Keep it concrete. "This Zap watches for new deals in HubSpot and creates project folders automatically. It's been running for three months and has saved the ops team about 10 hours a month." That's it. No tool demo. No jargon. Just outcomes.
Phase 2: Observation. Pair someone with an existing automation and let them watch it work for a week or two. They can see the triggers fire, the actions execute, the data flow through. They start to develop an intuition for what's happening without having to understand the mechanics yet. This phase is underrated. Most training skips straight from "here's what it is" to "now build one," and people aren't ready for that jump.
Phase 3: Participation. Now they build something, but not from scratch. Take an existing automation and ask them to modify it. Add a field. Change a filter. Add a notification. They're working within a known structure, which is much less intimidating than starting with a blank canvas. Sit with them the first time. Let them drive while you navigate.
Phase 4: Ownership. They identify a workflow they want to automate, map it using the napkin method, and build it themselves. You're available for questions but you're not building it for them. This is the moment they cross over from "automation consumer" to "automation builder." It doesn't happen on a schedule. Some people get here in two weeks. Some take two months. Move at their pace, not yours.
Setting Boundaries (Or: How to Not Become Unpaid IT)
This section might be the most important one in this post, because we've watched the absence of these boundaries destroy people's enthusiasm for automation entirely.
If you're the person who built the automations, you will become the default troubleshooter for every automation-related issue in the company. "Hey, this Zap stopped working." "Hey, I'm not getting that notification anymore." "Hey, can you add a step to send me a copy of that email too?"
Individually, each request is small. Collectively, they'll eat your entire week.
Establish ownership early and clearly. The person who uses the automation should understand how it works at a basic level, how to check if it's running, how to identify common errors, and when to escalate. Write this down. A shared doc with "here's what this automation does, here's how to check on it, here's what to do if it breaks, here's when to call me" will save you hours of interruptions.
You are not IT. You are not on-call. You are a colleague who knows how to build automations, and you're willing to help, but the person who benefits from the automation needs to take some responsibility for it. If you don't set this boundary, two things happen: you burn out, and nobody else ever learns to manage their own workflows. Both are bad.
A practical structure that works well: the automation builder trains the automation user, writes basic documentation, and does a handoff. After that, the user is responsible for day-to-day monitoring and basic troubleshooting. The builder is available for escalations (things that are actually broken, not just confusing) and new build requests. This mimics how IT support works in most organizations, and for good reason.
Building the Habit Organizationally
Individual adoption is great. Organizational habit is where the real leverage lives.
The simplest thing you can do: a standing 15-minute "automation check-in" every week or two. It doesn't need to be a big deal. Three questions:
- What's working? (Quick wins to celebrate and reinforce)
- What's broken or flaky? (Surface issues before they become crises)
- What should we automate next? (Keep the pipeline alive)
That's it. Fifteen minutes. Put it on the calendar. Make it part of the team's rhythm, not a special event. The companies we've seen get the most value from automation treat it as an ongoing practice, not a one-time project. We talked about this in the playbook and it's just as true at the team level as it is at the company level.
The other thing worth doing: keep a running list (a shared doc, a Slack channel, a column in your project management tool) of "things people wish were automated." When someone says "ugh, I wish this just happened automatically," write it down. That backlog is your roadmap. And because the requests come from the people doing the work, they're almost always higher-value than anything you'd come up with sitting in a room by yourself.
What Good Looks Like
Six months from now, here's what success looks like:
Two or three people on the team can build simple automations without help. There's a shared understanding of what's automated and what isn't. New automation ideas come from the team naturally, not from you pushing. Broken automations get noticed and fixed within a day or two, not discovered six weeks later. And you're not the bottleneck anymore.
That last point is the real goal. If you're still the only person who can build, modify, or troubleshoot automations, you haven't trained your team. You've just made yourself indispensable in a way that doesn't scale and will eventually make you miserable.
The best automation champions work themselves out of the job. They build the capability, transfer the knowledge, set up the processes, and then go find the next thing that needs fixing. That's the pattern. That's what you're aiming for.
This post is part of The SMB Automation Playbook, a series on practical automation for small and mid-size businesses.