I find myself increasingly frustrated by bad customer service. It’s disappointing when bad things happen, but they always will—that’s not my complaint. My grievance lies in the call to resolve where the wheels fall off. The customer service experience, not the actual product or service, is making me question my vendors.
After a recent interaction I had with investment firm Charles Schwab, I decided to write this post. I’ve been a customer for decades, and I believe their core services to be very good. However, I find myself questioning my long-term relationship after just one call.
My recent encounter involved my security token, a small device (see image below) that generates a one-time password when I log into schwab.com. The device displayed a low battery warning, and because these are inherently disposable devices, I had to request a replacement.
I initiated the request by sending an email to a contact at my local Charles Schwab branch. It’s not necessarily their problem, but most of us are programmed to avoid the main toll-free number for any business — even a routine request. A contact replied, saying he initiated the process, and I should receive a support call soon. He even provided the caller-ID information that I should expect. I then received a call from “Jonathan at Schwab.” I put that in quotes because I still don’t know if it’s true, but that’s what he said.
Jonathan offered to replace my token if I authenticated myself. (Ruh-Roh). Authenticating a customer over the phone is problematic for many reasons. For example, I told him I already logged into the portal if that helped — it didn’t. Jonathan wanted to send me a code via text message, but when he asked for my cell number, I refused to provide it. Why should I give my number to him? Not only had he called me, thus I could not be sure he was who he claimed to be, but it’s hardly a valid test if I provide the number. He then said he sent a code to my number on record, but it never arrived. I probably should have ended the call there.
Most contact centers attempt to authenticate with personal trivia — questions only I should know the answers. That’s becoming increasingly difficult in our hyper-connected world. The mother’s maiden name test isn’t as reliable as it was 50 years ago. Instead, he asked me to validate the balance of one of my accounts. I offered to validate the last four digits (that seems reasonable to me), but he said that wasn’t sufficient. I provided a balance, but the more I think about it, the more I regret that.
Jonathan said he still required a secondary test, and this is the one that pushed me over. He asked me to tell him the one-time password displayed on my current token. There’s a lot of problems with this request. First, the token device isn’t secure. It doesn’t require a password to display the code. More importantly, the request violated a golden rule of security—support staff should never ask for a user’s password—even a one-time password. Granted the code alone is not sufficient for access to an account, but it’s a key component that should be shared with strangers.
If Jonathan was a bad guy, and he may have been, giving him my current one-time password may have been just what he needed to access my account. When hackers obtain critical information by simply asking (me or others), It’s called social engineering, and it’s a big problem. People often get duped into giving out what appears to be non-critical information. Social engineering is key to the recent
SolarWinds hack. So far, in this conversation, a stranger Jonathan has now asked me for my cell number, my balance, and my one-time password.
Asking for the displayed code also implies that he can match it to something. Can support staff really see my one-time-password? The same question applies to my account balance too. We tend to view financial institutions on a security pedestal, but as my colleague and fellow No Jitter contributor, Sorell Slaymaker, says, “banks were so early with security that they often have obsolete practices today.”
After I refused to provide the code, he more or less gave up and suggested I contact someone at the branch. Curiously, that’s exactly where I started. I sent my contact another email. He called and said he would get the token replaced. Evidently—authentication was optional. I also asked about “Jonathan from Schwab.” This person was confident the representative I spoke with was indeed Schwab support.
It’s easy to see the problems here, so let’s turn to better practices. The first issue is they called me and asked me to authenticate. When receiving a call, we need to authenticate them too. The better approach is the customer should call. All contact centers should insist that the customer call a known, published number before they provide sensitive data. All vendors should teach their customers not to trust Caller-ID or believe callers that self-identify as authorized representatives. As a courtesy, they should offer a shortcut through the interactive voice response (IVR).
Authentication is hard to prove over a standard phone line, but there are some options besides personal trivia. An emerging trend is to use voice biometrics. I have since learned that Schwab does offer this, but I need to request it. Here, a speech processing bot authenticates the caller based on a recognizable speech pattern. Some do this passively after monitoring a conversation, and some request the caller to speak a specific phrase.
Both Amazon and RingCentral mentioned voice biometrics in their Enterprise Connect 2021 keynotes. Voice biometrics works well. Some organizations even scan all incoming calls for known scammers. Voice biometrics offers a simple form of authentication, however, some organizations may want additional authentication measures depending on the situation.
A common best practice is the use of a separate channel, The simplest is a verification code texted to the user’s smartphone. However, this relies on the mobile provider’s security practices. A better option is for a vendor to use their own mobile or web app when possible.
The contact center as a service (CCaaS) provider UJET heavily promotes this model and offers its CCaaS customers a mobile software development kit that allows developers to integrate apps with the contact center. This approach can also enable the use of a smartphone’s fingerprint sensor or camera.
Another concern from my example above is how much information is available to support teams. With the increase of security hacks occurring, it’s becoming a better practice to (severely) limit employee access to customer information. Zero knowledge models separate the outcome, authentication in my example, from the test and response.
Journey.AI has several zero knowledge solutions for contact centers. Let’s go back to the account balance question for a second. I’m more comfortable sharing sensitive data with a machine than with a human. Think of this situation like your ATM PIN code—we readily share it with the ATM—but it would be odd if a human teller asked for it. In this case, a bot can query me to verify my balance. The caller’s authentication status can be displayed on the agent’s desktop. It’s called Zero Knowledge because the agent doesn’t necessarily know the question and certainly not the answer.
Nearly every week, a major, trusted brand gets hacked. In some cases we are powerless victims. Though it was years ago, the
Equifax hack illustrates this point. Hackers stole the personal details of 147.7 million Americans, and the majority of these victims had no business relationship with Equifax.
As customers, we must remember we’re not always powerless and should exercise our voice when appropriate. That doesn’t necessarily mean dumping long-term relationships. There’s no assurance the replacement vendor will be any better. The better first step is active vocalization. Be heard, let them know when the service or process is unacceptable. It’s in everyone’s best interest to find the path of least resistance.
Dave Michels is a contributing editor and analyst at TalkingPointz.
