---
title: "Improving Call Centre Security: ROI and Business Case Explained"
url: "https://symnexconsulting.com/video/call-centre-security-roi"
date: "2023-11-09"
author: "Matt Smallman"
category: "Make The Case"
description: "Matt Smallman explains the ROI and business case for improving call centre security processes, with a live demonstration of a tool that models the benefits."
video: "https://stream.mux.com/nwrHXFCMi51ww4ar00fBayC8021ddgxifHmv00yzKyIjAg.m3u8"
---


# Improving Call Centre Security: ROI and Business Case Explained

_Matt Smallman explains the ROI and business case for improving call centre security processes, with a live demonstration of a tool that models the benefits._

Looking to optimize your call centre security processes? Matt Smallman, the author of [Unlock Your Call Centre](https://symnexconsulting.com/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.

### Video Content Overview

- An in-depth evaluation of current call centre security processes.
- An understanding of inherent challenges experienced in performance assessment.
- Insight into potential improvements through modern security techniques.
- Investigation into essential performance indicators such as usability, efficiency, and security.

### Key Learning Points

- Detailed understanding of the dynamics of security processes within call centres.
- Insight into the emotional aspects of security and the essential elements of winning support for investment in improved security.
- Benchmarking strategies for your current security processes.
- Perspective on the interplay of usability, efficiency, and security in a call centre security.
- Deeper understanding of how 'caller frequency' and 'risk' factors influence technology choice.

### ROI and 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.

### Interactive Tool

One highlight of the video is the practical [online tool](https://symnexconsulting.com/tools/visualisation) 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.

## Chapters

- 0:00 Introduction
- 0:38 Measuring Security Process Performance
- 1:58 The Importance of Security Process Usability
- 4:38 Efficiency in Security Processes
- 5:50 Identification versus Authentication
- 7:01 Additional Costs to Consider
- 9:54 Security as a Dimension of Process Performance

## Transcript

### Introduction
**Matt Smallman:** 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 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 centre's security processes.

### Measuring Security Process Performance
**Matt Smallman:** 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 centre, 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.

### The Importance of Security Process Usability
**Matt Smallman:** 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 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 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 organisations 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 callers.

So it does belie that kind of significant 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 organisations, 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 organisations, 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 organisation experiences is pretty close if not the same as the total rejects or the total retries that you see within your call centre's security process.

### Efficiency in Security Processes
**Matt Smallman:** 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 centre, 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 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 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 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.

### Identification versus Authentication
**Matt Smallman:** 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.

### Additional Costs to Consider
**Matt Smallman:** Also in efficiency, outside of agent 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 organisation has a direct fraud cost, but there are almost certainly reputational impacts of giving attackers access to your customer data as well that need to be considered by those organisations that don't have the same kind of risk profile as financial services organisations.

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 re-engage an organisation 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 organisation 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 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 channel of last resort is a visit to your branch or store and as we know, 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 exhaustive or too prescriptive here because of just a sheer variety of organisations that we're dealing with, but some areas that it's worth considering.

### Security as a Dimension of Process Performance
**Matt Smallman:** The final dimension then that I want to look at today is security.

Of course, this is the 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 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 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 organisation? Or would you prefer to identify those people and deal with them and ensure they have the correct authority on behalf of the customer, often disadvantaged or with special and challenging customer needs?

### Making sense of Security Process Performance
**Matt Smallman:** 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 organisation is different and it's difficult to be prescriptive about the specific data points and to give you a spreadsheet where you can throw everything in to figure it out for your organisation. 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 organisation are very well trained, they understand the processes, and they tend to give the benefit of the doubt to the organisation, 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.

### Understanding the Security Path Visualisation
**Matt Smallman:** So every customer is different and there are a huge number of varieties in between that, which is why we developed the security path visualisation, 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 organisation. And we're gonna have a quick look at that now.

So here is the security path visualisation for a typical organisation. 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 per cent of callers coming in at the left, and 100 per cent 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 flow 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, 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 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. 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.

### What Information is Required for the Security Path Visualisation?
**Matt Smallman:** 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 visualisation.

These are also very similar to the information that you'll need to complete our call centre security scorecard, 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 organisation. We'll have a little look at that in a second.

Just a quick word about cost per call here. Now, I know this is sometimes challenging for organisation. I put this brackets fully loaded around it, but fundamentally nearly every part of a call centre'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 licences 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 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 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.

### Using the Security Path Visualisation Tool
**Matt Smallman:** So you can find this tool on the community website by going here to tools if it works. Yep, tools and selecting security path visualisation.

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'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 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 organisation, 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 organisation 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 organisation 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 organisation. Maybe 60 or 70 per cent identification rate that might be through phone numbers inbound, maybe a 50 per cent 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 per cent range. That's again, not unusual. A small proportion of customers in this case may not even need identification. So 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 per cent of calls are unable to complete security, so are denied service or receive some form of service degradation. And as you can see from the chart in D and F, 6 per cent of those are customers who were identified, so clearly wanted to do something.

30 per cent of calls going to agents require identification and 62 per cent of agent calls require authentication. So that just gives you a feel for how it feels to be an agent in this organisation. Often 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 organisation 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 unrepresentative of a 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 detail, we're now able to give you some 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 organisation's perspective, undesirable. 9 per cent of total handle time was spent on security, and you can do the maths yourself if you work in the call centre about what that actually means in terms of opportunity for the business.

### Understanding the Voice Biometrics Opportunity
**Matt Smallman:** 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 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 organisation 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 maths 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 realise. 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 enrol 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 realisation 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 organisations 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 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 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 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 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 organisations 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 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 flavour 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.

### Modelling the Voice Biometrics Opportunity
**Matt Smallman:** 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 enrolment 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 enrolment processes to get the most out of them. And you'll see in the chart in a second just how material that enrolment 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 Modeller.

### Using the Voice Biometrics Opportunity Modeller
**Matt Smallman:** 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 per cent 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 not 80% of the hundred per cent, 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.

When I reduce the enrolment 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 per cent less callers denied service, a four hundred k reduction in cost to serve, and from a security perspective, 41 per cent of calls are now secured with an 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.

### Modelling the Network Authentication Opportunity
**Matt Smallman:** 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 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 the data quality of your organisation, 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 per cent of inbound calls now are from a mobile phone, and I think we also talked about less than 2 per cent 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, organisations may want to retain some knowledge-based authentication, just because of that related party risk, which we talked about at the start.

### Using the Network Authentication Opportunity Modeller
**Matt Smallman:** 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 Abhinav a couple of weeks ago.

I'm going to say the number availability rate is 95, only 5 per cent of callers withheld, I'm going to say the number identification rate is maybe let's call it 75 per cent because 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 per cent 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 per cent less calls denied service. Nearly a million pounds in cost to serve reductions and 43 per cent 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 to summarise 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 modeller so that you don't try to change too many things at once.

### Summarising the Key Benefits of Improved Call Centre Security Process Performance
**Matt Smallman:** 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 modelling future benefits, particularly around the speed at which those benefits emerge, which, again, is a function of call 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 summarise 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 centre are.

Number one, increased automation. And this usually is the key driver because 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 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 organisation 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 organisations and increased customer satisfaction is something we always strive for, but it's very hard to articulate what the actual 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 organisation that we're able to correlate to poor security experiences.

So 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.

### Looking Forward to Our Next Session on Consumer Attitudes to Security
**Matt Smallman:** 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 behaviour and attitudes of both consumers and organisations towards security.

This kind of subject area fascinates me. The difference between how consumers perceive things to be, how they actually are and what they expect or what organisations 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 what the implications really are for organisations 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 customer acceptance and even a perception of security that 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 contact centre conference for the remainder of that week.

### Question: How Do You Factor in Compliance, Reputation and Regulatory Risk?
**Matt Smallman:** 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 is really challenging and it's difficult to be prescriptive at a generic level for those functions.

Like, 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 crystallise, 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 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 organisation decides to invest.

So it may often be that an organisation is experiencing a significant level of fraud, but the investment required to improve the security processes may well be greater than the savings from fraud, but because you can add to that the savings from improved efficiency, that's what drives the case.

The same might go with regulation, like, 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 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, organisations 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 my voice next time. Thanks again. Bye bye.
