The best automations I have ever built did not start with a tool. They started with me getting annoyed at the same manual step for the fifth time and deciding to do something about it. Nobody assigned me an "automation engineer" title and told me to go build. I found the problems in the queue, I fixed them one at a time, and eventually the title caught up to what I was already doing.
If you work in support or IT and want to take the same path, here is the exact framework I used: what to fix first, what to learn, how to build credibility, and how to grow a portfolio out of problems you are already sitting next to every day.
The Problem Was Already There. Nobody Had Named It.
Early in my career, I was doing support at RAI Plywoods, answering helpdesk tickets and managing ICT requests. The work itself was fine. But I kept noticing the same thing: certain categories of request came in again and again, and every time they did, someone on the team would stop what they were doing, look up the same account information, and type out a nearly identical response. No one had a process. Everyone just handled the next ticket.
Later at a large international NGO, same story at much larger scale. Password resets, access request emails, "how do I do X in the system" questions. The volume was higher, the team was stretched thinner, and the pattern was identical: repeat work, handled manually, by someone who had better things to do.
There is a gap in every team between "someone should automate this" and "a developer has capacity to automate this." That gap is usually permanent, because developers have their own roadmap and internal IT toil is rarely on it. The people who become automation specialists are the ones who decide to close that gap themselves.
The First Automation I Built (And What It Taught Me)
The first workflow I ever automated was a password reset queue. Users would email IT, we would verify identity against a simple set of checks, and then manually walk through the reset. The process took roughly 8 to 12 minutes per ticket, and we were handling a few dozen of them a week.
I rebuilt it as a form plus a Zapier workflow. Users submitted a form with the information we needed to verify them. Zapier caught the submission, ran the checks we had defined, and triggered the next step automatically. The whole thing took about half a day to build. It ran for nearly two years without me touching it again.
The ticket volume for password resets dropped by roughly a third within the first month. More importantly, the remaining tickets were the edge cases that actually needed human judgment: locked accounts with unusual circumstances, requests that did not match our verification pattern, the situations that genuinely needed someone to think.
The hardest part was not the tool. It was describing the current manual process precisely enough that I could replicate it in software. If you can write a step-by-step SOP that a new hire could follow without asking questions, you can automate that process. The tool just executes the SOP for you.
How to Find What to Automate First: The Frequency Test
I use a simple test for prioritising automation work. For two weeks, I track every task where I or a colleague does the same sequence of actions more than ten times in that period. Not complex multi-step projects. Just repetitive sequences: look up this, copy that, send this, tag it, move on. A simple spreadsheet is enough.
At the end of two weeks I sort by time saved. The calculation is straightforward: multiply the frequency per week by the minutes per instance by 52 weeks. Ten tickets a week at eight minutes each is roughly 70 hours of team time per year. One afternoon to build the automation. The math almost always wins.
What you are looking for specifically:
- Same lookup, different ticket. Any time someone opens a second tab to retrieve context that could have been fetched automatically.
- Copy-paste between systems. A piece of information that lives in one place and needs to appear in another, done by hand every time.
- Status update emails. Anything where the content of the email is essentially a template with one or two fields filled in manually.
- Categorisation or tagging done by eye. If someone reads a ticket and assigns a category that follows a predictable pattern, that pattern can be automated.
You do not need to build all of these. Pick the one at the top of the list and build that. Get it running and stable before you move to the next one.
What You Actually Need to Learn (And What You Can Skip)
You do not need to learn to code. That surprises people when I say it, because the word "automation" carries a lot of developer baggage. But the tools that power most support and IT automation, Zapier, Power Automate, n8n, GoHighLevel workflows, are designed to be used without writing code. The logic is visual. The errors are readable. The learning curve is measured in days, not months.
Here is what actually matters:
- Understand triggers and actions. Every automation tool is built on the same concept: something happens (the trigger), and then something else happens in response (the action). Master this mental model and every tool makes sense immediately.
- Read JSON without panicking. You will encounter JSON data in almost any integration work. You do not need to write it from scratch. You need to look at it and understand the structure well enough to find the field you want.
- Understand what a webhook is. A webhook is a URL that listens for data to be posted to it. When you send data to that URL, it triggers an action. That is the whole concept. Once this clicks, a large portion of integration work becomes accessible.
- Learn one tool well before learning five tools broadly. I started with Zapier because the error messages are clear, the documentation is excellent, and the interface is the most forgiving of the major options. It is not the cheapest tool at scale. But for learning, it is the right first choice.
What you can skip for now: Python, building your own APIs, anything that requires a server to run, authentication flows more complex than OAuth. These are worth learning eventually. They are not where you start.
How to Earn the Right to Automate More
Early automation work lives or dies on trust. Build something internal and low-risk first, not something that sends emails to customers or modifies production records. The goal with your first few automations is not to impress anyone. It is to demonstrate that things you build keep running after you stop looking at them.
Document the before and after for each one. Not a formal report. Two numbers: what the manual process cost in time per week, and what it costs now. Share those numbers with your manager in a two-line message, not a presentation. "Password reset workflow shipped. We were spending roughly X hours a week on this, now it is closer to Y." That is it. No ceremony required.
The portfolio builds slowly and then quickly. After six months of building small things that stay running, you have a track record. After a year, you have a reputation. After two years, people come to you before they even write the ticket, because they know you will ask whether it should be a ticket at all.
The Career Is in the Gap Nobody Else Is Filling
Nobody handed me the role I have now. I found a gap between the support team's needs and the development team's capacity, and I chose to live in that gap. The first automation was a password form and a Zapier trigger. What followed was gradually more complex: CRM data enrichment, support routing logic, onboarding and offboarding workflows, proactive outreach sequences triggered by customer behaviour signals.
The title followed the work, not the other way around. That is how it goes for most people who end up in an automation or ops role inside a support or IT function. The job description comes second. The portfolio is first.
If you are sitting on a support desk right now and you have noticed the same pattern repeating in the queue this week, that is where you start. Not with a course. Not with a certification. With the next ticket that should not be a ticket.
If you are at that point and want to compare notes on what to tackle first, drop me a message. I am happy to look at your ticket patterns and tell you where I would start.
Comments