How do you automate customer support without breaking escalation?
Map every escalation rule a human currently applies, and automate only the work that sits above the rules. Escalation is not a feature you add to an automated flow — it is the boundary of the flow, so the boundary has to exist and be written down before anything is automated. Teams that automate first and define escalation later end up with a system that handles everything confidently, including the things it must not touch.
Start from the rules that already exist
Every support team has an escalation policy, and every version of it is a compromise between what is safe and what an agent can remember under pressure. Write down what the policy says and then what the team actually does, because those differ. In fintech the difference usually runs in the safe direction — agents escalate far more than the policy requires, because being wrong about money is a career event. Those extra escalations are the real automation target, and they are invisible if you only read the document.
The output of this stage is a table: trigger, who decides, what the human must see before deciding, and what the worst outcome would be if the decision is wrong. If you cannot fill the last column for a row, you have found a rule nobody understands, which is not automatable yet.
Automate the work above the line, not the decision
Split every task into gathering, judging, and acting. Gathering and acting automate well; judging does not, and a first project should not try. Fetching the customer's transaction history, working out which product the issue belongs to, drafting the reply in the right language and tone, and pre-filling the ticket fields is most of the time an agent spends on a real case. The decision — refund or dispute, block or unblock, escalate or close — takes seconds and is the part worth keeping human.
Concretely: at FINETIKS the work I lead is agentic AI workflows and context-aware automation that reduced manual intervention by 40%, sitting alongside the support operations, escalation paths, and n8n automations that carry it. The 40% is typing, looking things up, and moving information between systems. It is not judgement about a customer's money.
Make the boundary visible in the product
Two things have to be true in the interface or the automation will quietly widen. The agent must be able to see what the system did and why, in the same view where they work — a collapsed panel of "3 sources consulted, drafted from template X" is enough. And the system must state, in the ticket itself, when it chose not to decide.
The failure mode I design against is not a wrong answer. It is a right answer with no trace, because then nobody can audit it, nobody can teach it, and the next person to inherit the workflow has to guess which parts are load-bearing. When we cut manual intervention at FINETIKS the condition I held to was that the human decision path stayed legible — a faster queue with an invisible brain inside it is not a system, it is a rumour about one.
Filbert Henrico is a Technical Customer Success Lead at FINETIKS in Tangerang since June 2025, with seven-plus years of customer success and technical sales across Southeast Asian fintech, including Xendit, Peakflo, and Brick. His focus includes API integrations, agentic AI, workflow automation, conversational AI, UAT, and launch readiness. Bachelor of Marketing, Victoria University, Bandar Sunway, Malaysia, 2016–2019.
Stuck on something similar?
These pages describe how I approach the work, not a fixed methodology. If you are scoping something similar and want a second opinion on the trade-offs, send me the problem in the messy state it is actually in.
Keep reading
All questionsWhich AI use case should a team build first?
Build the one where a human already does the task every day, the correct answer is easy to recognise, and a wrong answer is cheap to undo. Those three conditions are what let you finish the project: the workflow gives you data, the recognisable answer gives you a test, and the cheap undo gives you permission to ship.
What does production readiness mean for a voice AI agent?
A voice agent is production-ready when it can end a call safely without ever needing to be clever. That means four things are tested against real audio, not transcripts: it recognises the caller's actual speech, it handles being interrupted, it has somewhere to hand off to a human, and every action it takes against a real system has a limit it cannot exceed.
How should a fintech team evaluate an AI vendor?
Evaluate the vendor's failure behaviour, not their accuracy claim. Ask for the worst ten calls they can show you, what the system did when it was wrong, and who found out. A vendor who can answer that has built something; a vendor who answers with a benchmark number has built a demo.