Automation

Automating recurring admin tasks with scripts

The same round every month: an export from one system, a bit of work in a spreadsheet, a file moved to the right folder, an email with the figures attached. A couple of hours, it nearly always goes fine, and it sits with one person who is sometimes off sick. Nobody calls it a problem, until the month it goes wrong.

This is the smallest kind of engagement on this site, which is a description rather than modesty. Automating a recurring admin task is a day or two of work: establishing exactly what happens, capturing it in a script, running it somewhere, and making sure you hear about it on the day it fails. No platform, no implementation programme. Just something you can read and change yourself afterwards.

When is a task worth scripting?

Not every manual action deserves a script. A task becomes interesting once it repeats, follows fixed rules, and can fail without anyone noticing.

Someone runs the same export every month, pastes it into a template and sends it on. Same steps, same person, every time.
Two systems are meant to show the same figures and someone compares them by hand until they agree.
Files from a supplier or customer have to be collected, renamed, checked and filed in the right place.
There is a check that ought to run daily, but which only happens when someone remembers.
The work has to run outside office hours or at the weekend, and someone currently stays up for it.
The task sits with one person, and nobody else knows exactly how it is done.

What the work covers

Writing the script is the smallest part of the job. Most of it sits in establishing what actually happens, and what should happen when it goes wrong.

Writing the task down as it genuinely runs today, including the exceptions that live only in the head of the person doing it.
Checking whether scripting is the right answer at all. Sometimes a task is better solved by dropping it altogether, or by a setting in a system you already own.
The script itself: readable, written in whatever already runs on your side, with no dependencies nobody can maintain.
Error handling: an empty file, a system that does not answer, two runs on the same day. Stopping with a message beats carrying on with half a result.
Logging and alerting: every run leaves a trace, and a failure reaches someone who can act on it.
Scheduling, hosting and handover: where it lives, what starts it, under which account, and one page explaining what to do when it complains.

What you get

No black box and no subscription. You get the working script plus everything needed to keep it running without me.

The script in your own environment or repository, source included, not as a service you rent from me.
A one-page description: what it does, what it needs, how to start it by hand, and where the logs live.
Alerting that lands with one of your people, not with me.
A half-hour handover with whoever will look after it, so at least one person has watched it run.
The freedom to change it yourself or have someone else change it. Nothing in it depends on me being available.

What it is not

Not an application. Once screens, users, permissions and a database enter the picture, scripting stops and software development begins. I will say so, and it becomes a different engagement.
Not an automation platform I talk you into. I sell no licences and hold no preference that earns me anything.
Not a support contract. I do not watch your scripts permanently; the alerting does that, and your own people respond to it.
Not cover for a process that needs tidying up first. Automating a messy task produces a messy result, only faster.

Common questions

How do I judge whether a task is worth automating?

Frequency times duration is the starting point: ten minutes a day weighs more than a day once a year. But time is not the only measure. A task that can fail silently, or that only one person is able to perform, is a good candidate too. And if working out and recording the rules costs more than the script will ever return, I would rather say so up front.

What language or tooling do you build it in?

Whatever fits what already runs on your side and whoever will maintain it. If a scripting language is already in use, I use that. If you already pay for a scheduler or an automation environment, we hang it there. The choice follows from your environment, not from my preference. More important than the language is that someone at your end can read the code.

How will I know a year from now that it is still running?

That is the real risk with small automation: the script stops and nobody notices, because success was as invisible as failure. So every script comes with a closed alerting loop. On a failure, a message goes to an address that is actually read, and the same happens when a scheduled run fails to appear at all. Silence is not proof that it went well.

What does something like this cost?

This is the shortest engagement shape I offer: one or two days, on a time-and-materials basis, or at a fixed price when the task can be described sharply enough. What drives the size: the number of exceptions inside the task, whether I can reach the systems involved in a sensible way, and whether the rules are written down anywhere or live only in someone's head. I name a rate in the first conversation.

When is a script no longer enough?

As soon as several people need to enter something, permissions and roles are required, or a screen has to sit around it. A script that slowly grows into an application is a script nobody dares touch any more. At that point it is more honest to design a proper web or mobile application. That is work I also do, but it is a different engagement, and the decision is yours.

More within this service

A task that comes back every month?

Sketch briefly what is done by hand today and how often. I will say honestly whether it is worth scripting, or whether something else would serve you better.

Book an intro call Send a message