Automation people actually adopt

I've built a lot of automation: e-commerce flows, marketing automation and CRM sequences, email/SMS campaigns, training systems, and more recently LLM-assisted workflows. The most important thing I've learned is uncomfortable for engineers: automation that nobody uses has a value of zero, no matter how elegant it is.

Here's what separates the automations people adopt from the ones they route around.

Start from the annoyance, not the tool

The best automation projects start with someone sighing. "I copy this into that every single morning." "New users always get stuck on step three." Those sighs are the requirements.

When I built an LLM-assisted onboarding workflow for a trading-platform audience, the starting point wasn't "let's use AI." It was: new users have to understand a lot of tools and strategy concepts before they get value, and they were spending too long getting there. The workflow guided them through it with structured, reliable answers tailored to where they were. The result was a 35% reduction in onboarding time — because it targeted the actual bottleneck.

Fit into the path people already walk

Automation fails when it requires a new habit. It succeeds when it shows up where people already are:

• In the inbox they already check.
• In the CRM screen they already have open.
• In the chat tool the team already uses.

Our direct-sales business grew to 17,000+ customers and 400+ consultants partly because the systems behind it met people in familiar places: email, SMS, simple funnels and Facebook groups — not a shiny new portal they had to learn.

Make the output trustworthy

People stop using automation the first time it embarrasses them. One wrong name in a customer email or one nonsense answer from a chatbot can undo months of adoption. That's why I care so much about structured outputs, validation and human review for anything customer-facing. (More on structured outputs in another note.)

Keep a human-sized off switch

Every automation I build has an obvious way to pause it, override it, or do the task manually. Counterintuitively, this increases adoption. People are willing to rely on something when they know they can step in.

Train, then train again

In infrastructure projects, I retrained entire teams when we moved to new platforms. The lesson stuck: rollout isn't the end, it's the middle. Short videos, one-page guides and a few live sessions turn "a tool exists" into "the team uses the tool."

Measure adoption, not deployment

"We deployed it" is not a result. Results look like:

• Time saved per task (measured, not guessed).
• Percentage of eligible work that actually goes through the automation.
• Error or escalation rate.
• What people do when it fails — fix it, or abandon it?

The checklist

1. Start from a real, repeated annoyance.
2. Put the automation where people already work.
3. Validate outputs before they reach customers.
4. Give people a clear override.
5. Train and support beyond launch.
6. Measure usage and outcomes, not just uptime.

Automation is a product. Treat its users like customers, and they'll actually use it.