SolutionsAutomate

Remove the work that shouldn't need a person.

Automation projects fail in two predictable ways: they automate a process nobody agreed on, or they automate judgement and quietly make it worse.

Both are avoidable with one question asked honestly before anything is built — does this step follow a rule you can write down completely, including the cases you would rather not think about?

If you can write the rule and its exceptions, the step is a candidate. If writing it down starts a discussion, the problem is not automation. It is that nobody has agreed what the process is.

What is worth automating first

Some work has an unusually good ratio of hours saved to risk taken, and it is rarely the impressive-looking part.

Moving information between places — the highest value, lowest risk work there is
Anything that must happen on time regardless of who is busy
Checks that should never depend on someone's mood or memory
Making things visible: a view of what is stuck, updated without being asked

What to leave alone

If customers stay because you handle their awkward cases well, do not automate the awkward cases — that is the product. Pricing that depends on context needs a person. The first human response can be acknowledged automatically but should not be answered automatically; people can tell. And anything you have not done manually enough times to understand should wait, because automating it freezes a version you have not finished thinking about.

Where AI earns its place

AI has genuinely widened what can be automated — it handles unstructured input, a message written in someone's own words, a document in an unpredictable format. It has also made it easy to automate things that should not be, because the demo is always convincing. The test is the same as before: can you describe what correct looks like? Use it where a person checks the output as part of the normal flow. Be careful where it acts and nobody looks.

How we work on it

One step at a time, which sounds slow and is not. Automating a whole process at once means you cannot tell which part delivered the value and which part quietly broke something.

The process written down as it happens, workarounds included
Each step marked honestly as rule or judgement
The most repeated rule-shaped step automated first
A month later: would anyone notice if it stopped?

Recognisable when

Handoffs happen by message and memory
The same data is entered into more than one tool
Follow-ups are manual, and inconsistent because of it
Nobody can say what is stuck without asking around

Questions we get

Where should we start?

Almost always with the step where information gets retyped from one place into another. It follows a perfect rule, it is pure cost, and nobody enjoys doing it — which makes it the cheapest win available and the least risky thing to get wrong.

Do we need new software for this?

Often not. A lot of automation is connecting tools you already pay for, and the work is deciding what the process actually is rather than buying anything. Where a gap genuinely has no product behind it, a small custom piece fills it.

Will this replace people?

In our experience it moves them. The work that automates well is the work nobody wanted — retyping, chasing, checking. What is left is the part that needed a person in the first place.

How do we know it worked?

Ask after a month whether anyone would notice if it stopped. If it would be reported within a day, it was worth building. If nobody would mention it, you automated something that did not matter.

Start with the problem, not the service.

The first conversation is about understanding what is not working, not scoping a build. Sometimes the answer is much smaller than expected, and occasionally it is not software at all.

Start with a problem See Automate in context