What better time to reflect on the sorry state of “customer service” than just after experiencing post-Christmas festivities at the local Shopping Maul? Actually, I don’t go to The Maul often and my wife doesn’t go at all. (Let me assure you that my wife does know how to shop—she just does it all on the Web. We can now blow right past the credit limit on multiple cards directly from the convenience of our own home.) But other than receiving January’s credit card bills, nothing is more discouraging than to personally experience customer “service” as it is practiced in the retail marketplace today.
I don’t know of many banks that aren’t making better customer service a priority in 2006, but what about the customer service bankers receive from their service providers? How well do your vendors do when it comes to providing excellent customer service?
Lots of banking vendors read GonzoBanker (we sure hear from them pronto when we mention them by name here at GB!) and we’ve decided to help them out with a few Gonzo New Year’s resolutions. We’re sure these 15 suggestions are just what the folks at Fiserv, Fidelity, OSI, Metavante, etc. have been waiting for!
Resolution #1: Custom modifications developed for one client that would be beneficial to others will be provided at no additional cost to all users in the next release.
Custom modifications often miraculously appear in a subsequent release as “chargeable enhancements.” Seems to us that if a bank pays for the development of code, that bank either gets its money back when those features are migrated into the base code, or the bank sponsoring the development gets to participate in any subsequent fees collected by the vendor for those features.
Resolution #2: We will not charge “professional development fees” over and over for a Max$ell MCIF interface.
Written once circa 1982, it now requires no further “development” and should be provided at no additional charge (if there’s anyone left who doesn’t already have it).
Resolution #3: We will make available migration plans and updated documentation in advance of the release, and we will provide a bulletin board with FAQs and contact names/numbers of clients who have already installed upgrades.
We know of one vendor that offers a product in both service bureau mode and as in-house software. Until recently, this vendor installed new software releases at the service bureau first, as a way to “validate” the revised software before releasing it to its in-house client base. Talk about not thinking it through! Why do banks use service bureaus? One huge reason is because they don’t want to be guinea pigs—they want someone else to work out the kinks. Service bureau clients sometimes pay a premium to NOT be pioneers. Wonder where this vendor had its head when it decided to force-feed changes to service bureau clients first?
Resolution #4: We will make new software releases available in a test environment first.
Do end users determine the test cases to be used in testing? Does testing consider both the front room impact and the back room impact of changes? Do end users—and certainly not vendors—do final acceptance testing on new software?
Some service bureau providers just “drop it in” with little advance notice. Others let fly with a new release without any availability of the software for prior testing by end users. There are more than a few that do this… and we think it is outrageous!
Resolution #5: We will provide bona fide user control over software development. Enhancements needed for sales purposes (such as to facilitate entry into a new market) will be funded above and beyond software enhancements needed by the current user base.
Most vendors don’t actually listen to their clients—they develop what they want to.
Resolution #6: We will promptly fix at our own expense errors, bugs, and omissions found in our systems.
There always seems to be discussion about what is a “bug fix” and what is an enhancement. If it doesn’t do what is described in the documentation, it is a bug. If it does something stupid, it is a bug. If your clients are getting written up by the regulators, it is a bug.
We have also seen vendors argue that they have no responsibility for changed regulatory requirements. Frivolous changes (can you say “Reg. CC”?) that go well beyond what anyone ever reasonably expected banking software to provide may be exceptions, but banking is a regulated industry and you’re already making lots of money off the industry. Just do it.
Resolution #7: We will provide telephone support during our clients’ customary business hours. We will even guarantee telephone hold times and response times via Service Level Agreements.
Hello? Weekend banking and extended hours are a reality in most markets, and those folks need help with their problems, too.
Resolution #8: We will provide direct access to specialists.
Nothing is more ludicrous than forcing all calls to go through a single individual. Banking is far too complex for any one person to have a broad-enough scope of knowledge to answer all questions, and we suspect that vendors who “channel” communications this way are more interested in controlling communication than they are in providing prompt and satisfactory resolution to problems.
Resolution #9: We will provide periodic Operational Assessments of clients”usage of our product.
Many vendors try to make Operational Assessments chargeable, which doesn’t necessarily make sense. (Clients should pay extra because vendors haven’t done an effective job of training their customers in the use of the system?) Business Strategy Reviews should never be chargeable, since the information gleaned should be highly useful to vendors who truly want to understand how their clientele uses a product.
Resolution #10: We will work to ensure that both local and regional user groups are user-controlled and well-attended.
The first usually results in the second. User groups are not sales opportunities. Do a good job (e.g. keep them happy) and the sales thing will take care of itself.
Resolution #11: We will provide a user-controlled facility that allows our clients to openly share information and issues about our products.
Take a chance. Your users are talking about you behind your back anyway, so make it easier for them and gain a window on the dialogue for yourself. You might be surprised what you can learn. (You’d be doing us a favor, too, since we currently act as the middle man for all this information.)
Resolution #12: Advisory boards will have a voice in future product design and functionality.
Advisory boards aren’t just for golf and fine dining. If you’re not getting good information, the wrong users are participating. Invite more worker bees and fewer queen bees.
Resolution #13: Computer-based training (CBT) or Internet/intranet training capabilities will be made widely available. We will provide tools to empirically measure the proficiency of those trained.
Management reporting that gives an account of who’s completed training and what their level of comprehension is should be available. We’ve actually had vendors—and customers—argue about the necessity for measuring the results of training classes.
Resolution #14: Just as our customers try to support their clients through whatever delivery channels they prefer, we will provide support via e-mail, Web access, and other on-line support mechanisms.
There should be documented and monitored turnaround times for e-mail and other on-line support. Frequently Asked Questions (FAQs) should exist and be updated regularly.
Resolution #15: We will install an account management process which requires that an assigned representative meet face-to-face with bank management on a regular basis.
ALL outstanding problems and issues should be discussed at these meetings, and there should be well-defined follow-up and escalation procedures for problems that cannot be resolved at this level. Account managers’ territories should not be so broad that they cannot be intimately aware of the status of every client’s issues. Clients should receive a periodic copy of all incidents and their resolution, and reports regarding “routine” calls, which contain information such as date opened, date resolved, and an explanation of how issues were resolved, should be generated monthly.
GonzoBankers, how many of these Best Practices does your vendor provide? We hear all the time (in sales presentations, of course…) that they always do this, and much, much more. We’d love to hear from you if your vendor actually does these things!
-bm