The power of unified front ends in banking

Özkan Erener from VeriPark explains how unified front ends offer banks the ability to unify all of their applications into one single screen, allowing them to serve customers faster and more efficiently

Guest
By Guest on 05 September 2018
The power of unified front ends in banking

This article was originally published in the Summer 2018 issue of The Record. 

A man comes running into a bank branch and says to the receptionist: “I’ve lost my wallet and I need to cancel all my cards, please help me.”

The receptionist calmly asks the man to take a service ticket from a machine and 15 minutes later, he finally manages to speak to a customer service representative (CSR) who says the bank can cancel his cards if he is able to give the card numbers. Giving a look of clear exasperation, the customer responds: “I don’t know. I lost them. I was hoping you would know.”

The CSR must then log in to the bank’s systems to find the customer’s card information. If the CSR was lucky, the bank would have had a system that offered a 360-degree overview of all the customer’s information on one screen, so it would have been quick and easy to cancel everything in one go. However, the bank does not have this system, which means that the CSR has to open the credit card application, find all the cards, cancel and then replace them one by one, before going through the exact same process in the debit card application. The CSR then has to log in to the core banking application to charge the customer a fee for replacing all of the cards. Unsurprisingly, the customer objects to the fees, so the CSR has to load up another screen to waive the charges and chase down the branch manager to approve the charge waiver flag.

Although banks frequently receive requests from customers to cancel one or more lost cards, most banks aren’t able to do so quickly. For example, at one bank that VeriPark worked with, the CSR had to open three separate applications and navigate through 11 different screens to complete the operation, before printing out four paper forms for the customer to sign.  In this instance if a customer walked into the branch to request a card cancellation, they would be lucky to leave in 30 minutes.

Unfortunately, this picture is common in our industry. However, there is a solution: unified front end (UFE). This is a single, unified interface to all of the applications that branch staff need to use to cancel cards, which means that that they would no longer need to launch multiple applications to get the job done. Unlike in the above scenario where the CSR takes 30 minutes to cancel a card because they need to log in to three applications, navigate 11 screens and print out four pages for the customer to sign, the UFE allows the CSR to log into one application, look at one screen and print out one page in less than 300 seconds. UFE turns the bank from being product centric to customer centric by ensuring that the customer’s needs are satisfied within five minutes.

Although this concept is so simple that it should be a no-brainer, UFEs in the banking industry are as about as common as UFOs. So, what prevents banks from building UFEs? I think I know the answer. 

VeriPark is currently discussing implementing a UFE with one of our customers. The bank needs to build 1,600 screens for its branch UFE by using code, but they need 200 developers to carry out the work. While this would be easy for a software company like VeriPark, it’s not so achievable for a bank whose core business is not software development.

UFEs are among the most complex types of software applications to create because they need to encapsulate core banking, credit cards, loan origination, investments and more. Banks have hundreds of applications and thousands of screens, so building a UFE using code should be their last resort. Instead, the UFE screens should be built using no-code development environments.

Luckily, software tools are giving us multiple no-code development options, but which one should we use? The debate usually shortlists business process management (BPM) systems, plain old development environments and customer relationship management (CRM) systems as contenders for building these UFEs. If the UFE was only supposed to make transactions, print statements and process bill payments, I would opt for plain old development environments or even a BPM screen builder.

However, these front ends are complex. Banks want UFEs to help them cross-sell, to fix compliance issues, alert them if a customer is missing a declaration and more. Banks want these front ends to do more than just cancel lost cards on a single screen, they would like to be able to sell, serve and solve client needs in that same screen. If the customer visits the branch or the contact centre to cancel a lost card, that screen is a great place to offer insurance protection against future theft of the new cards, or to trigger a complaint if there was a disputed transaction. It is also an ideal opportunity to double check if the customer’s address and mobile number are still the same. A UFE does the job it’s supposed to, but also does so many other things under the hood.

Only CRM systems have the feature set to cross-sell, ensure data quality, service agreements, provide a single view of the customer and more. BPM and plain old development environments don’t have these features in their DNA. For this reason, CRM systems are a great candidate to build UFEs that can turn banks into true customer-centric businesses.

Özkan Erener is CEO at VeriPark

 

Number of views (1625)/Comments (-)

Tags:

Comments are only visible to subscribers.