AI makes automation faster. Making it dependable still takes experience.
You probably know the routine. A system exports a report, but not in a format anyone can actually use. The supplier has no plans to change it, so someone opens Excel.
They convert the data into a table, add filters, tidy the colours, apply formatting rules, fix the dates and combine first and last names. None of it is difficult. But it takes 20 minutes every time, and when the report is needed several times a week, those minutes add up to more than a working week a year.
A deliberate experiment
That is exactly the kind of task I set out to automate at Netitude: take a CSV export from our security awareness reporting and turn it into a consistently formatted Excel report. We ran it on our own processes first, so we could learn before making any commitments to clients.
I also set myself a deliberate constraint. I would build it entirely with the Microsoft 365 tools many of our clients already own: Copilot, Power Automate and Excel scripting. I wanted to see how far that route would go on its own.
Faster, not instant results
An AI assistant saved me a great deal of research. It helped me explore approaches and work through unfamiliar details far faster than documentation alone would have.
What it did not do was produce a finished solution. Getting the process working reliably drew on years of hands-on experience with Microsoft 365, Power Automate, scripting and troubleshooting. Knowing what to ask, what to question and how to test the answer mattered more than any single suggestion.
The build took many hours, which is longer than the headline promise of AI might suggest. It will still pay for itself because a task repeated several times a week quickly recoups that time. But the more useful result was understanding where those hours went.
The hidden cost of being the go-between
Most of those hours were not spent solving hard problems. They were spent relaying information.
Copilot would suggest a step. I would build it in Power Automate, run it, then copy the output or error back and ask for the next step. The AI could not create the flow itself, nor could it see what its own suggestions produced. So I became the connection between the two, carrying information back and forth to keep things moving.
That is not a verdict on the products, each of which is useful in its own right. It is a lesson about tool selection. AI accelerates automation most when it works inside a platform where it can build the workflow, run it and interpret the results directly, with a person reviewing and approving rather than ferrying messages.
Acting as a courier for an AI is not a valuable use of anyone's time. And freeing people from low-value work is the whole point of automating in the first place.
Beyond the demonstration
A working demonstration proves that a process can run. It does not prove that a business can rely on it. A flow that reports success is not enough if the published report contains incorrect data, so testing must verify the outcome, including what happens when expected information is missing.
The prototype also ran under my own account. That was fine for an experiment, but it is not a design to carry into production. Production automation needs deliberate decisions about ownership, least-privilege access, monitoring and maintenance, plus continuity if the person who built it leaves. The right account model depends on the process and platform; there is no universal rule.
These requirements are far less visible than the finished report, which makes them easy to overlook when judging a demo. They are also where a managed service earns its place: detecting exceptions, recovering safely where possible, and making sure the right person knows when human judgement is needed. That is why I assess every automation opportunity against the whole process: who depends on the output, what failure would mean, and who is responsible for putting it right.
Recovery with boundaries
The goal is automation that handles common faults safely: retrying a temporary failure, following an agreed recovery path, or escalating clearly. What I do not want is AI improvising business rules when a situation is ambiguous. Useful self-healing needs boundaries, monitoring and human oversight, not just another set of generated instructions.
What this means for how we build
Experiments like this are how we test our own assumptions before they reach a client. This one confirmed two things: AI genuinely shortens the path to a working automation, and experience is what turns a working automation into a dependable one. It also reinforced a decision we had already made. The platform matters.
That is why Netitude's new managed automation service runs on a dedicated development platform we chose specifically for this work. AI works within the platform rather than alongside it, and we provide the ownership, monitoring, and support a business needs to keep it running, depending on what we build. The value is not simply building faster. It is building something that keeps working.
If you are wondering where automation could give your team time back, I would welcome a conversation about where to start.
My experiment reinforced something important: AI can help us build automations faster, but making them dependable takes experience, the right platform and a clear understanding of the business process we're trying to improve.
The real value isn't simply getting a task to run. It's creating a solution that works consistently, handles problems sensibly and gives people confidence in the results.
That's the thinking behind net9.ai, Netitude's new managed automation service. We're bringing together AI-enabled development, practical expertise and ongoing support to help businesses move beyond experimentation and put automation to work in a meaningful way.
If your team is spending too much time on repetitive tasks, I'd welcome a conversation about where automation could make a difference.