Most automation projects do not die from a lack of technology. They die from too much ambition. You want to automate everything at once, you touch ten processes at the same time, and at the first grain of sand nothing holds. The team falls back on old habits, the fine tool gathers dust, and the wrong conclusion gets drawn: people decide automation does not work here, when it was the method that was bad.
Since 2019, I have built bespoke automation systems with NS Corp, for small companies and for larger ones. The most useful lesson I draw from it fits in one sentence: you do not automate an intention, you automate a process you have understood first. Here is the method I apply, in four steps.
1. Choose the right process, not the most visible one
The natural reflex is to aim at what annoys people most, the task everyone hates. It is rarely the right starting point, because the most painful tasks are often the most complex and the most full of exceptions.
The first process to automate should tick three boxes. It is repetitive, so the gain recurs. It is stable over time, so you will not be rebuilding it every three months. And its result is easy to check, so a mistake shows at once.
A daily entry, always identical, whose result you can verify at a glance: an excellent candidate. A process that changes with the customer, the month and the mood of the market, and whose error only surfaces three weeks later in the accounts: a very poor candidate for a first step. You will get to it, but later, once trust is in place.
2. Map it before writing a single line
This is the step everyone wants to skip, and it is the one that decides success. Before coding anything, you draw the process as it really exists. Not as it is supposed to exist in some forgotten procedure. Who does what, in what order, with which decisions, and above all with which exceptions.
This work almost always reveals a surprise. Half of so called technical problems are in fact processes no one had ever set down clearly. Two people do the same task differently. An official step has been bypassed for months. A rule everyone thought absolute turns out to suffer five exceptions. As long as that blur exists, no automation will hold, because you would be automating a fiction.
Mapping, then, is first of all clarifying. And that clarity has value even if you automate nothing afterwards.
3. Automate in slices, keeping a human in the loop
You never switch off the old system the day the new one starts. That is the surest way to lose everything at the first surprise.
You run both in parallel for a while. The machine proposes, the human validates, you compare results. As long as they diverge, you keep the safety net and you correct. When they converge in a stable way, over several weeks, you gradually remove the net. This caution is not slowness, it is assurance. It is what lets a project survive the first awkward case instead of collapsing.
I often see impatient leaders at this stage, who would like to switch over all at once to reach the gain faster. I always give them the same answer: the gain of an automation is not the speed at which you launch it, it is how long it holds. A brutal switch that breaks after a month gains you nothing at all.
4. Plan for the exception, not just the ideal case
A real process is full of special cases. The customer who pays another way, the supplier who sends an odd format, the month when everything overflows. An automation that handles only the ideal case creates more work than it removes, because every exception becomes an emergency to be handled by hand, in a rush.
The rule is simple: a good automation knows how to recognise what it cannot handle, and pass it cleanly to a human, rather than forcing an answer. It is less spectacular than a perfect demo where everything glides, but it is precisely what holds in production. You do not judge a system by its demo, you judge it by how it handles the day things do not go as planned.
The framing mistake I am most often called to fix
To end on something concrete, here is the scenario that comes up most when I am called in to rescue a project. A company tried to automate a large chunk of its activity in one go, won over by a promise of transformation. Six months later the tool is half used, the teams have kept their old habits in parallel, and no one knows any more which version of the information is authoritative.
The repair rarely runs through more technology. It runs through stepping back, isolating one simple process, making it truly work, and rebuilding trust from there. To automate, at bottom, is not to replace people with code. It is to take the repetitive gestures off them so as to give them back time to decide. You start small, on understood ground, you keep a human within reach, and you extend once trust is earned. Those who do that succeed. Those who want everything, all at once, end up with nothing.