Automating manual work, explained without the jargon

Teams tend to reach for this after something has already gone wrong. Here is automating manual work without the vocabulary that usually surrounds it.

Clear scope protects the client at least as much as it protects the agency. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

The short version

Automate the boring and repeatable, not the judgement calls. In practice this is a scheduling problem more than a technical one. Budget a little time for it every quarter and it never becomes a project of its own.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. Where this goes wrong is almost never a lack of knowledge.

Document the process before you automate it. The teams that handle this well are rarely the ones with the biggest budgets. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Turning this into a decision

Half-automated processes can be worse than manual ones. None of that requires a large budget, only a decision and someone to own it. Write the reasoning down alongside the decision, because the reasoning is what changes first.

In practice

The projects that go badly are rarely the ones with the hardest technical problems. Three things worth confirming about automating manual work before you move on:

• Someone can say what the current setup is without going to look
• Half-automated processes can be worse than manual ones — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.