Conversational AI
Tiledesk
Multi-agent
Web chat
WhatsApp
Backend APIs
Multi-agent Support
for a Payments Fintech
A payments fintech needed support across three areas: merchants and partners, consumer app users and general customer service, mainly on web and WhatsApp. I split the work across agents and sub-agents that answer from knowledge, look up the customer’s own case through backend APIs and hand over to a person when a case needs one.
90%+
Of conversations automated
~13K
Conversations a month on the busiest agent
90%+
Answer rate on that agent
3
Support areas in one setup
Built with
Tiledesk
AI agents
Knowledge base
Routing logic
Backend APIs
CRM
Context
The problem
In payments, many support questions are about the customer’s own situation: where is my payment, what’s the status of my case, what’s missing from my account setup. A bot that only knows the help pages can’t answer those. On top of that, three very different groups were asking: merchants and partners, people using the consumer app, and general customers.
01. Different audiences
A merchant and an app user can ask a similar question and need a completely different answer.
02. Answers live in systems
Payment status, case data, KYC and setup info sit in backend systems and the CRM, not in a knowledge base.
Architecture
How it works: 4 layers
Each agent combines AI prompts, a knowledge base, conversation history, routing logic and backend API calls. The layers below show how a conversation moves through them.
Routing
Find out who is asking and send them to the right agent
Routing logic decides whether the conversation belongs to merchant and partner support, consumer app support or general customer service.
Agents and sub-agents
One specialist per support area
Each area has its own agent with its own prompts and knowledge. Sub-agents take over specific tasks inside an area, so no single agent has to know everything.
Backend API calls
Answers about the customer’s own case
The agents call backend APIs for payment status, case data and KYC info, and pull customer data from the CRM. The customer gets an answer about their situation, not a link to a help page.
Escalation
A person when the case needs one
When a case goes beyond what the agent should handle, it escalates to a person, who picks up with the conversation history.
Design decisions
Why each choice was made
One agent, or agents and sub-agents per support area?
One agent for everything means one very long set of instructions, and every change risks breaking an area that was working. Splitting by support area keeps each agent focused, makes its answers easier to test, and lets me improve one area without touching the others.
Not chosen: one large agent
Long instructions, mixed audiences, hard to test. A fix in one area can break another.
Chosen: agents and sub-agents per area
Focused instructions and knowledge per audience. Each area is tested and improved on its own.
Answer from knowledge only, or call backend APIs?
Knowledge answers “how does this work”. Customers in payments mostly ask “what is happening with my payment”. That needs live data, so the agents call backend APIs and the CRM during the conversation.
Not chosen: knowledge only
Fine for general questions. Can’t answer anything about the customer’s own case.
Chosen: knowledge plus backend APIs
Payment status, case data, KYC info and CRM data available inside the conversation.
When should the agent escalate?
I treat escalation as a designed path, not a failure. Each agent knows what it can resolve. When a case goes beyond that, it hands over instead of guessing, and the person receives the conversation history so the customer doesn’t have to repeat themselves.
Handover and measurement
What happens after go-live
I designed the agent split and routing, configured the agents and connected the APIs. Going live was the start of the work, not the end: I kept monitoring the agents and improving them on real conversations.
What I track on my assistants
- Total conversations and how they split across agents
- Answer rate, with answered and unanswered questions reviewed
- Handovers to a person
- Knowledge base performance
Result
End to end
CustomerAsks on web or WhatsApp
→
RoutingPicks the support area
→
Area agentKnowledge and history
→
Backend APIsThe customer’s own data
→
AnswerOr a person, with context
More than 90% of conversations are automated. The busiest agent, and the one that relies most on backend API calls, handles about 13K conversations a month with an answer rate above 90%.
Takeaways
What I learned
- Split agents by who is asking. The audience shapes the answer more than the topic does.
- In payments support, access to the customer’s own data is what makes an agent useful.
- Plan the escalation path at the start. A clean handover is part of a good answer rate, not the opposite of it.