Automation

Process automation: turning recurring manual work into a dependable process

Every Monday someone exports the same list, pastes it into a template, mails it round and keeps a private file of who has replied. It works, as long as that person is there. You want this to be a process rather than a habit.

Process automation is not a matter of putting a tool on top. It is redesigning a recurring sequence of steps: the ones that need no judgement run on their own, the ones that do stay with a person, at a point you can name. The technology follows from that design, not the other way round.

When this comes up

Not every repetition is worth automating. These situations are.

One person knows exactly how a recurring task goes, and that person is about to go on holiday.
A process runs on email and a shared file. Nobody can see its status without asking.
Volume is growing faster than the team, and the first instinct is another pair of hands.
Something was automated before and is now routinely bypassed, because it never matched how the work really runs.
You want to know whether AI adds anything here, or whether a dull script does the same for less.

What the engagement covers

The weight of the work sits before the build. What gets built is the outcome of that.

A map of the process as it actually runs, including the workarounds that appear in no procedure.
Choosing which process goes first: frequency, handling time and error cost, weighed against how stable the step is.
Redesign before build. Steps that can go, go; removing a step is cheaper than automating it.
The exception design: what the process handles itself, what goes to a person and how that becomes visible.
The build: integrations between existing systems, scripts, or a web application around them when separate parts are not enough.
Logging and measurement points, so a failure is noticed before a customer reports it.
Handover: documentation, access and a walkthrough for whoever will run it.

What you are left with

A working process and the means to keep it running without me. The second weighs as heavily as the first.

A process map of the current and the new situation. Short enough to read, precise enough to decide on.
The working automation itself, running in your environment and under your accounts.
An exception list: what runs automatically, what routes to a person and what the process deliberately leaves alone.
Documentation at the level needed to change it: where it runs, what it calls, what breaks.
A handover to whoever will maintain it, with the explicit aim that you do not need me afterwards.

What it is not

Not a platform I am selling you. No partner arrangements with suppliers; whatever ends up running, runs in your name.
Not an organisation-wide switch in one go. One process finished and supported, then the next.
Not AI because AI sounds good. Where a rule will do, a rule is cheaper, faster and easier to explain.
Not a reorganisation. I rebuild the process, not your org chart.
Not the automation of a process that needs clearing up first. If that is the finding, you hear it, even if you came in with a build request.

Common questions

Which process should I automate first?

Put three things side by side: how often the task occurs, how long it takes, and what an error in it costs. Whatever sits at the top is the candidate, provided the step stays stable for now and someone is willing to own it. Start small and visible: one automation that works convinces people more than a plan.

Our process is not much good. Automate it, or clean it up first?

Clean it up first. Automation makes a process faster and stiffer at the same time: the workaround someone can still take by hand today ends up in code tomorrow. Automating a bad process sets it in concrete. So I take every step and ask one question: why does this step exist.

Almost every case here is an exception. Does this still work?

That is a feeling, and it pays to count. Track for a month which cases genuinely differ and in what respect. The question is then not whether everything can run automatically, but which part can. The rest gets a proper route: recognise, hand to a person, record where it stopped. Halting silently is worse than not automating.

Where does AI fit, and where does it not?

The core of a process should be deterministic: the same input gives the same result tomorrow. There a rule or a script beats a model, because it is cheaper and explainable. AI earns its place at the edges, where the input is messy: pulling data out of documents or messages, classifying, drafting text. Provided the output stays checkable and no irreversible step runs without a person confirming it.

What does this cost, and what does an engagement look like?

It depends mostly on how many systems the process touches and how unambiguous the exceptions are. The shapes: a short engagement of a few days to map the process and pick the first candidate, build work on a time-and-materials basis with an agreed ceiling, or a fixed price for a defined result. I name a rate in the first conversation.

More within this service

Work that comes back every week?

An introductory conversation is without obligation. Sketch out the process; I will say honestly whether automating it pays off here, and if so which part goes first.

Book an intro call Send a message