Anyone discovering macros, scripts and no-code automation for the first time tends to want to use them everywhere. That is understandable, but it often leads to two disappointing results: automations painstakingly built for tasks that took two minutes a month, or fragile flows that break and that nobody knows how to fix any more. Before building, it pays to measure. This article proposes a simple method for deciding what to automate, in what order and with which tool.
Step one: list the repetitions
For two weeks, keep a list of the repetitive tasks you perform. You don't need to-the-second precision, but for each item note:
- what you do, described concretely: "I copy orders from emails into the sales sheet";
- how often: every day, every week, at month end;
- how long it takes each time, even as an estimate;
- where the data comes from and where it ends up: email, PDF, management system, spreadsheet, web portal;
- how many decisions it requires: none, a few simple ones, many subjective ones.
This list is useful in itself. Tasks often emerge that could be eliminated altogether, before even automating them: a report nobody reads any more, a double entry that started years ago for a reason that no longer exists.
Step two: calculate the time at stake
For each task, multiply the duration by the annual frequency. A 10-minute operation every working day is worth about 40 hours a year, assuming around 230-240 working days. A 30-minute operation once a month is worth 6. The comparison is often surprising: small daily tasks weigh more than large occasional ones.
On the other side you have to estimate the cost of the automation, which is not just the time to build it:
| Cost item | Question to ask |
|---|---|
| Building | How many hours for a first working version? |
| Testing | How long to check that it works on real cases? |
| Maintenance | How often do the formats, programs and portals involved change? |
| Licences | Are subscriptions to platforms or programs needed? |
| Training | Does whoever will use it know how, and what to do if it stops? |
If an automation takes 20 hours between building and testing and saves 40 a year, it pays for itself in a few months. If it saves 6, think carefully.
Step three: assess suitability
Time is not the only criterion. Some tasks lend themselves far better than others. A good candidate has these characteristics:
- clear rules: you can explain the procedure to a new colleague without saying "it depends";
- structured or structurable data: spreadsheets, CSV files, PDFs generated by programs, forms; low-quality scans and free text are harder;
- stable inputs: the data format doesn't change every month;
- recognisable errors: if something goes wrong, you notice quickly;
- limited consequences: a mistake doesn't cause irreparable damage.
The last point deserves attention. Automating PDF filing carries low risk; automating payment reminders to clients carries higher risk, because a mistake is visible to the outside world. That doesn't mean it shouldn't be done, but that it needs more checks, such as a human review before sending.
Step four: choose the simplest tool
For each chosen task, start from the simplest tool that solves the problem:
- a feature already in the program: email rules, mail merge, conditional formatting, pivot tables;
- a macro or a text expander for repetitions within a single program;
- a no-code platform to connect different online services;
- a script when you need complex logic, many files or local data;
- RPA only when the only interface available is the graphical one.
In my work I have often seen the opposite path: an elaborate script for a problem that mail merge solved in ten minutes. The simplest tool is also the one other colleagues will be able to understand and maintain.
Automating halfway is often the best choice
Not everything has to be one hundred per cent automatic. An automation that prepares the work and leaves the final check to a person, for example generating email drafts without sending them, captures much of the benefit with a fraction of the risk. You can always complete the automation later, once you have seen for a few weeks that the result is reliable.
Review after a few months
An automation in production should be reassessed after a while: does it save the expected time? Has it broken? Has someone stopped using it? A periodic check of the original list, updated with the results, lets you choose the next task to work on based on real data rather than impressions.
In short
- For two weeks, list repetitive tasks with frequency, duration and data flow.
- Multiply duration by frequency: small daily tasks weigh more than you think.
- Count building, testing, maintenance and licences as real costs.
- Favour tasks with clear rules, structured data and recognisable errors.
- Choose the simplest tool and consider partial automation with a human check.
