I have been watching businesses approach AI automation for long enough to notice a pattern. Most of them are solving the wrong problem. They are chasing the big integration, the impressive architecture, the full-stack AI transformation. Meanwhile, the things that would actually move the needle sit ignored because they do not photograph well for a case study.
This is my current thinking on what is genuinely underrated, drawn from running sendXmail, ZOPPLY and HOT Leads, from teaching at Harbour.Space University, and from watching both clients and students make the same mistakes at different speeds.
Underrated AI Automation Explained
The small things are where the time actually goes
The automation projects that get attention are always the ambitious ones. The AI agent that handles the entire sales pipeline. The workflow that connects twelve platforms and triggers forty actions from a single form submission. These make good slides at conferences.
The projects that actually recover meaningful time are usually far less photogenic. For example, a two-step automation that removes a copy-paste task someone does forty times a day. A simple trigger that routes incoming enquiries to the right folder without anyone touching them. A template that auto-populates a document that used to take fifteen minutes to format by hand.
Admin work is where most organisations lose the most time. It is also where most organisations have the least appetite for automation, because fixing admin is not a strategic initiative. Nobody gets promoted for eliminating a manual data-entry step. But if that step happens 200 times a week across a team of 10 people, the compounded savings are substantial. It just does not appear in a boardroom presentation, so it gets deprioritised in favour of something that sounds more significant.
This is a mistake. The unglamorous automations are often the highest-return ones precisely because nobody is competing to build them.
The “broken” workflow that is not broken
There is a design pattern in automation that almost nobody talks about, and it is one of the more interesting things I have started emphasising with clients and students. It is the deliberate human-in-the-loop workflow, where the human is not a fallback for when the automation fails but a design choice built into the architecture from the start.
The idea is straightforward. You split the workflow according to what each component does best. The automated and AI-driven parts handle the structured, repeatable, rules-based work: data extraction, formatting, routing, classification, first drafts, and summaries. The human handles the judgment calls, the creative decisions, and the contextual reading of a situation that a model cannot reliably do.
The human is not there to fix the machine, but rather because some things genuinely require a person, and pretending otherwise produces worse outputs. What you end up with is the operational consistency of automation combined with the taste, creativity, and judgment of someone who actually understands the context. That combination outperforms either component running alone.
I have seen this work in content production, in client communication workflows, in reporting pipelines. The workflows look incomplete to someone expecting full automation. That apparent incompleteness is, in fact, the design. The seam between the automated output and the human edit is where the real value lives. 🙌
Automating everything is not the goal
This one is more contentious, and I will say it directly: trying to automate everything is one of the bigger strategic errors I see professionals and businesses making right now. [READ THIS AGAIN] 😉
The right question is “should this be automated?”
What belongs in an automation or AI workflow is anything that is fundamentally defined, repetitive, and rules-based.
- Copying data between systems…
- Formatting reports…
- Sending sequences of messages according to known triggers…
- Classifying inputs that follow predictable patterns.
This work is genuinely better handled by a machine, and delegating it frees up time for things that actually require a person.
What does not belong in an automation is the work that requires judgment, creativity, contextual understanding, or relationship. And here is the part that rarely gets said clearly enough: keeping humans involved in that work is not just about producing a better output, but about keeping the human sharp.
Every task you automate away is a task you stop learning from.
If you delegate the writing entirely, you stop developing your thinking.
If you delegate the analysis entirely, you stop developing your instincts about the data.
If you delegate the client communication entirely, you stop developing your read of what clients actually need.
Over time, the professional who has automated everything becomes dependent on the automation, lacking the underlying skill to correct it when it goes wrong, improve it as the context changes, or replace it when it fails.
The people who will remain valuable over the next decade are those who have used automation to free up time for the work that develops them, while staying actively involved in the decisions and outputs that shape their expertise.
Automate the boring.
Protect the learning.
Tool anxiety is a productivity killer dressed up as diligence
The pace at which AI and automation platforms are adding features is, by any honest measure, difficult to keep up with. I use HeyGen and Veed.io for video work, and both have added more capabilities in the past 12 months than most platforms do in 3 years. The same is true of Make, n8n, and every AI platform worth naming. New features, new models, new integrations, new use cases, continuously.
The response I see most often to this pace is anxiety. A feeling that you are perpetually behind, perpetually missing something important, perpetually not yet ready to start because the landscape has changed since you last looked. This anxiety drives people to spend time learning features they will never use, following every product update, and feeling vaguely inadequate for not being across all of it.
It is the wrong response to the right observation. Yes, the platforms are evolving fast. No, you do not need to understand every feature. What you need is clarity about what you are trying to accomplish, and then the discipline to find the most direct path to that outcome using the tools available right now.
Most of what gets added to these platforms is not relevant to any given use case. The relevant parts become obvious when you approach tools with a specific goal rather than a general intention to stay informed.
The goal comes first. The tool serves the goal.
Everything else is noise, and treating noise as a signal is a reliable way to stay busy without making progress.
Automate what is already working, not what you hope will work
This is perhaps the most practical thing I can offer, and it comes directly from my approach to automation in my own agencies.
I do not automate a process until I am satisfied with how it works manually. Not until I have run it by hand enough times to know what the edge cases are, what breaks it, what the output looks like when it is good and when it is not, and what judgment calls it requires that are not obvious from the outside.
When I reach the point where the manual version is working consistently, and I am confident in what it produces, that is when I start looking at how to automate it.
By that point, I know exactly what the automation needs to do. I know the inputs, outputs, decision points, and exceptions. I can design something specific to the actual process rather than adapting a generic template to approximate it. And because the manual version is already producing good results, the automated version has a clear benchmark to meet.
The alternative, which is to automate a process you have not yet validated, is to build something that runs fast and consistently in the wrong direction. Speed of execution is not a virtue when the underlying process is uncertain. The automation does not fix the uncertainty, but industrialises it.
This is what I mean when I talk about the Manual First approach.
Get the process working. Get comfortable with it. Understand it well enough to explain every step.
Then build the automation around that understanding, and you will find that the tool selection, the design choices, and the troubleshooting all become considerably simpler. You are no longer trying to figure out what the process is while simultaneously figuring out how to automate it. You already know the answer to the first question, and the second becomes much more tractable.
What this looks like in practice
None of this is a framework with steps and a certification, but rather a sequence of questions worth asking before touching any platform.
Is the process I want to automate actually working? If not, fix it first. Automation will not repair a broken process; it will make the breakage happen faster and on a greater scale.
Am I trying to automate this because it genuinely warrants it, or because it looks impressive? The unglamorous two-step automation that removes a daily friction point is worth more than the complex agent architecture that nobody actually uses.
Where does human judgment belong in this workflow? If the answer is nowhere, check again. Most processes have at least one point where a person’s read of the situation makes the output significantly better. Design that in deliberately rather than treating it as a limitation.
What am I keeping for myself, as a professional? The work that develops your expertise, sharpens your judgment, and compounds your knowledge over time is not a candidate for automation, regardless of whether it could technically be delegated to a model.
And finally: what do I actually need to know about the tools to accomplish this specific thing? Not everything. Not the full feature set. Just what this goal requires, right now, with what is available. Everything else can wait.
The businesses that will get the most from AI and automation over the next few years are the ones asking the clearest questions before they start building anything at all.
Leave a Reply