Improving Call Centre Security: ROI and Business Case Explained
Looking to optimize your call centre security processes? Matt Smallman, the author of Unlock Your Call Centre, illustrates how to boost your security performance and demonstrates the ROI and Business Case to justify the resources required for this enhancement. An essential watch if you’re looking to build a cohesive and convincing business case.
The video further explores the Return on Investment and Business Case for improving call centre security processes. Using simple, industry-related metrics, Matt demonstrates how to quantify the financial opportunity presented by improving security. This segment offers a clear path for organizations seeking to convince stakeholders of the need for investment in security improvements.
One highlight of the video is the practical online tool available on our site. This tool allows you to enter your specific call centre data and then model potential outcomes based on principles discussed in the video. You’ll get a clear sense of possible improvements and their impacts on your bottom line.
Whether you run a call centre or you play a part in its operation, this enlightening webinar will guide you to enhance your organization’s security processes. Make the most of this learning opportunity to elevate your call centre’s performance and secure your customer’s trust. Get started by watching the full video now.
Matt is the author of “Unlock Your Call Centre: A proven way to upgrade security, efficiency and caller experience”, a book based on his more than a decade’s experience transforming the security processes of the world’s most customer-centric organisations.
Matt’s mission is to remove “Security Farce” from the call centre and all our lives. All organisations need to secure their call centre interactions, but very few do this effectively today. The processes and methods they use should deliver real security appropriate to the risk, with as little impact on the caller and agent experience as possible. Matt is an independent consultant engaged by end-users of the latest authentication and fraud prevention technologies. As a direct result of his guidance, his clients are some of the most innovative users of modern security technology and have the highest levels of customer adoption. He is currently leading the business design and implementation of modern security for multiple clients in the US and UK.Only available to signed-in members
Matt: We’re going to split today’s session into two parts. First, we’re going to look at current performance of your security processes to understand what the baseline is, and then we’re going to look at the opportunity for improvement using modern security methods. So we only have 30 minutes, so it’s going to be very much a whistle stop tour of these key areas.
But fortunately I do cover all of this and more in the book, in my book. And there’s plenty of additional insight and context and detail that we just won’t have time to get to today. But hopefully today’s session should give you everything you need to get started to understand what the business case is to improve your call center’s security processes.
Matt: One of the main issues with making the case for better security processes in your call centre is that it’s really challenging to separate subjective and objective measures of security process performance. Often we inherently feel that some security processes are bad, but it’s hard to articulate why.
Sometimes those reasons are obvious. They take too long, you couldn’t pass, but other times it’s like they just didn’t feel secure, or usable, or friendly. And our challenge is to convert those into a rational case for change. Those emotional aspects though that we may not spend as much time on today are still critically important to winning support and getting the case over the line for investment.
But we have to start with hard facts and that’s what we’re going to be doing today.
Now, when I think about security process performance, I use these three dimensions. Usability, efficiency, and security. Usability is about how hard or easy the process is to use for all its users. Importantly, in the call center, this includes customers and agents. And efficiency represents the action and opportunity cost of the security processes, most often measured in time.
And finally, security is obviously how effective the process is at achieving its objectives, namely keeping attackers out.
Matt: We’re going to look at each of these in a little bit more detail, starting with usability. Now, I always start with usability quite consciously because I consider it the primary performance dimension of any security process.
Because without it because both efficiency and security flow from it principally. A process can be secure but not usable. And if it is, then no one’s going to use it, or be able to make effective use of the services that sit beyond it. And if a process isn’t usable, then it’s likely to be very inefficient and may, and customers may avoid it, and therefore use other methods that are in turn less efficient.
Secure than they might otherwise have been.
Unfortunately, usability is also the hardest of these factors to quantify. At the simplest level, usability could be thought of as just a proportion of genuine callers who are incorrectly rejected, the false reject that you’ll see in the diagram here. So genuine callers, genuine customers who are rejected.
To make this harder though, in many cases, this isn’t terminal. It will inevitably lead to some additional time, frustration on behalf of the customer and possibly your agents. It leads to effort and maybe even resentment on behalf of the caller. But often there are other ways of getting the caller through security processes albeit with that additional cost not necessarily financial but psychological.
Or the customer will experience some degree of service degradation. Denial of service is not something that many organizations do, but the actual act of failing security several times or retrying or having to call back can have a pretty significant cognitive load on on callers.
And it also, yeah, so it does belie that kind of. Significant kind of efforts that the caller puts into and forced to employ to complete the process. And in my experience, that most often manifests in willingness to engage with self service features or with acceptance of offers and sales that may occur later in call.
In many organizations, users who fail to complete the authentication process are assumed to be attackers, when in practice, and from the data that we see, even in the highest risk organizations, the vast majority of, if not all, customers who, fail authentication processes are genuine customers. Just unable to complete the process.
So we can assume in most cases that the false reject rate that your organization experiences is pretty close if not the same as the total rejects or the total retries that you see within your call center’s security process.
Matt: The next dimension I want to look at then is efficiency. Fortunately, efficiency is significantly easier to quantify. And with most, as with most things in the call center, efficiency really comes down to time. Obviously, the amount of agent time that might be spent on identification and authentication.
But also, and we see this almost certainly more significantly, and sometimes orders of magnitude more significantly, the call time, total call time spent servicing customer requests that could have been serviced, could have been handled by automated solutions if the customer had been authenticated before connecting to an agent.
It is really truly incredible, and we see new advances every day now of what natural language understanding and AI based tools can do to service customers with automation in a beautiful Magical sometimes experiences, but the key constraints of many of those is that we need to know that who the customer is and be sure that they are who they claim to be before we can act on them in those cases.
So without knowing the who the customer is and being sure about it, it’s hard for many of these solutions to be much more than a glorified FAQ bot that you could otherwise have on your website.
Matt: Now, I’ve been quite careful to make a distinction between identification and authentication because for me, they are two separate process steps within the security process. They’re often conflated together as ID& V or security, but in practice they can actually take place independently during different parts of the call. Yes, you need both in many cases to service the customer and do what you need, but they can be done separately.
For example, callers can be identified in IVR or in automation by the phone number they called in on. But not every caller can be done that way, so some may need to speak to agents. But not many callers can be authenticated in that manner, and therefore they may need to come to agents. So we have the identification step taking place separately from the authentication step, and we’ll see why that’s important later.
Just to clarify, in my vernacular, identification is the process step of determining which customer in your system of records this caller is claiming to be, and authentication, which is sometimes also known as verification, is the step of determining that the caller is who they claim to be. As we’ll see later, we need to understand both of these in order to build our model.
Matt: Also in efficiency, outside of agents costs, there are some other costs that it’s worth considering and attempting to measure. There is obviously the cost of provisioning and knowledge and possession based authentication material, which may include letters text messages, or delivery of physical tokens.
And we must also not forget the cost of handling reprovisioning of those materials, resending of physical tokens, or resetting of passwords and the agent time that might be spent doing that.
Obviously, there is the cost of any fraud, not just that which occurs in the phone channel but the fraud that is enabled by the phone channel that takes place elsewhere.
And we had a fascinating discussion with Abhinav from Smart Numbers a few weeks ago just on , how frequently fraudsters use the phone channel to obtain the information they need to attack other channels.
Now, I appreciate that not every organization has a direct fraud cost, but there are almost certainly reputational impacts of giving access, giving attackers access to your customer data as well that, that need to be considered by those organizations that don’t have the same kind of risk profile as financial services organizations.
Another area that’s often missed is complaints, particularly in regulated industries, where there’s an obligation to report complaints within specific timelines, and any incremental complaints about security process performance will almost certainly have a cost associated with it, often an order of magnitude greater than the call itself.
Of course, it’s not just that complaint, it’s the other complaints that may not otherwise have been made if it wasn’t for the poor security process. I put my head in my hands frequently when customers phone up to to re engage an organization or to solve a problem that they’ve had in another channel, only to find that they can’t complete the security process and what may have been a simple save for the organization turns into a complete car wreck, and creates complaints and even customer churn that may not otherwise have existed if you’d been able to more simply get the caller through authentication and solve the problem they are presenting to you today.
Finally, and related to that, there’s the impact that security processes have on the customer’s channel of choice. There’s an upfront impact, a kind of perception that it’s too hard to phone you that leads many customers, particularly in certain demographics, to seek out your physical locations.
And there’s also the cost of the failure to authenticate in the phone channel that particularly, again, if you have those physical locations, often the kind of channel of last resort is a visit to your branch or store and as we know, the cost of visiting those, the cost per visit of those is again, an order of magnitude greater than it would have been just to handle the need in the phone channel.
So that’s some other costs that it’s interesting to consider. Now, we can’t necessarily be exhausted of too prescriptive here because of just a sheer variety of organizations that we’re dealing with, but some areas that it’s worth considering.
Matt: The final dimension then that I want to look at today is security.
Of course, this is the kind of key component of the process. But not everyone who is rejected by a security process is a bad actor and similarly, not everyone who is accepted is the genuine customer. Those incorrectly accepted customers are called the false accepts, again, the unhappy face in the top right of our diagram here, who we don’t want to accept.
Unfortunately though, this is an even harder figure to measure. So whilst we might see from post incident investigations in fraud, the number of calls or the number of times an attacker called in before the fraud was conducted. What we often will miss is the number of reconnaissance calls that may have been made to, to defraud one of your customers in another channel or to gain information about an attack that didn’t necessarily trip the radar of the investigation process.
Again I’d refer you back to the session we did with Abhinav, which we talk about this in, in, in a lot more detail about how the attack cycle works.
And it’s not just bad actors, there are many non malicious callers who are forcibly accepted by your security process as well, whether they be friends or relatives of customers who are carrying out their wishes, often with their consent, but without necessarily identifying themselves to you.
Another area to consider within the, Security process performance. Is that something that you really want to allow within your organization? Or would you prefer to identify those people and deal with them and ensure they have the correct authority on behalf of their, the customer, often disadvantaged or with special and challenging customer needs?
Matt: How do we make sense of this all? I’m very aware I’ve just listed a long bunch of stuff, that it’s quite hard to figure out how to put this into a coherent and easy to communicate format. This list isn’t even exhaustive, but I hope it gives you a bit of structure to think about the costs of your security process.
Every organization is different and it’s difficult to be prescriptive about the kind of specific data points and to give you a spreadsheet where you can figure, throw everything in to figure it out for your organization. But one area I can help with is the discussion of efficiency. The biggest challenge I find when articulating this is just a sheer variety of potential outcomes.
It really is true that no customer, no call is the same. And as employees, we often overweight our own personal experience and expectations. Like most employees when they call their employer’s customer service organization are very well trained, they understand the processes, and they tend to give the benefit of the doubt to the organization, which is maybe very different from your real customers.
Some of whom may struggle with every step, despite the fact that the minority often will sail through every process and engage with every piece of automation you put in front of them.
Matt: So every customer is different and there are a huge number of varieties in between that, which is why we developed the security path visualization, which illustrates the different permutations and combinations, as well as the number of callers, proportion of callers, and the different types of outcome that you might experience in your organization. And we’re gonna have a quick look at that. Now.
So here is the security path visualization for a typical organization. Let me just take you through some of the key features. First, notice the width of each path corresponds with the proportion of callers that use it. So we have 100 percent of callers coming in at the left, and 100 percent of callers leaving on the right, but they all take different paths, and each of those different paths has a different outcome and different implications in terms of usability, efficiency, and security of that flow.
You can liken this to how calls might throw through your phone system. In most cases, some form of automated identification process at the start here will determine whether the caller can be authenticated in automation or whether they can be identified at all and just need to go straight to an agent for identification.
If they are successfully authenticated in automation, this is the top half of our diagram then they can act So the top two paths and they can access self service features and a proportion of your callers will do that, and you can see that A path, that kind of optimal path for a customer who didn’t even need to speak to an agent to get their needs solved.
Whereas path B, the customer did need to speak to an agent, but didn’t need to do any identification or authentication with that agent because they’d already been identified and authenticated. If we move slightly further down, we can see paths C and D. This is where a customer who has been identified in automation was unable to authenticate using automated solution, which is not uncommon with knowledge based authentication where they depend on pins and passwords or the speech recognition of names or addresses processes that might’ve worked well online don’t necessarily translate in this world. So we’ll see a high level of automated authentication rejects in this particular case, moving through to an agent for manual authentication, but missing that opportunity for self service. We see the majority of those do successfully authenticate and then we see, a small number that fail to authenticate.
Obviously there are customers who don’t identify in automation and need to go to an agent, and that’s the bottom half of the diagram. Most, we’re mostly very good at doing this, albeit the time it takes will be significant to get customers identified and then authenticated, and that’s really path E.
And then we see path F and G, where we’re unable to either authenticate in F or even identify in path G. Again, customers in path D, F, and G, they’ll all have spent and expended some time and effort on your behalf, will either receive some degree of service degradation or be denied service altogether.
I hope you can see that the path model is really helpful for explaining to executives particularly, and showing them where the challenges might lie within your security process.
Matt: Now. If you’re thinking that looks nice but a bit complex and you have no idea where to start, then don’t worry because we have an online tool to help you and we’ll look at that in a second.
It also includes really helpful calculations of some key metrics and there’s some numbers underneath that we can pull out to help articulate that business case in a bit more detail but it’s a really helpful interactive tool. Before we dive in though, it’s worth having a quick look at the information you need to be able to construct this visualization.
These are also very similar to the information that you’ll need to complete our call center security score card, which evaluates more of these dimensions for you.
So the first off is identification and authentication rates, both automated and manual.
Again, as I’ve said before, it’s challenging sometimes to break these out because they’re often conflated together as a single security or authentication process. But where we have them, we should consider them separately.
And then if you want to move on to get more sophisticated results out of the tool, you’ll need to understand the containment or self service rate. That is the proportion of callers , who are authenticated in automation, who use your self service solutions, or who move off to an agent after that.
And then finally, not quite finally, but the times are important. Clearly separating them, manual identification handle time, manual authentication handle time.
And then if we also know the average handle time, the number of calls, and the cost per call, we can do some quite interesting calculations to figure out what the total opportunity cost of security is for your organization. We’ll have a little look at that. In, in a second.
Just a quick word about cost per call here. Now, I know this is sometimes challenging for organization. I put this brackets fully loaded around it, but fundamentally nearly every. Every part of a call center’s cost model is based on the number of agents. So the number of supervisors they have, the number of desks you need, the number of licenses you need for software, the amount of recruitment you need, the number of trainers you need, the number of planning people you need is generally a function of the number of agents.
I try to get this kind of cost per call metric to be as fully loaded, as inclusive of that as possible. Clearly, I’m not going to teach you to do basic maths here, but there are ways of taking kind of salaries and number of calls per year and average handle time and reducing that down into the cost per call, but we won’t necessarily do that here.
But the more fully loaded you can represent that cost, the better for the base path model.
Matt: . So you can find this tool on the community website by going here to tools if it works. Yep, tools and selecting security path visualization.
There’s also a quick link and I’ll put that in the notes afterwards. You can watch a video of me explaining how to use the tool again, but you’ll, you’ve got this one so you don’t need to. And as we scroll down the page, you’ll see that the tool is laid out into three kind of specific blocks. So we have the assumptions that we’re putting into the model itself, and then some basic outputs.
In this case, they’re quite simplistic outputs, but we’ll look at more advanced ones in a minute and then we have Next Steps. Again, I’ll show you how you can use the Next Steps feature to look at opportunities in a few minutes.
So moving back to look at the basic assumptions. So we’ve just started here with some simple assumptions and these are not abnormal for an organization, but you can see that you can just enter different values through automated identification rates, automated authentication rate, containment et cetera, et cetera. And the chart will update. So if for example, you’re an organization that doesn’t have any automated authentication, then we can very quickly reduce your automated authentication rate to zero, and we can see that the paths update accordingly.
So clearly. You almost certainly have no self service features if you can’t authenticate callers. So we can see that the majority of traffic flows down this C path now as opposed to the A and B paths that it did before. So you can adjust for your specific organization and you’ll get useful metrics at simplistic metrics, albeit at this point, are at the bottom.
So let’s just set up what might be a reasonably high performing organization. Maybe 60 or 70 percent identification rate that might be through phone numbers, inbound maybe a 50 percent authentication rate, which is again, not bad for pins and passwords that you might have in the IVR, particularly if your callers are low frequency. Manual Identification Rate in the 80 or 90 percent range. That’s again, not unusual. A small proportion of customers in this case may not even need identification. So that, that, that accounts for some of the G path. And then again, the Manual Authentication Rate somewhere in the 90%.
So you can see, as we’ve updated the chart here, we can see a little further down. 9 percent of calls are unable to complete security, so a denied service or receive some form of service degradation. And as you can see from the chart in D and F, 6 percent of those are customers who were identified, so clearly wanted to do something.
30 percent of calls going to agents require identification and 62 percent of agent calls require authentication. So that just gives you a feel for how it feels to be an agent in this organization. Often the kind of the automated flows, particularly these top level A flows, they obviously never touch an agent. So whilst it might look like a significant proportion of your calls are authenticated automatically and go through self service, actually the agent experience of that might be different which is why we use this metric.
We also have an advanced mode which enables you to use those additional metrics that we talked about. Again, we’ve plumped for some pretty standard numbers here. So this organization takes just over a million calls a year. The average handle time is 360 seconds, which if maths corrects me is 5 minutes. It takes about 20 seconds to identify a caller manually, it takes about 40 seconds to authenticate them and the cost per call is about five pounds. That might be a little bit higher than you think, a bit higher than you might have in your models, but I don’t think is unfair of a, unrepresentative of a kind of fully loaded onshore cost. It works out at about a pound or a dollar per minute, depending on which currency you want to use this in.
And as you can see, because we’ve added some more advanced more detail, we’re now able to give you some kind of more specific summaries. In this model, 92, 000, that’s still the same 9%, but 92, 000 real callers were unable to complete security. So experienced some form of service degradation, which is clearly from the organization’s perspective, undesirable. 9 percent of total handle time was spent on security, and you can do the maths yourself if you work in a, in the call center about what that actually means in terms of opportunity for the business.
Matt: And the number I think is always really interesting is what I call the opportunity cost of the security process, and here we’ve got it at 1. 8 million pounds in this case. So that’s, that is the cost. That is the amount of money that is spent in handle time and calls that might otherwise have been avoided.
This is the number that you would save if all of your callers were identified automatically, authenticated automatically, and continued to self serve at the rates that your existing customers self serve. So that is a pretty significant number for this organization that only takes kind of a million calls a year.
So now what? So that’s the online tool. And as I said, my favourite part of that number is the total cost figure. So that’s what would happen if you managed to eliminate The need for security in your process altogether. I definitely did a double take when you see that number, but we have been through double, triple, quadruple, and four eyed check the math and it does pan out.
But of course it’s unrealistic to expect you to save all of that because every authentication identification method is going to have its own unique characteristics that impact how much of that opportunity it’s able to realize. And that’s what we’re going to jump on to next. We’re going to look at those methods in a little bit more detail.
So the purpose of this section is not to go in depth on selection and exploration of different techniques. But before we can quantify the opportunity, we need to understand which modern methods are likely to be most effective at increasing usability efficiency and security in your case. And then figure out clearly whether it’s worth it for the costs, and again, we’re not going to talk about costs too much today.
But there are two dimensions that I want to talk about, which we haven’t talked about much so far. Caller frequency and value at risk.
Caller frequency is really important for technologies like voice biometrics, and even some device based methods that require the customer to set up or enroll themselves in the system before it can be used.
There’s often a cost or at least effort associated with this, and even if there isn’t, it’s delaying the benefits, delaying the realization of the benefits until the next call. So if a caller never calls you back, there’s really no point in enrolling them or setting them up in some methods. Of course, most organizations are somewhere in between those two extremes.
My rough rule of thumb and your mileage may vary here is that one or more calls per year or four or more calls in the life of the relationship, whether that be short term one, like case handling in insurance claim or for the medical case or house purchase or, or a longer term savings and investment product that might have very few interactions every year, but might have a number over the lifetime of the investment.
Secondly then is risk it’s usually a bit easier to talk about we talked about a little bit when we looked about costs, but it generally, a higher risk of fraud would already have led you to have more complex and longer authentication processes. So it’s unlikely we’re even having this conversation unless there is some degree of risk in the interaction, but when we evaluate the methods, it’s quite important that we consider both the, not just the absolute risk, which we talked about, but the related party risk. So how vulnerable is the customer to other parties who may have access to particularly devices that might be used as part of the authentication process, but then also the perception requirement.
How secure does the customer need to feel, and what amount of friction might be required in order to make them feel secure? Again, some of our modern methods require very little effort and that may disorientate some customers who want to feel the need for improvements.
I think I may have told this story before, but about the kind of private banking millionaires who are more than happy to buy oil rigs using online banking, but need to speak to a person and go through extra security steps before transferring money to their children’s bank account.
With those two features, we can use my general model for determining the right methods to use. For higher risk and higher frequency interactions, Voice Biometrics is usually the right answer, but when you move into lower risk and lower frequency interactions, network authentication becomes a more viable approach depending on those risk factors, and particularly as you head towards low risk and low frequency interactions.
I haven’t shown device based methods here because they tend to be limited in scope to those organizations who have significant adoption of apps by their customer base already. So if you were in that situation, we’d be drawing a slightly different diagram and be looking at that kind of user penetration of the app to figure out what the right method is.
So we’re not here to decide what the perfect answer is today, but I just wanted to give you a flavor of the different options so that when we jump in to look at how we will model them in a second you’ll understand where we’re coming from.
Matt: So let’s talk about the Voice Biometrics opportunity first off.
We need some more data then so we need three key assumptions that will flow into our Voice Biometrics opportunity. One is the enrollment rate. And now this is clearly a really important number because it’s the proportion of callers who have been authenticated, who then accept, provide you with consent when it’s required and accept whatever terms you may have and complete whatever enrolment process you may have. And I have a whole set of videos and chapters of books about how to design enrollment processes to get the most out of them. And you’ll see in the chart in a second just how material that enrollment rate is to the overall value and return on investment you get from a voice biometric solution. The two other dimensions we need to understand are the authentication rates in IVR, if you intend to do that’s generally using short utterances alongside a natural language understanding and then with an agent if you’re using the technology there.
So those are the different dimensions and we have some benchmarks in the chart, which I’ll go to in a second. Again, using our tool I need to provide a little bit of personal information here
to access our Voice Biometrics Modeler.
Matt: Which then provides me with again changing the assumptions and changing the chart slightly so that I can add in those assumptions. So we’ve assumed an enrolment rate of 80 percent here, which isn’t bad and the enrolment rate we’re assuming here is based on Identified and authenticated callers by other means.
So it’s already slightly, it’s not 80% of the a hundred percent, it’s 80% of those we’ve managed to authenticate in this model .We have an IVR authentication rate of 75%, and that’s because we tend to have shorter utterances there, and it’s not necessarily always as successful as it might be with an agent, where 95% plus authentication success rate is fairly common these days.
You can see when I reduce the enrollment rates you can see quite a significant change in the outcomes that we get at the end. Yeah, different assumptions go in here, and then again at the bottom we see a summary of what those benefits might be, so the key benefits here for voice biometric implementation, 26 percent of c, less callers denied service, a four hundred k reduction in cost to serve, and from a security perspective, 41 percent of calls are now secured with a Inherence based authenticator, so significantly more secure with a significantly lower chance of a false accept than with a knowledge based authentication that inevitably replaced.
You can see in the chart that the updated flows through each of these channels have been included so that the previous numbers in the brackets and the new numbers in the, is out in the open. Cool. Finally then, moving on to Network Authentication.
Matt: A couple of different factors we need to consider when understanding the network authentication opportunity.
One is number availability, so that is the proportion of calls that you receive who, where you receive the number. The second is the identification rate, so the number of those calls which you have received that you’re able to successfully identify, and this is usually a function of kind of the data quality of your organization, how many of those numbers can you match up, but it can also be a function of which type of numbers are calling you.
Again, with the session we had with Abhinav a few weeks ago, I think we saw that something like 80 percent of inbound calls now are from a mobile phone, and I think we also talked about less than 2 percent of calls being withheld. So, in the UK, those numbers are pretty high.
We then have the authentication rate. Now, this is a function of the solution provider, and there is quite a wide variety available today. And also the data that they’re able to access in terms of network intelligence data in order to make that decision. So that is the proportion of calls which they have high confidence are not spoofed, the authentication rate.
And then we also have a variable that we include called the handle time reduction rate. And we include this really because, in most cases it will be good enough to eliminate any manual security questions. But in some cases, organizations may want to retain some knowledge based authentication, just because of that related party risk, which we talked about at the start.
Matt: So we’ll just have a look at how that flows into the model, and then we’ll wrap up today’s session. So again, we have the network authentication model as a different tool on here. And you can see the assumptions have changed. I’m going to update the assumptions with the information I got from, uh, Abhinav a couple of weeks ago.
I’m going to say the number availability rate is 95, only 5 percent of callers withheld, I’m going to say the number identification rate is maybe let’s call it 75 percent because that’s the that’s the number of mobiles and maybe I don’t have every mobile customer. And then I’m going to say the network authentication rate may be like 60 percent or so, because there are some quality issues with the data.
I’m also pretty happy though, because most of my interactions are low risk. So I’m actually going to reduce all of the handle time and eliminate all of the handle time associated with manual authentication, because my related party risk is really pretty low in this particular case. And you can see again, based on our baseline assumptions, what that’s done, how that’s changed our model.
So we’ve almost. Double the number of callers going into self service and who never need to speak to an agent. That and the cost saved from that is pretty incredible, as you’ll see from the reduction in cost to serve down below. Again, we’ve meant twice as many callers going through to agents are now authenticated.
20 percent less calls denied service. Nearly a million pounds in cost to serve reductions and 43 percent of our callers are secured by network authentication. Again, an increase in security, a lower probability that they’re incorrectly accepted than perhaps some of your knowledge based authentication methods.
So just just to summarize then there are a couple of other tools you can find on our site. So you can download the graphics because I think that’ll be really useful to you. You can save the assumptions in our backend and come back to them and play with them later. And you can go back and change the baseline at any time, but we try to lock down the baseline before we go into the modeler so that you don’t don’t try to change too many things at once.
Matt: I think we’ve covered a huge amount of ground today. Now, I haven’t been quite as prescriptive as some people might like, but I’ve tried to lay out a framework and a structure for how people might consider both the costs of their current security process in terms of the current performance and what that means in terms of usability, efficiency, and security, and how that might manifest itself in costs.
But also then about just starting to think about how we might model the future opportunity. Again, in quite simplistic forms there are a huge number of more permutations and combinations that we could look at when we look at modeling future benefits, particularly around the speed at which those benefits emerge, which is again, is a function of call of frequency, but they’re not really for this level of discussion.
But if you want to have that discussion, then you are welcome to reach out and we can have it, or we can follow on in the questions and answers in a second.
So to summarize then the principal benefit areas, principal business case areas we’re likely to be looking at when we’re thinking about improving the security processes for our call center are.
Number one, increased automation. And this usually is the kind of the key driver because we, if we’re able to identify and authenticate more customers using automated solutions, then there are more customers that are able to use our self service solutions. And those capabilities are improving rapidly. And if they are able to use a self service solution for the entirety of their needs, then they don’t need to speak to an agent at all, which is often where the majority of our costs come from.
Yes, we can also, number two, reduce handle time. And that, that is a good thing for both agents and customers. It enables the agents not just to spend less with every customer, but also to actually listen to the customer during the call. So there are different soft benefits there as well as the hard benefits.
Number three, we can talk about, reducing fraud. Now, not every organization has a significant amount of fraud but we can also look at that about increasing security and increasing the confidence of your customers in the security processes they have. And then finally, all of that really can add back into increased customer satisfaction.
Now. I’ve worked in many different organizations and increased customer satisfaction is something we often, we always strive for, but it’s very hard to articulate what the actual kind of financial case associated with that is. But I would encourage you to look at advocacy or churn figures and just understand what data points you have in your organization that we’re able to correlate to poor security experiences.
So that, that’s all I have for you in today’s session. There are no questions yet in the chat, if that is all we’re going to have today, then I will move on and just give you a quick preview of what’s coming up in the next couple of weeks.
Matt: So on Tuesday, not Thursday this time, so mark your diaries accordingly, I’ll be speaking to Stephen Yap, who is the Research Director of the CCMA who’ve just completed a fascinating study as to the behavior and attitudes of both consumers and organizations towards security.
This kind of subject area fascinates me. The difference between what could, how consumers perceive things to be, how they actually are and what they expect, what they expect or what organizations intended is fascinating and at the heart of a lot of security problems.
So Stephen’s got some fascinating original research and focus groups done with consumers, which we’ll be digging into and discussing in a lot more depth and looking at how, what the implications really are for organizations about how they design and communicate change in the way in which they secure their processes.
Some of the interesting insights that popped out straight away from me were just how accustomed and comfortable customers have become with SMS one time passwords, for example, which I think we know to be insecure and we know to be quite expensive and we know to be quite poor use from a usability perspective.
Yet the volume of their use has led to quite significant levels of kind of customer exception and even a perception of security that is. Is not in fact warranted. We’ll be having that discussion with Stephen on the 28th and that’s because in the UK we have a a contact centre conference for the remainder of that week.
Matt: Yeah, so we’ve got some questions about reputational risk and regulation and compliance and how do we include these in the calculations and, That, that is really challenging and it’s difficult to, it’s difficult to be prescriptive at a kind of generic level for those functions.
Like they, they will vary very significantly by industry, by country even by size of firm within that sector.
That’s not to say they’re not important, and I often think about these, what I call the three legs of any modern security business case. There’s a cost thing there’s an efficiency that can clearly be raised by improving the security process. And that’s usually the most easy to crystallize, the most easy to identify and measure.
There’s then the security factors and they are often they can occur as incidents that push people over the edge, and then there are the usability and potentially even, and I think you’re right to say, regulatory drivers that push people beyond that. So I often see these kind of three legs of any business case.
But one of those legs needs to support the whole case, and in my experience that’s usually around improving the efficiency of the security processes. And then the other legs really act to support the whole business case and to keep it above the line where the organization decides to invest.
So it may often be that an organization is experiencing a significant level of fraud, but the investment required to improve the security processes is, it may well be greater than the savings from fraud, but because you can add to that the savings for, from improved efficiency, that’s what drives the case.
The same might go with regulation, like we, we think we should probably be doing this to meet the regulatory requirements, but it doesn’t otherwise add up, but when we add to it the efficiency case it’s easier to make it, push it above the line. I think there are some cases and I know that the questioner here is very familiar with those where regulation really is the driving force and it’s get everything done.
Unfortunately, in security space, there is no kind of perfect answer. There is no golden bullet solution. Whilst regulation might drive for improvements in security, we’re still faced with choices about how we might improve that security, and historically, organizations have made, to my view, bad choices about that, they’ve traded customer usability for some perception often, or some fleeting security opportunity. So regulation, I think, is an opportunity to look at this case.
It may not be enough to make it in its own right. I hope that answers some of the question, if not, we’re too much of a waffle.
That’s great. Thank you so much everyone for joining us this afternoon, both here on the Modern Security Community and on LinkedIn. We will be posting the video and the transcripts and some useful links up on Monday, and you’ll receive an email with those details. And I do hope you’ll sign up to join us in three weeks time to speak to Stephen and ask him, not me, these questions.
So you won’t just have the my voice next time. Thanks again. Bye bye.