In my articles on the Sanca vulnerability scanner and automated email sending , I describe situations where I was faced with a problem for which I came up with a solution.
But if you listen carefully, you’ll realise that within our clients’ environments there are numerous pain points just waiting for us to address them. Here are two anecdotes that enabled me to provide (almost unwittingly) clients with solutions they didn’t even realise they needed.

Generate a 200-row Excel file on a monthly basis

I’d been working for a major client for a few days when a manager asked me to list all the domain names registered in Azure Active Directory (AAD) in an Excel file, along with additional details such as whether a domain name is associated with an IP address, whether there is a web server, and so on.
An Excel file with around 200 rows and several columns – gathering all that information one by one takes time. I don’t know whether he was doing it manually or asking someone else to do it, but it seemed to be a chore for him.
I didn’t want to spend days building an Excel file only to be asked for it again the following month, so I automated the task straight away.

I spent half an hour writing a script in Fish; it carried out all the checks and generated the complete Excel file. The following month, when I sent him the Excel file five minutes after he’d asked for it, he asked me if I’d automated the generation of the file. I told him I had and showed him where to find the script, which I’d shared with the company.

After a while, he stopped asking me for the Excel file, and during a conversation I learnt that he was using the script himself.
Surprised, I asked him if he’d had any trouble using it, and he replied that it had been very straightforward, that he’d read the README file provided with the script and had followed the instructions.
I always comment on and document my projects, but for a manager to manage to use my script entirely on his own, on an operating system different from mine, on his own computer, was a real victory.

Instead of making them dependent on me and on a script I would have kept secret, I resolved a point of friction and enabled someone to be independent in their work. Some might say that I’ll lose my assignments if I allow my clients to be independent, but I see things differently.
Everyone hates service providers who lock their clients in; I, on the other hand, prefer my clients to stay with me because they want to, because they know I’m on their team.

Generating a monthly export of vulnerabilities by region

As explained in my articles on Sanca and automating email sending via AHK , I have been involved in vulnerability management. I automated everything I could on my end in order to handle as many vulnerabilities as possible.
One day, whilst chatting to someone responsible for overseeing the remediation of vulnerabilities across several countries, she explained to me that she would copy the data we sent in emails and paste it into an Excel file for tracking, which she would then supplement with further data. The ticketing system couldn’t provide her with all the data she needed, so she had to manage her own spreadsheet. I must admit I’d never thought of that.
What struck me was that the data she needed was already in my own spreadsheet. Why not let her benefit from it?

With my manager’s approval, I spent about twenty minutes writing a PHP script to take my Excel file, filter it to include only the vulnerabilities relevant to her, tidy up a few bits of data to make it a proper export, and I sent it to her. For me it was simple, nothing complicated, I was just doing her a favour, but for her it made a difference.
She no longer needed to copy and paste data from emails or fill in missing details; everything was there. She could focus on tasks where she added value.

Over time, we improved the export; for example, I extracted data from the ticket management system via the API to supplement the export, making it truly comprehensive. This Excel export, which I generated in a matter of seconds using a script that did the work for me, was useful to this manager.
It enabled her to track her current vulnerabilities, to find out when a vulnerability had been reported or the date of the last email exchange on the subject, but also to monitor progress in dealing with vulnerabilities. Managers are often adept at using Excel, so it was easy for her to see the number of vulnerabilities resolved by country and by month, to create a clear chart showing the trend, or even to identify the countries that take the longest to fix their vulnerabilities. This export was a genuinely useful working tool.

I hadn’t been explicitly asked to produce this export; my job was to process and report vulnerabilities. But if the teams responsible for these vulnerabilities didn’t have the tools to do their job properly, what was the point? Initially, I just wrote this script to help one person, because it seemed a shame to let a motivated colleague, even from another team, waste their time, and it was inconceivable to me to do it manually. I like people who try to do their job properly.

She liked the export so much that she asked me for it every month; luckily, it only took me a few seconds to generate it. It was so handy that, even though it wasn’t originally part of my remit, I started providing these exports to all the relevant managers.
Thanks to these exports, the managers were able to do their jobs more effectively, and our team collaborated much better with them. Logically, my manager should have been commended by his superiors for this collaboration. I was partly responsible for that, and I hadn’t even done it on purpose.

Much later, when another team took over the management of vulnerabilities, the manager who had originally organised the export was very disappointed to learn that the new team would no longer be providing her with this export. I’d got her used to a bit of luxury. New team, new methods.

The key is to listen

As techies, once we have the ability to automate something, it becomes unthinkable to do it manually. That said, we mustn’t forget to listen to the business teams, who are often left to their own devices with Excel as their only tool. I’m used to automating my own tasks, but by automating other people’s tasks, I’m taking a weight off their shoulders, and I’m always impressed by just how much it means to them.

When faced with this sort of situation – particularly the anecdote about the export of vulnerabilities – there are at least two types of people:

  1. Those who say we need artificial intelligence (AI) because it solves all our problems.
  2. And those who say the solution is to develop a massive, bespoke tool that does exactly the job, which will be available in three years’ time if we’re lucky and will cost 3 million euros.

To those who advocate for AI in every context, I would say that it is merely a tool, not a magic wand. There are situations where AI offers genuine added value, and many others where effective automation is more than enough.
Not to mention that AI comes with its own set of constraints: costs are unpredictable, sending sensitive data to a company, often a foreign one, is risky, and a business rarely has the hardware to run AI on a server using Ollama.

And to those who would like to overhaul the entire system in order to achieve a perfect solution, I would say that they are partly right. But long-term planning is as important as it is difficult; businesses evolve, teams change, and the perfect solution may become obsolete even before its development is complete.

I belong to a third category of people: I try to do my job and help others do theirs. I didn’t have the power to reform the company, but I did have the opportunity to provide immediate, tailor-made solutions. Thanks to this, together with the people involved, we were able to eliminate pain points, improve processes and enhance collaboration between teams, all in less than an hour.

Would you like to audit your processes to find out what to automate?
Let’s talk about it and find some solutions