It is one thing to reprimand associates for bad behavior, however another if you are doing it without any knowledge of how the issues occurred. With any project I research it is not to call out anyone, but a way to look at a process, improve on it, then coach or redefine a new behavior to obtain the needed results.
Here is how to look at breaking down attrition: Accounts close all of the time for many many reasons, however of all of the reasons, can we determine if they are life cycle, process issues, relocation, death, divorce, a closing of a location, personnel, ingress, egress issues, NSF or anything that force the client or the institution to close an account.
What you will find is that of the 10% to 25% of those clients that attrited, most are issues beyond ones control, however what this exercise will accomplish is of those that can be controlled if fixed can it change the retention rates.
I must add a simple note here. At times depending on your clientele, attriting is not a bad idea. I'll leave the deeper aspect of identifying profitable clients to a separate blog, however sometimes retaining clients just to retain them is not always a good thing. That is why it is so important to research all aspects of attrition before coming to conclusions. This information is to identify issues then to fix them...not a way to hang and burn people.
You are first going to have to find a way to collect data from the front line. If your core system has the ability to collect reason codes that will be your best bet. It may be as simple as an open field that you can use, however contact your IT group to find out.
Our sales group implemented the first go around and boy was that a failure. The attempt was knowable, but the results were a mess. In their defense they gathered the troupes and implemented the data collection process, however that is about a far as it went. It got better, however keeping 1,500 associates capable of entering data informed as to the process, and the churn factor of employees just didn't help.
Keep this in mind when working with data and lots of it there has to be commonalities so one can work with and review the results quickly. Problem #1 the sales staff chose a alpha numeric field to enter information in. This is fine if you truely want to read about the issues, however disastrous if you have 4,000 closed accounts in a month and they all have different verbiage. The only way to review the data is to look at it and try to match it in silos. It is just not going to happen.
I quickly made a change to the input of data. With the help of the sales staff I asked for as many common issues we could think of then I assigned a numeric code to each.
They were as follows:
1 - Rate
2 - Facility Closure
3 - Moving out of the market
4 - Account funds used for purpose intended
5 - Deceased
6 - Removal of name
7 - Dissatisfied with service
8 - Dissatisfied with product
9 - Competitors promotion
10 - Convenience - moving within the market
11 - Transfer funds to another account within the institution
12 - Divorced
13 - Other
14 - NSF/Overdraft
15 - Married
16 - Fraud
17 - Dormant
18- No longer needs accounts
19 - Lost job
If you are looking to implement such a program use these only as guidelines. You may need to begin with a few then add as needed. I provided a simple sheet that could be posted close so they could refer to it as often as needed.
After implementing these new standards it became easier for both sides. It was less work for the associates and for me I could now do something with the data. We still struggled with even this part for some associates who felt they were being helpful would instead of just entering the number they would enter "#12" or "number 12" instead of just "12." If I had the capabilities to change the field to just numeric I would have. If you can, do it.
I was able to identify those associate issues and then passed that information on to their branch manager. After some time it got better.
 |
| The results in graph form allowed myself and associates to quickly see where the issues were. |
Once a month in the core system I had a query run in periodic options that would collect the information I needed to build the report. I was able to through Excel build a path through an ODBC function with iSeries that after building macros would shake hands with the query grab the data then bring it back and configure the report they way I wanted to see it and deliver it in graphic form for the company and by branch. This report could be built in seconds each month.
The report provided results in three multiple ways: 1. Numerically providing numbers associated with a graph. 2. The same results, however in graph form. 3. The numeric data was broken down by branch. 4. Each code was given a factor as to if an associate could have changed the behavior of the client which became "issues." A percentage was provided as to of all the closed accounts what percent was the branch in control of. 5. Where and who the data came from.
I must bring back once again how important it is for you to learn Excel. This report on its own could take several hours to build, however once set up it takes longer to open the report than it does to run it. Learn your core or find someone in IT to work with you. Have them look into iSeries or ODBC in Excel to connect with your core system. Learn how to build macros in both your core and Excel. And also learn how and understand pivot tables.
It will be hard at first, however once you get the hang of it you will be able to understand the data, build it quickly and start spending more time analyzing it.
If you need additional help please feel free to contact me through e-mail
No comments:
Post a Comment