How do I get my team to actually use a new automation?

The automation works. It was tested, it runs, and the run history is green. Yet three weeks later the team is still sending the welcome email by hand, double-checking every record it creates, and keeping the old spreadsheet open "just in case". The hours it was meant to save never show up.

The short answer: people rarely ignore an automation because they dislike technology. They ignore it because they cannot see what it did, they were burned once when it got something wrong, nobody told them who to ask, or the old way is still easier. Adoption comes from making the automation visible, owned, documented and trusted, and from closing the old path once the new one is proven.

Why teams quietly work around automations

Most workarounds come from one of these:

• They cannot see it working. If the only proof is a log in a tool nobody else opens, people assume nothing happened and do the task again.
• One bad run. A single wrong email to a client or a duplicate record is remembered far longer than fifty correct runs.
• It changed their job without asking. The person who used to do the task was not consulted, so the automation misses a step they always did and never wrote down.
• The old path is still open. The template, the spreadsheet and the manual checklist are all still there, and habits win.
• Nobody owns it. When something looks wrong, there is no one to ask, so people protect themselves by doing it manually.

Each of these has a practical fix.

Involve the people who do the work before you build

The person who does a task every day knows the exceptions: the client who must never get an automated email, the form field everyone ignores, the step that only applies to new matters. Before anything is built:

1. Sit with them while they do the task and note every step, including the ones they do not think of as steps.
2. Ask what would make them trust it. Often the answer is simple: "I want a copy of every email it sends for the first month."
3. Make one of them the pilot user. Someone from the team who helped design it is a far better advocate than a manager announcing it.

This is also where you decide what the automation will not do. Leaving a judgment call with a person, and saying so, builds more trust than automating it badly.

Give every automation one owner

Each automation needs one named person who checks it is running, answers questions and decides on changes. It does not have to be the person who built it, and it should not be the managing partner by default. It should be someone close to the process who will notice when the output looks wrong.

Write the owner's name in the runbook and in the automation's description inside the tool. When that person leaves or changes role, the owner changes too; our article on what happens to automations when an employee leaves covers the handover steps.

Write a one-page runbook

A runbook is a short note, kept where the team already looks (your intranet, shared drive or handbook), that answers six questions:

1. What does it do? One sentence: "When a new client signs the engagement letter, it creates the client folder and sends the welcome pack."
2. What starts it? The trigger, in plain words.
3. What will you see? The record, email or task it creates, and where.
4. What should you not do any more? The manual steps it replaces.
5. What if it looks wrong? Who to tell, and the manual fallback in the meantime.
6. Where is the history? The tool and the account it runs under.

On the last point, run history is not kept forever. Zapier, for example, says it can guarantee a maximum of 60 days of run data in Zap history, according to its help article on Zap history as published in October 2026. If you need a longer record, the runbook should say how and where it is exported.

Make failures visible to the right person

Trust breaks fastest when an automation fails silently and a client notices before you do. Every platform can alert someone; the job is to make sure the alert reaches the owner, not a former employee's inbox or a mailbox nobody reads.

• Zapier sends error notifications to the account email by default, with options for immediate alerts, an hourly summary or both, and Pro, Team and Company plans can set notifications Zap by Zap, according to Zapier's notification settings guide as of October 2026.
• Make emails users about errors and about scenarios it has deactivated because of errors, then follows up with a digest for repeat issues; preferences are set per organization in your profile, according to Make's email preferences guide as of October 2026.

Route alerts to the owner and, if your team uses one, a shared channel where a second person can see them. Then tell the team that alerts exist. Knowing that a failure will be caught makes people far more willing to stop checking by hand. Our guide to why Zapier automations keep breaking lists what usually triggers those alerts.

Close the old path, but keep a fallback

Once the pilot has run cleanly for a couple of weeks, remove the temptation:

• Archive the old email template or move it somewhere less convenient.
• Make the old tracking spreadsheet read-only.
• Remove the replaced steps from checklists and onboarding notes.

Do not remove the ability to do the task manually altogether. Keep a short written fallback in the runbook for when the automation is down, so people are not stuck, and so the fallback is used deliberately rather than by habit.

Launch small and show the result

• Start with one team or one client type rather than the whole firm.
• Send a short note at launch: what changes, what stays the same, who owns it, where the runbook is.
• Report back after a month. How many runs, how many errors, and roughly how much time the team spent on the task before and after. Real numbers from your own firm convince people more than any vendor claim.
• Act on complaints quickly. A small fix made within days shows the automation is maintained, not abandoned.

Check in at 30 and 90 days

Ask the people who use it three questions: what still feels manual, what they do not trust, and what they would change. Then look at the run history for steps that are repeatedly skipped or edited by hand afterwards. Both point to the next improvement.

How Flow Mesh helps

Our stack audit reviews the tools and automations you already have, gives each tool a verdict (keep, configure, consolidate or replace), and sets out a written scope that names an owner for every flow. Builds are quoted in writing after the audit and done inside your own accounts, and training and support covers the runbooks and team sessions that get automations used.

Key takeaways

• People work around automations they cannot see, do not trust or were not consulted on.
• Involve the person who does the task before building, and make them the pilot user.
• Give every automation one named owner and a one-page runbook the team can find.
• Send failure alerts to the owner and tell the team they exist, so nobody checks by hand.
• Close the old path once the pilot is clean, but keep a written manual fallback.