Home / BA / RCA_Financial Institution.

RCA_Financial Institution.

 

This is the first in a series of blogs in which I will share some of my thoughts about good complaint RCA practices observed in the course of our work across a wide range of firms.

The problem of relying on complaint categorisation when performing RCA

There are many sources of data and management information which firms could analyse in order to understand what is negatively impacting their customers, for example, retention data, cancellation rates and customer feedback. However, the primary source for most firms remains the root cause categorisation which is commonly applied by complaint handlers during or after the complaint resolution process (it should go without saying that using complaints data as a primary data source is limiting in terms of conducting effective RCA).

In my experience, the categories presented to the individual logging the reason for the complaint can be confusingly arrayed, not necessarily easy to understand or informative, often duplicated and can be myriad (sometimes numbering in the thousands!).

What this can lead to is individuals defaulting to their ‘favourite’ categories or at least the ones they know best and often ignoring the more appropriate and relevant category. When conducting our own reviews to support our clients, we have regularly found that the first category in a drop down list is disproportionately applied.

The risk this can present is to skew the data analysed during the start of the RCA process, potentially leading to bigger and / or more customer-impacting issues being over-looked. This is especially pertinent to firms whose sole source of complaints RCA data is derived from complaint categorisation.

What is the solution?

Complaint categories could be more intuitive and supported by decision trees and guidance providing a clear definition, including examples where relevant, to aid consistency of understanding and application.

For example, complaint management systems should ideally offer (at least) three categories to provide the granularity which supports useful RCA. It won’t necessarily get you to the ‘true root cause’ because that requires the RCA analyst to conduct detailed analysis, e.g. field work, business owner interviews, to determine. However this approach may significantly increase the chances that the analysts are looking in the right direction as well as providing a good sense of trending areas.

This then also allows firms to structure their categories intuitively.

  • Level one > where did it go wrong?
  • Level two > what part went wrong?
  • Root Cause > why did it go wrong?

Level one categories will describe the where of the complaint (i.e. the umbrella grouping where the cause of the complaint is attributable – depending on the business, this might be broken down into individual customer journeys, processes, product types, or business areas). This can aid high level analysis of the areas where issues (giving rise to complaints) are located, which should in turn prompt extra focus on hot spots. The number of options under level one should be strictly limited.

Level two categories will describe the what of the complaint (i.e. the specific subject the complainant is complaining about). This may provide a more detailed level of data on the specific drivers of complaints (but not why they are causing complaints).

Root Cause categories will describe the why of the complaint (i.e. the cause of the complaint). This may provide insight into the underlying cause of the complaint and point the root cause analysis in the right direction to determine the original trigger (or root cause) of the complaint.

To ensure that the data used to drive the root cause analysis is correct, each of the level one, level two and Root Cause definitions should meet the following three principles:

  • Is the definition clear and easy to understand?
  • Does the definition actually tell you something?
  • Is the level of detail in the definition reasonable for the user to know?

To put this into context, an example is below:

Complaint Primary Reason Secondary Reason True Root Cause
A customer complains that he has been charged a fee for making a late payment towards his mortgage The user selects from a small number of options, in this case they select ‘Product‘. The user selects from a small range of pertinent options, in this case they select ‘Charges & Fees’.   Having investigated the complaint the user is comfortable that the customer was provided with a copy of the terms and conditions which illustrated any penalty charges so they select ‘Terms and conditions applied correctly – customer believes unfair or unreasonable’.

What are the benefits?

The above example should result in meaningful information for the RCA team and lead them to ask the question ‘Are our penalty charges illustrated in the terms and conditions prominently displayed and are they clear and not misleading?’ Remedial action can then be taken if the answer to either part of this question is ‘No’.

Further, each of the root cause categories may be effectively utilised to provide differing levels of analysis and insight:

  • Level one categories: high level trend identification and possible horizon scanning for emerging trends.
  • Level two categories: functions or areas which are driving complaints and identification of high reward opportunity areas to focus deep dive analysis.
  • Root Cause: pinpoints the specific issues that are causing complaints within a function or area.
  • In a world so affected by constant change and so vulnerable to the interface of human, software and hardware issues that can cascade into a management nightmare in seconds, some financial giants have elected to deploy the advanced capabilities of REASON integrated root cause analysis, corrective action tracking and lessons learned as a hedge against future operations problems.
  • The financial community at large finds itself increasingly vulnerable to both automated transaction issues, compliance issues and market change issues. Problem management in the financial field has become a designed, coordinated and aggressive activity requiring fast answers, a view of the systemic sources of problems, a view of developing trends for planning and solid decision support, and access to lessons learned data in order to benefit from the knowledge gained from past problems. REASON is the ideal problem solving concept and tool for the financial community because the foundation of capabilities is exact, verifiable and validated data.
  • In the financial world, you will not hear talk about approximate interest rates and terms, or estimated balances and due dates, nor will you find a tolerance for investments in guesses and assumptions. REASON problem solving is structured by logic rules and supported by criteria for accuracy and completeness. The repeatable process and objective answers of the REASON System replaces the inherent weaknesses of subjective approaches that permit and rely upon personal opinion, brainstorming, debating and voting for answers. With REASON there are no trial balloon remedies in an environment that cannot afford “wait-and-see?” solutions.
  • Service industries set apart from manufacturing and process industries have special issues that often center upon personnel conveying and maintaining necessary services upon which other companies depend. This vital linkage can represent critical loss potential for both the service organization and its client. There are several significant issues with which any root cause analysis approach must deal in such relationships.
  • Perhaps in this field, the most important is the need for the problem solving method to deal objectively with the human behavioural aspect of the problem and in the same context as the elements of equipment, materials, processes and environment. Typically, however, when human performance enters the picture, it is common for subjective problem solving approaches to move strongly toward subjective assumptions and contrived remedies. Here REASON demonstrates one of its most powerful capabilities, the ability to understand the core issues affecting an individual’s performance and behaviour on the job, and to manage those factors for prevention and control.

 

About Sudhir Kumar Sahu

Check Also

What is BRD? How is it different from SRS?

BRD stands for Business Requirements Document, whereas SRS stands for Software Requirements Specification. Both documents …

Leave a Reply

Watch Dragon ball super