Customer service: Improving efficiency and service excellence

Click here to view an edited video of the discussion

The Participants

Howard Boville, Head of global banking of BT

Gary Bennett, Director of service provider development of Avaya

How has the process of communicating with the customer changed and developed in recent years?

Howard Boville: It has changed significantly. The number of channels has increased and there are more ways of actually accessing the bank to get information. In addition to that, the rise of the internet has put more information out there. So information is a lot more available to customers and they are a lot more banking savvy as a result: this has not only increased the number of calls that are put into the contact centres, internet channels and the bank branches, but also the nature of the questions have increased in complexity.

The growing number of channels must have increased the complexity involved when communicating with a customer: how are the banks responding to this?

Gary Bennett: Traditionally, a lot of the infrastructure has been built up around silos - whether that is different businesses within an organisation or different product streams. What this has meant is that very often, when a customer has interacted with their bank, the person they've spoken to has had a very narrow view, and customers are now looking for the bank to have a complete view of their position with them. Many banks are now leveraging the technology to align these communications - this not only leads to a greater customer intelligence and swifter resolution of inbound contact, but also reduces siloed activity and therefore costs.

Are infrastructure challenges primarily to blame for poor customer service where it occurs?

GB: Some of those infrastructure challenges have certainly led to poorer service, in the eyes of customers. For customers, that typically plays out in terms of not being able to get access to the right person with the right level of expertise, and for the banks, that means not being as agile as they would like to be in terms of the way they deploy their staff. So infrastructure plays a part but I think we are at a stage now where we can help organisations to overcome that.

HB: There are a few elements that firms need to think about: the technology legacy systems they have, the applications that support that technology infrastructure, and the third area is around the people, that is, the organisational design. Unless you get those three areas into alignment, you cannot offer the single customer experience. To make that work, you need business cases and therefore the customer experience needs to be seen to be driving greater profitability for banks. More often than not, that profitability comes from existing customers. So if you can retain existing customers through a positive customer experience you get into a virtuous cycle.

Typically, how can banks hope to increase efficiencies in their communications infrastructure?

HB: We look at the volume of calls coming into an organisation, we break that down to look at the volumes in terms of the nature of the calls that come into an organisation, and then based upon their nature we actually align a financial value to them. For example, if they are interactions then they have a particular financial value; if they are transactions then clearly they have a very definable financial value to the actual organisation. We then look at the most efficient means of handling those calls, but the final decision on how to handle those calls needs to be made by our customers, because some very efficient means may not enhance the customer experience or may not fit within the brand identity of the organisation. Once that decision is made, you can get into all of the details in terms of what the infrastructure needs to look like.

If a bank was building its customer-facing communications from scratch, what would be the ideal operating model?

GB: From a technological point of view, we would be looking at encouraging an organisation to centralise that core platform and the applications, but to decentralise the agents who work on that platform. What this really means is that a bank can roll out new applications fairly quickly, it becomes very scalable, and it also means that the bank can be very agile in terms of where it deploys its workforce. That can have a big impact in terms of employee retention and satisfaction. So, the model needs to be resilient and centralised but also serviced by human resources that can be accessed across a variety of different areas that can be adjusted as needed.

HB: In terms of decentralising staff, the model means that the bank can be more flexible in terms of their employment. A bank could have people situated in contact centres or they can be situated at home, and that sometimes meets the call profiles that certain customer groups have. We found that one customer had a lot of calls early in the morning, a lot of calls late at night and not very many calls during the day. It was very difficult to get the shift patterns in place. But, if they had home workers with the technology piping the call-centre functionality to them, it would mean they could employ different demographics and different groups - people with disabilities, people with young families - which in turn would better serve the bank's needs.

But does flexibility where the workforce is concerned necessarily translate into up-front cost advantages?

HB: If a bank wants to increase the number of agents, it can increase on a per-port basis, or per-user basis, or per-seat basis. But equally, if there isn't high demand for a particular period, or the bank is not running all the same sort of marketing campaigns, or there isn't just one sort of customer requirement, it can scale down its costs on a unit-cost basis as well. That's a really important benefit for the finance community. From a contact centre manager's perspective, it means they can actually have one dashboard of the key metrics and offer a better customer service as a result. They can get the right shift patterns in place and monitor their call volumes and call floors a lot more effectively. In the case of the end-user customer, the centralised model means that they are able to get through more easily - they don't have to wait in queues because they are not tied into one contact centre that has a limited number of people - they've got a global pool of call centre agents that can service them.

There has been a lot of disruption in the marketplace during the past year: is this model able to stand up in the face of a major business disruption, such as a sudden merger or acquisition?

GB: The beauty of the centralised model with a decentralised workforce is that, as you potentially acquire or merge with other organisations, it can become very simple to take out overlapping technology and cost, and roll out some of those centralised applications to those new organisations. The other advantage of the model is that when you are trying to react to certain economic events, you have the ability to be very agile in the way that you respond: this means you might be able redirect staff that are working on one function to a more urgent function, or to mount an outbound calling campaign in response to an event that has hit the press. That carries substantial advantages.

If a bank attempts to move from its existing set-up to a centralised model, what are the operational risks involved?

HB: The key issue is ensuring that you've got availability - so you need to build redundancy into any platform that you build because if you have a centralised function you've potentially got a single point of failure if you don't architect that solution properly. If any component fails, you can't afford that to bring down your customers' access to your call-centre agents. But with a correct architectural design you can avoid that - you can have sufficient redundancy to ensure that access is always available. How long does that take? It depends upon the size of the organisation but the key element is the technology planning stage, which ranges from about six weeks to three months to get the architecture correct, and then the roll-out, which typically takes about 24 to 36 months to get the architecture bedded in.