My First Automation Project: Improving a Manual Service Desk Process
Several years ago, before AI assistants became part of my daily toolkit, I built what was probably my first real automation project.
At the time, I didn't know VBA, had never written Office macros, and had no experience extending Excel. If I got stuck, there was no AI to explain an API or generate working code. It was mostly documentation, trial and error, and a lot of persistence.
- Looking back, I can see plenty of things I would do differently today.
- The code isn't perfect.
- The architecture certainly isn't either.
- But the problem was real.
A Process Everyone Accepted
The Service Desk I worked in sent the same types of emails over and over again.
Onboarding instructions, reminders, equipment returns, employee departures, follow-ups... None of these tasks were difficult, but they were repetitive.
Technicians copied old emails, updated a few names, searched for recipients, attached the right documents and repeated the same process dozens of times every week.
And they accepted that face like it was something you could not change.
It wasn't just time-consuming. It also meant inconsistent wording, forgotten information and unnecessary manual work.
Instead of accepting the process, I decided to see how much of it could be automated.
Building with the Tools Available
The result was Service Desk Mail Merger.
The objective wasn't to build a sophisticated application. It was simply to reduce repetitive work by centralizing email templates and automating everything that didn't require human judgement.
The solution combined Excel, VBA, Outlook automation and a few PowerShell scripts, packaged with a simple installer so other technicians could use it.
For someone with almost no experience in those technologies, it felt like a huge project. Most of the development wasn't about adding features. It was about learning how everything worked.
The Hardest Part Wasn't Technical
What surprised me most wasn't the development effort.
It was the adoption.
I wrote documentation, prepared installation files and tried to make the tool easy to use. Despite that, very few people actually adopted it.
In practice, I remained its main user.
That experience taught me something I still see in projects today: solving a problem doesn't automatically change people's habits.
Even when a solution saves time, people need to trust it, understand it and feel comfortable integrating it into their daily work. Documentation helps, but it isn't enough on its own.
I Would Build It Differently Today
An Excel-based solution wouldn't be my first choice anymore.
Today there are much better options: Power Automate, Microsoft Graph, ServiceNow integrations and countless automation platforms make this kind of workflow much easier to implement and maintain.
The technology has changed.
The problem hasn't.
Many Service Desk teams still spend a surprising amount of time preparing the same operational emails manually when much of that work could be standardized.
Prerequisites
The original project assumes:
- Microsoft Excel with macros enabled
- Microsoft Outlook
- Windows PowerShell
- Local installation of the Mail Merger package
- Permission to execute macros and PowerShell scripts
- Standardized email templates
- Structured source data stored in Excel
Looking Back
I wouldn't deploy this solution unchanged today.
It belongs to another era of tooling.
What I'm still proud of isn't the technology itself, but the mindset behind it.
It was the first time I stopped asking, "How do I complete this task?" and started asking, "Why are we still doing it this way?" (and i'm still asking to this today, WHY ?!)
That change in perspective has stayed with me ever since. Most operational processes contain repetitive work that can be simplified. Sometimes the biggest value of a project isn't the tool you build, but the way it changes how you look at problems.
0 Comments