The app that couldn't finish the job
A customer opens her banking app to dispute a charge. The screen is clean, the flow is guided, and she submits it in under two minutes. Then nothing happens for five days. Behind that screen, someone in customer operations is pulling her case into a separate system, emailing the back office for evidence, and waiting on a queue she can't see. The app digitized the request. It never touched the work.
That gap is what customer operations in banking actually means: the connective layer that takes a request captured in a digital channel and drives it to resolution across front office, back office, and AI agents, without dropping context or reassigning it to a human every time a system can't talk to another system.
Most banks never built that layer. They built better forms. So the resolution still runs through spreadsheets, shared inboxes, and whatever core system happens to own that piece of the case. Jouk Pleter, describing what this looks like on the ground, put it bluntly: "We have to order a third physical monitor on the desk of our customer operations because it cannot fit in physical monitor - that is the big problem." A third monitor isn't a productivity perk. It's evidence that the operational bottleneck is architectural, not a matter of retraining staff or chasing a better CSAT score.
Inside the customer resolution loop
Every customer request follows the same basic path. A customer states an intent on a digital channel, a system checks whether it can resolve that intent instantly, and if it can't, the request drops into a queue for someone to finish by hand. Call this the resolution loop. It runs constantly, whether or not a bank has named it or built for it.
Most banks have automated the easy slice of that loop. Balance checks, standard transfers, simple disputes with no documentation gaps: these resolve straight through, no human needed. That's the part vendors love to demo. But the long tail looks different. A loan application missing one document. A KYC flag that needs a second look. A dispute that touches three back-office systems before anyone can answer the customer.
That long tail is where most operating cost and most customer frustration actually live. It spills into email threads, spreadsheets, and phone calls, because nothing connects the front-office moment to the back-office system of record. Banks keep buying tools to make the queue easier to manage. The queue isn't the problem. The missing connective layer between intent and resolution is.
Customer operations as an orchestration layer, not a helpdesk
Backbase defines Customer Operations as one of three pillars of Agentic Banking, alongside Conversational Banking and Relationship Intelligence, all running on a shared, AI-native Banking OS. Its job is to resolve complex work, the "Resolve" piece of the Serve, Grow, Resolve outcome banks are chasing this year. That framing matters because it puts Customer Operations next to how a bank talks to customers and how it understands them, not underneath a ticketing queue.
A helpdesk manages conversations about problems. Customer Operations manages the work that actually closes them out: verifying a document, updating a record across three systems, routing an exception to the right team before a deadline slips. That work has always existed. Most banks just buried it in back-office queues, spreadsheets, and manual handoffs that no customer ever sees and no system tracks well.
Backbase treats this as an orchestration problem, not a ticketing problem. Customer Operations connects the front office, the back office, and AI agents directly to systems of record, so a case moves through decisioning and evidence collection without stalling at a handoff. The interface a customer sees still lives in Digital Banking. What Customer Operations governs is everything underneath it: the routing logic, the audit trail, the exception handling that decides whether a case resolves in minutes or sits untouched for days.
What Backbase Customer Operations replaces
Most banks already have tools that automate pieces of the back office. RPA scripts click through screens to pull data. BPM suites route tickets between queues. Core banking vendors bolt on workflow modules to handle exceptions inside their own system of record. Each one solves a narrow problem, and each one stays trapped inside a single silo.
Backbase Customer Operations is built to replace all of that, not sit next to it. It displaces RPA tools, traditional BPM suites, core workflow add-ons, point solutions, and the custom in-house builds banks have patched together over the years. Those tools automate isolated tasks inside one system. Customer Operations orchestrates the whole journey, across channels and across business units, so an exception in onboarding doesn't stall out waiting for someone to check three separate systems.
That's the structural difference. RPA can move data from one screen to another, but it can't decide what happens next when a document fails verification and three teams need to weigh in. A BPM suite can route a case, but it can't reach into the core, the CRM, and an AI agent at the same time and keep evidence consistent across all three. Customer Operations does that by design, which is why it replaces the patchwork instead of adding to it.
Five flagship use cases still waiting for their own story
Five problems keep showing up when banks try to name what customer operations actually does: transaction dispute resolution, payment inquiry, complaint resolution, onboarding evidence collection, and KYC/CDD remediation. Each one looks like a support ticket from the outside. Underneath, each one is a case that touches multiple systems, needs evidence, and has a deadline attached to a regulation or a customer promise.
Onboarding and loan origination make the clearest case for what changes. Banks now treat the full application to activation flow as a customer operations problem, not a Digital Banking one. That flow includes KYC and AML checks, evidence collection, exception handling, and decisioning orchestration. The application form, the status tracker, the upload screen all stay in Digital Banking, exactly where customers expect them. But the work of chasing a missing document, routing a flagged application to a human reviewer, or reconciling a mismatch between what the customer submitted and what the core system holds happens in the orchestration layer behind it.
That split matters. It means the interface can stay simple while the case underneath gets more rigorous, not less. The other four use cases follow the same pattern: a clean front end, a governed process behind it that spans systems of record instead of living inside one. Each deserves its own detailed treatment, since the evidence rules, the exception types, and the regulatory clocks differ case by case. This piece names the pattern. The follow-ups will show how each case actually runs.
Why this only works when the CDO and COO think together
A customer's request for a mortgage exception or a disputed transaction doesn't know where digital ends and operations begins. It just moves forward or stalls. Most banks split ownership of that journey across two org charts that were never built to talk to each other. The Chief Digital Officer owns the interface. The Chief Operating Officer owns what happens after the click. Customer operations breaks in the gap between them.
Fixing this isn't a procurement decision you hand to IT. It's a question of who owns the resolution loop end to end, and that answer has to come from the top. Jouk Pleiter, Backbase's CEO, put it plainly on a recent episode: "Our most successful clients, the chief digital officer and the chief operating officer got connected and they're starting to think holistically." He added the part that matters most: "It starts with the customer, it ends with the customer." Watch the full conversation on The End of Account-Centric Banking.
That alignment changes what gets built. Instead of a digital team shipping a nicer form and an operations team patching the workflow behind it later, both sides design the same event-driven process together. The interface and the exception handling get built as one system, not stitched after the fact. Banks that skip this step end up with faster front doors and the same slow back rooms.
Governance turns agentic resolution from risky to regulated
Banks can't hand exception handling to AI agents without a way to stop them. That's the part generic automation tools skip. Robotic process automation runs a script until it breaks. It doesn't ask whether an agent is authorized to touch a specific case, and it has no way to intervene mid-task if something goes wrong. Customer Operations built on a Banking OS treats authorization as a checkpoint every agent has to clear before it acts, not an afterthought.
That checkpoint is what makes agent-driven resolution workable in a regulated industry. During a recent Backbase webinar introducing the AI-native Banking OS, a speaker walked through what happens when an agent tries to act without clearance: "it will basically block it, and the agent cannot continue. There's even a kill switch function that if the agent would still disobey, it will kill the agent and it will not execute. This is really critical to make sure that agents and AI can operate at scale in a regulated industry."
That kill switch isn't a one-off safeguard bolted onto a single workflow. It runs with full lifecycle management, tracking every agent action, authorization check, and intervention across the case. Compliance teams get a record of what an agent tried to do and why it was stopped, not just what eventually got resolved. That's the difference between automation you hope behaves and orchestration you can prove behaves, case by case, at scale.
As Tier 2/3 banks and credit unions decide where to spend their next technology dollar, the banks that connect the CDO and COO around a shared resolution loop will be the ones that turn exception handling into a competitive advantage instead of a back-office cost center.
Frequently asked questions
What is customer operations in banking?
Customer operations is the connective layer that takes a request captured in a digital channel and drives it to resolution across front office, back office, and AI agents without losing context. Most banks never built this layer, so cases still get finished manually through spreadsheets, shared inboxes, and disconnected systems of record.
What is Backbase Customer Operations?
It is one of three pillars of Agentic Banking on Backbase's shared Banking OS, alongside Conversational Banking and Relationship Intelligence. It orchestrates the resolve piece of Serve, Grow, Resolve by connecting front office, back office, and AI agents directly to systems of record so exceptions and evidence collection move without stalling.
How is Backbase Customer Operations different from a helpdesk or contact center platform?
A helpdesk manages conversations about problems. Customer Operations manages the work that closes them out: verifying documents, updating records across systems, routing exceptions before deadlines slip. The customer interface stays in Digital Banking, while Customer Operations governs the routing logic, audit trail, and decisioning underneath it.
Why can't traditional BPM or RPA tools solve the customer resolution loop?
RPA moves data between screens but can't decide what happens when a document fails verification and multiple teams must weigh in. BPM suites route tickets but stay trapped in generic queues or a single system of record, so they can't reach into the core, CRM, and AI agents simultaneously to keep evidence consistent.
What are the flagship use cases for Customer Operations at Backbase?
Five cases keep surfacing: transaction dispute resolution, payment inquiry, complaint resolution, onboarding evidence collection, and KYC or CDD remediation. Onboarding and origination are the clearest example, where the application interface stays in Digital Banking while exception handling, evidence chasing, and decisioning orchestration run underneath in Customer Operations.
