There is a growing interest in, and appreciation of the importance of, customer service in digital financial services (DFS), for reasons explained highlighted in the previous blog in this series  (See “In Our Digital Financial Service We Trust?”). GSMA recently released a code of conduct for mobile money service providers. CGAP is also playing a leadership role to understand and promote customer risk mitigation for DFS. As part of this, CGAP commissioned MicroSave to examine customer risk mitigation issues in three countries (Bangladesh, Philippines and Uganda). The key customer risk mitigation issues turned out to be core customer service issues that are affecting providers’ business – see CGAP’s report.

As can be seen from the graph below, three issues were common to all three countries, and another to just Bangladesh and the Uganda. And in these two markets also customers struggled to get their problems addressed through customer care. 

These problems are clearly having negative impact on both uptake and usage. Non-users and users alike look at the customer experience and worry about how reliable and trust-worthy digital financial services really are. The problems are also well known to providers, and so in this blog we examine why they often struggle to address and resolve these challenges – even when they are so clearly negatively affecting their business.

Service downtime, or the inability to access the system, appears to be a purely technological problem that should be relatively easy for providers to address. However, there are several challenges that underlie this and make it a much more complex problem than it appears.

First, in many markets DFS require the systems of multiple institutions (mobile network operators [MNOs], banks and 3rd party agent managers) to talk to one another. In these markets it is often difficult to pin point where the bottlenecks are occurring, and with regulatory authorities taking an increasing interest in system availability, institutions are unlikely to admit when their systems are causing the downtime. Unsurprisingly, MicroSave has seen several markets where multiple players are blaming one another for service downtime.

Second, if one or more of the institutions in the value chain does not receive adequate compensation for providing the services, they are unlikely to invest additional bandwidth to resolve the problem. Indeed, in some cases, players in the value chain may simply ration bandwidth availability on their systems. In Bangladesh a typical cash out transaction has five to six stages. If the customer is not able to complete all five to six stages within the 90 second time limit allocated by MNOs, the USSD session lapses and the transaction does not go through. Customers perceive this as a service downtime, however, technically it happens because of the USSD session lapse.

Third, as Fionán McGrath & Susie Lonie noted in “Platforms for Successful Mobile Money Services”, the first wave of providers, unsure of the likely returns from mobile money, underinvested in the systems to manage DFS. Providers not meeting their return on investment targets, or at least clearly on the way to doing so, are unlikely to sanction additional capital funds to upgrade their systems. But those that do should, if MTN-Uganda and Ericsson are to be believed, be able to make very significant improvements in the availability of their systems.

Finally, MNOs in Uganda note that agents without liquidity prefer to mollify their customers by telling them that “the system is down” rather than having to explain that they cannot conduct the transaction for want of float. This may be common in other markets too. Without regular and rigorous mystery shopping providers are likely to struggle to counter this problem.

Charging of unauthorised fees/over-charging is quite common but occurs for a wide variety of reasons. In the Philippines different agents charge different commission rates depending on the agreement they have reached with the provider. This is designed to allow rates to be competitively determined according market conditions – and thus permit those agents operating in hard-to-reach and thus service remote areas to charge more than those in urban areas. The different commission rates (which can theoretically range from 1-5%, but are typically in the 2-3% range) leave many consumers with the impression that some agents are over-charging. Providers wishing to address this would have to conduct an extensive above the line communications campaign with a complex core message.

In Bangladesh and Uganda, as in many markets MicroSave has observed, agents (again particularly those operating in remote rural areas where they have a quasi-monopoly) often charge additional unauthorised fees on top of the “on-the-board” rate (which is often not displayed anyway). This practice is especially common, and indeed accepted by many customers, for over the counter (OTC) transactions, where the agent is seen to provide a valuable service and to reduce risk by conducting the transaction. Addressing this, particularly in the context of agents’ incentives to foster OTC transactions, is likely to be a real challenge for providers. Again mystery shoppers and regular monitoring of agents by providers’ staff or third parties hired to do so, as well as a quality customer care call centre can address this challenge.

Agent liquidity is consistently the “hot topic” at The Helix trainings on agent network management – all types and sizes of agent network managers seem to struggle with this. As a result, the discussions and demonstrations of PEP’s float management system and the field trips to see PEP’s agents are extremely popular. Bangladeshi providers, led by bKash, have some of the most successful and sophisticated agent liquidity management systems that involve the delivery of liquidity to agents on a daily basis. These systems have been designed and implemented in the context of Bangladesh’s very high agent and population density, but could potentially be replicated in urban areas of most countries. First Rand Bank’s agent management system in Mumbai combines elements of these with credit for agents to allow them to hold higher levels of liquidity. For more rural areas, providers will need to look at new approaches to helping agents predict their liquidity needs better.

The fear, realised or not, of losing money by sending it to the wrong number is very real in both Uganda and Bangladesh. Indeed this fear is encouraging people to ask agents to conduct transactions for them – and thus an important driver of the growth of OTC transactions. For SMS-based systems this problem can be addressed relatively easily by linking the sender’s address book to the mobile money system (implemented in Kenya by M-PESA), so that the recipient’s name is displayed for each transaction. For USSD-based systems there at least three potential solutions, all of which present different challenges. The first (implemented in Uganda by Airtel) is to use the registered customer base to display the recipient’s name once the phone number is entered. This, of course, requires a comprehensive and accurate database of all customers, and (where there is inter-operability) will not work for customers registered on other providers’ systems. The second (implemented in Bangladesh by DBBL and GrameenPhone’s MobiCash) is to implement a check-digit system under which every mobile number is assigned an additional digit based on an algorithm.  As a result, if a wrong number is punched in, the transaction does not go through. The third, requiring the sender to enter the recipient’s number twice, prolongs the transaction and thus both undermines the customer experience and would aggravate the impact of any limitation in the length of the USSD session allocated to each transaction (see Service Downtime above).

Finally, the study highlighted that providers’ customer recourse – both through call centres and at offices – was viewed as difficult to access, poorly trained and often unable to resolve problems. Since agent illiquidity and the charging of additional unauthorised fees are increasingly accepted as the norm in these markets, customers with substantive problems most commonly call customer care when they have transferred money to the wrong number. DFS providers have consistently struggled with repudiation (see “Fraud in Mobile Financial Services” page 23), and have typically adopted a policy of “repudiation only with consent of both parties”. As a result customer care typically can do little to help customers resolve this issue. However, clearly defined, and well communicated, policies on repudiation, as well as free calls to better trained customer care centres can do much to improve this.

It is clear that these customer service issues need to be high on the agenda of providers intent on achieving high levels of registered uptake and usage of DFS (See “In Our Digital Financial Service We Trust?” blog). It is also clear that responding to the most common challenges is no easy matter, even for the most committed provider. Improving customer service, and thus the customer experience, will require investment in systems, communication, monitoring of agents and in the call centres that support customer service. The CGAP Focus Note “Doing Digital Finance Right: The Case for Stronger Customer Risk Mitigation” has a range of examples of solutions implemented across the globe. The investment in customer service is necessary, to establish a credible platform for both enrolling significantly more customers (as has been done in Kenya for example) and to get DFS customers to access and use a wide range of products. In the long run basic payment services, particularly when delivered as OTC services, will limit the profitability of DFS for providers – see GSMA MMU’s Mobile Money Profitability: A Digital EcoSystem To Drive Healthy Margins. So quite apart from the risk of the regulators turning their rhetoric (and, in many cases, existing regulations) into action, providers focused on the long-term profitability of their services need to address these core customer service issues sooner rather than later.

Leave Comments

*   can't be blank


can't be blank

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>