You already own the low-code automation platform. Your organisation paid for it as part of an enterprise productivity suite. The licence is active. Your IT team can deploy flows by next week.
You do not already own a designed process.
That distinction is where the budget conversation breaks down. Banks in Singapore and Malaysia are asking 'which automation tool?' when the operative question is 'who will design the process being automated?' Those are different budget lines, with different outcomes.
The Category Error in the IT Budget Meeting
A general-purpose automation flow tool does exactly what it promises: it executes a sequence of steps reliably and at scale. If the sequence was designed well, it executes a good process. If the sequence was inherited from a manual workflow nobody questioned, it executes that too — faster, and with a clean audit trail.
The category error is treating the automation decision and the process design decision as one question.
Abdulla Al-Awadi, former Chief Strategy Officer at a Kuwait bank and founder of ESSAM, describes this pattern directly: 'Automators don't fix processes; they amortise them.' The broken step persists. The speed increases. The error rate becomes a system metric rather than a process symptom.
Banking ops leads who already have an enterprise suite licence feel pressure to 'just use what we have.' That is a reasonable cost instinct. It becomes expensive when the process being automated has never been mapped at the handoff level.
What the Low-Code Platform Actually Does
Incumbent low-code automation tools are capable. They can build multi-step approval flows, automate document routing, trigger notifications, and connect line-of-business systems without custom code.
What they do not do:
- Identify which steps in the process should not exist
- Detect approval stages that duplicate a check already done upstream
- Map the waste embedded in the current-state workflow
- Assign ownership to handoffs with no current owner
- Generate an SOP, SLA, or RACI from the process model
A flow built on an unmapped process carries all of those problems forward. The automation makes them invisible.
When an Automation Flow Is Enough — and When It Is Not
Not every process requires engineering before it can be automated. Some workflows are well understood and simply run slowly because they are manual. The distinction:
| Scenario | Appropriate response |
|---|---|
| Steps are known, documented, and the manual process works as designed | Automation flow is sufficient |
| The manual process is slow but the sequence is sound | Automation flow is sufficient |
| No one can describe the current process without hedging | Process engineering first |
| Multiple people own the same step with no defined handoff | Process engineering first |
| The process has not been formally mapped in over two years | Process engineering first |
| A previous automation failed or was abandoned | Process engineering first |
| The process spans more than two teams with no SLA in place | Process engineering first |
| Compliance or audit requires documented ownership at each step | Process engineering first |
The cheapest automation is not the one that requires no licence fee. It is the one built on a process that is already sound.
The Cost of Automating a Broken Process
Consider a bank that built an automated credit-limit review flow using the general-purpose automation platform already bundled with its productivity suite. The flow ran. Approvals processed on schedule.
Six months later, an audit identified three approval stages that had been carried from the manual process into the automated one. Each had existed because someone required it at some point. None added control value. The automated flow had accelerated a redundant process and produced a documented record that it had done so.
That is an illustrative scenario. The audit trail is what makes it costly.
Automation of a broken process does not hide the problem. It records it. If the process included a poorly designed approval gate, the system log will show that gate firing thousands of times. That record is available to regulators and internal audit teams in Singapore and Malaysia alike.
What Process Engineering Does First
ESSAM runs four phases in deliberate sequence: Eliminate, Simplify and Standardise, Automate, Migrate. Automate is the fourth phase.
Before any flow is built, ESSAM captures the current-state process conversationally, in a session with the people who actually run the work. It auto-tags waste against eight MUDA categories. It generates a before-and-after audit view, plus SOPs, SLAs, and RACI assignments, from a live process model. It runs a failure-mode analysis before go-live.
The low-code automation platform you already own then executes a designed process rather than an inherited one.
A Kuwait bank cut a procurement cycle from 139 days to 57 days, a 59% reduction, by eliminating and simplifying before any automation was introduced. That was procurement. The sequencing principle applies across banking operations: loan approvals, trade confirmations, reconciliation exceptions, account opening.
Where to Start
The question is not whether to automate. The question is whether the process is ready to be automated.
ESSAM's 7-step AI Lean cycle (Baseline, Map, Analyse waste, Optimise, Document, Deploy, Improve) establishes process readiness before a single flow is built. Standards deploy over WhatsApp, which staff in Singapore and Malaysia already use, with no additional adoption overhead.
If your automation flows are underperforming, or your team is about to build new ones, run the process-readiness check first. Book a demo on your process. Your actual workflow. No hypothetical use case required.
Related reading: AI process automation vs RPA in banking · Build vs buy process automation TCO · ESSAM features