Automation that knows
what happened.

I do not start with a technology: first I describe the current workflow, exceptions and responsibility. Then we decide what software should take over and where a person should remain involved.

When automation is worth it

The best candidate is not simply a task that repeats. It is a process with a clear start, rules and outcome where people currently lose time copying data, checking results or switching between systems.

Typical examples include order handling, recurring data transfers, spreadsheet work, reports, status checks or handoffs between several tools. The value is not that software clicks faster. It is that the team can see what was processed, what is waiting and what needs a decision.

What can be automated

• repetitive steps in an internal or web system,
• scheduled tasks and batch processing,
• data transfers and validation between tools,
• files, reports and publishing inputs,
• the part of a workflow that should be prepared for approval.

If a usable API exists, I prefer it to interface automation. If the API is missing or does not cover the full process, browser automation may be appropriate. I always explain its dependency on a third-party website and the cost of future maintenance.

Automation is more than a script

A one-off script can survive the happy path. An operational automation must also handle slow responses, temporary outages, duplicate runs, incomplete data and a state that cannot be safely interpreted.

Depending on the process, I design a queue, state model, safe retries, duplicate protection, logs and alerts. Sensitive steps can wait for manual confirmation. When something fails, the context stays available instead of forcing a person to restart the whole process.

How the work progresses

1. Describe the process: normal flow, exceptions, inputs, outputs and systems.
2. Set the first boundary: choose the smallest part that can prove value.
3. Prototype and test: validate the technical path, access, limits and failure behaviour.
4. Prepare operations: add logs, retries, monitoring, documentation and handover.

What should improve after delivery

The result should not be only fewer clicks. Good automation makes responsibility clearer, reduces silent failures and gives the team a way to trace what happened. It also defines when a person should intervene and when the issue belongs to an external service.

If the process changes every week or its rules are unclear, I may recommend improving the process first. Automation should not turn an unresolved decision into a faster recurring problem.