The insight
Automating a manual process feels like an obvious win until something goes wrong and nobody can explain what the process was supposed to do in the first place. A skipped approval step, a missing notification, a record that never gets updated. These failures do not happen because automation is unreliable. They happen because the process was never properly understood before it was handed to a system.
The starting point is not software selection. It is a written description of the task as it currently exists, including every decision point, every exception, and every person involved. Sit with the person who actually does the work and ask them to walk you through it from the moment it starts to the moment it ends. Record what they say. You will almost always discover steps that were never written down anywhere because they lived in someone's memory.
Pay particular attention to the exceptions. A task might look simple on paper but in practice there are conditions that change what happens next. A client in a particular industry gets a different document. An order above a certain value needs a second approval. A supplier responds in a way that requires a manual workaround. These branches matter enormously in automation because a system that only handles the standard path will quietly fail every time an exception arrives.
Once you have a written description, map it as a simple flow. You do not need specialist software for this. A whiteboard sketch or a basic diagram on paper is enough. The goal is to see the process visually so that everyone involved can agree on what actually happens and spot anything that was missed in the written description. This is also the moment where you identify which steps are genuinely repeated and identical each time, and which steps require human judgement. Only the former are safe candidates for full automation at this stage.
Before you hand anything to a developer or configure any tool, define what a successful output looks like at each stage. If the process creates a record, what fields must be populated and with what data. If it sends a notification, who receives it and under what condition. If it triggers another task, what information does that task need to proceed. These definitions become your acceptance criteria when you test the automation later. Without them, you have no objective way to confirm the system is working correctly.
Identify who owns the process once it is automated. This is a governance question that South African businesses frequently skip. When the automation runs without anyone watching it, who is responsible for noticing when it behaves incorrectly. Assign a named person, not a department. That person should receive a simple log or summary at a frequency that makes sense for the volume of transactions, so that problems surface quickly rather than accumulating undetected.
Finally, keep the manual version of the process documented and accessible even after the automation goes live. This is not pessimism. Systems go down, integrations break, and edge cases emerge that the automation was not built to handle. If your team no longer knows how to do the task manually, a technical failure becomes a business stoppage. Treat the manual process documentation as a standing operating procedure that remains current even when the automation is handling the volume.
The work of documenting before automating feels slower than just building something. In practice it saves significant time, reduces rework, and means the automation you end up with reflects your actual business rather than a simplified version of it that creates new problems of its own.
Found this insight useful?
Tap the heart to let us know. No sign-in needed.