First National Bank (FNB) is the second largest financial institution in South Africa. Formed in 1998, the bank has grown significantly over the years, both through normal growth as well as acquisitions. Still, despite the rapid growth, the bank has prided itself on technology and innovation to compete in today’s demanding markets, largely investing in applications for mobile and banking apps that expand their access to customers. Their efforts at innovation have paid off as they were awarded the World’s Most Innovative Bank for 2012.
Earlier this month, we had the opportunity to talk to Mark Jeffery and Ramon Nogueira, 2 of FNB’s application architects behind their call center, about how they are automating many of the customer processes. A new telephony platform was introduced and has greatly improved customer service levels, speeding up the amount of time a customer must wait on the phone to resolve their enquiry or perform a transaction. One of the secrets to speeding these transactions up was to separate the telephony platform from the CRM system, and place a messaging broker between them. After careful consideration of several potential tools, including ZeroMQ and HornetMQ, FNB decided to use VMware’s vFabric RabbitMQ.
Why Insert RabbitMQ?
When asked why they introduced a messaging layer, and specifically RabbitMQ, they were quick to answer, “To decouple the CRM from the telephony platform and to provide high availability and redundancy.” Simply put, the bank needed to make sure that downtime of the call center was minimized. Redundancy became a requirement, so they clustered their servers. However, they also needed to make sure if a cluster was removed to troubleshoot or update, the system would simply redirect traffic gracefully. To do this, the telephony platform needed to become loosely coupled with the CRM, and transactions between them needed to be asynchronous. So, a messaging platform was needed.
While looking at messaging options, RabbitMQ stood out because of its support for high availability using clustering, and specifically for how it performs mirrored queues.
Additionally, RabbitMQ appealed to FNB because it also adheres to the AMQP specification. This is important to FNB because it will allow them to easily integrate their telephony platform and CRM to other systems in the bank, because of the adherence to a standard. There are many systems in the bank that will integrate with the Contact Centre.
RabbitMQ is also written in Erlang, the programming language used in telecoms, banking, e-commerce, computer telephony and instant messaging applications to build massively scalable and highly available real-time systems. With this history, FNB saw RabbitMQ as a good fit in a telephony environment.
In just 3 months, the FNB team set up a few hundred RabbitMQ agents that access a front-end and integrates with the telephony platform. The delivery of messages back and forth between this front-end and the telephony platform are high-volume. Any delay in the real-time processing of these messages has a direct impact on customer service levels, increasing the amount of time each customer has to wait on the phone before being services.
When asked about what benefits of using RabbitMQ has provided to their call center operations, Nogueira and Jeffery cited benefits for both the business and IT:
- For the call center—Higher service levels are achieved by shortening the time users are on the phone and the system stability has increased meaning lower incidence of technical problems during a customer call.
- For IT—They are more aware of the number of agents that are connected at any time, as well as the volume of messages processed. Moreover, if there is a problem with a server instance and it needs to be restarted, the agent front-end connectivity is not affected at all.
When asked if Nogueira and Jeffery would choose RabbitMQ again and recommend others to use it, they quickly replied, “Yes. The installation is not complex and the stability and performance are second to none.”
When asked what they would do differently the next time to improve the implementation process if they had to do it again, their advice was, “We think one of the lessons we learned was to keep it simple and not worry upfront about every possible way that messages could be lost or duplicated, but rather handle those as rare error conditions.”