Are One-Off Tasks Worth Automating? How to Hand Over Work You Do Once a Month

Writing a script has a premise: the job has to repeat often enough to be worth a body of code.

A lot of automation tools assume you already meet that premise. Real work also includes the opposite kind. The steps are many, the work is annoying, and the frequency is low. Four times a year, or once a month.

Doing it by hand is a nuisance. Writing a script does not pay. Below is how to handle that kind of job.

Three low-frequency jobs

Quarterly settlement screenshots. At each month end, finance opens four admin backends, screenshots the settlement pages, names the files by month, and drops them into a shared drive. Four backends, three to five screens each, twenty-odd steps in total. Once a month.

A stock check before a big sale. Before each major promotion, someone pages through the inventory of a dozen stores and flags anything below the safety line. There are only two or three big sales a year, and each one means a dozen stores.

A sudden competitor check. The boss says go and see what these three competitors have been pushing lately, so you spend an evening going through the home pages of dozens of accounts. It happens a few times a year, and each time it arrives in a hurry.

The three jobs share one shape: many steps, none of them hard, and a result you can check afterwards. That is the kind worth handing over.

Writing a script means mapping the flow first, fixing how each step is located, handling the exceptions, and then debugging. On a job you run every day, that work spreads out. On a job you run once a month, the same engineering returns one thirtieth.

There is a more concrete reason. Low-frequency flows are often close, and they are rarely identical. Last month there were four backends. This month there are five. Last time the files were named by month. This time finance wants them named by store. There is always a small change. Scripts handle that kind of change badly.

So most people did it by hand and put up with it.

Say the job once

iEasyRun works like this: you say the job once in ordinary language, and it goes and does it on the screen.

Say it in ordinary language: “open these four backends, screenshot the settlement page, name it 2026-09, and save it to that folder on the desktop”. Coordinates, control paths, and a pseudo-code draft are outside that description. It understands, then does the steps.

The cost of a script grows with the length of the task. The cost of saying it barely depends on the length. A twenty-step job takes about three minutes to explain clearly. Three minutes against two days is the line for whether this kind of low-frequency job is worth handing over.

A script remembers “the point at row 320, column 65”. Change the interface and you go back and change the script. AI phone control looks at what is on the screen and then decides: it reads the text and the elements on the current page, judges which one is the target, and taps it.

On low-frequency work that difference shows up more clearly, because:

• A month passes between runs, and the app has very likely shipped an update in between
• The entry point can sit somewhere else each time, for example after the backend home page is rearranged
• You are not going to maintain a script for a job like this

It looks for the button that says “Export”. If the point moves away from 320, 65, it still finds it. If the button moves from the left to the right, or a menu goes from one level to two, it still finds it.

If the same job comes back next month

Two ways, depending on how little effort you want to spend.

Save it as a workflow after the run. Once the first conversation run finishes cleanly, save the process and call it directly next time, with no second description. This fits a job you know you will do again, and whose flow will stay the same.

Save nothing, and say it again next time. When next month arrives, say the same sentence again. Saying it costs about three minutes, which is enough for something you do four times a year.

Most people start with the second. The third time they do a job, they notice they are saying almost the same thing, and then they save a workflow. That order is more natural than planning the workflow on day one.

Three tests.

The steps are many, and none of them are hard. The more steps there are, the easier it is for a person to skip one in the middle. That is the most direct gain from handing the job to a computer.

The flow is roughly the same each time. Close is enough. A job that needs a person to judge on the spot every time is one it cannot take over.

The result can be checked. Whether the screenshot landed in the right place, whether the stock was flagged: there is something concrete to look at. A result you cannot check is one you would not trust anyone with.

Two kinds of work stay with you. A job you can finish in two or three taps saves very little. A job whose rules differ every time is one it cannot do.

The first time, pick the shortest of your low-frequency jobs. Leave the quarterly settlement, with its twenty-odd steps, for later. Take a job of seven or eight steps, run it once, and see whether what it understood matches what you meant. Watch the first run or two. After that you can leave it.

When the run finishes, look at execution history: whether the status is right, and whether any step failed in the middle. Low-frequency jobs need that look more than daily ones. A high-frequency job shows the problem the next time you run it. A low-frequency job can sit wrong for two months before anyone notices last month was already off.

The software is completely free and runs on your own computer. On the same phone, keep the high-frequency work on scripts and run the low-frequency work from a conversation. The two sit side by side.