Deflection!

In my career, I’m often asked questions about case deflection: How do you measure it? How do you know when you’re doing it enough? I’ve found that my answers to these questions have evolved over time. Where I used to eagerly dive into specific answers to these questions, I now find myself pushing back on the idea that case deflection has value as a metric for success.

Deflecting

Part of my unease with case deflection is, admittedly, semantics. The term “deflect” is not often used in a positive sense. In basketball, you might deflect a shot from the opposing team. A politician might deflect an uncomfortable question by changing the subject. In medieval warfare, a shield might deflect the blow of an enemy’s weapon.?

Our most common uses of the word “deflect” are to describe scenarios where we protect ourselves (or our interests) by denying someone else something they seek: two points, an honest answer, a wounding blow. At its core, I don’t think the intent of case deflection is to deny anyone anything, so it strikes me as a false representation of our desired outcome. And I've come to believe that the concept of protecting our interests by preventing cases is actually detrimental to our success.

Smoke & Mirrors

Semantics aside, a larger source of my unease is how case deflection is “measured”. Case deflection is understood as the percentage of cases that weren’t opened out of the total number of cases that potentially could have been opened.?

My first issue is that you can never accurately know the number of cases that potentially could have been opened. This is because the intent of visitors to your self-service resources is never fully known. Some might legitimately be looking for solutions. Others might be researching, or clicked on the link by mistake. Without this context, it's impossible to determine how many of those visits might potentially have resulted in cases. Your percentage is therefore derived from an unknown total.

Secondly, a case not being opened is an event that never occurred. Measuring it requires that you prove a nonexistent outcome of a potential activity. That means your percentage is derived from an unknown divisor, AND an unknowable dividend.?

People far better at math(s) than I have created workarounds to infer visitor intent from a variety of data points: user sessions, case volume, CSAT, web cases, article ratings, unique article visits, etc. But, in the end, these equations all boil down to conjecture, because they cannot measure, from a pool of potentialities, something that didn’t happen.

Some knowledge base platforms offer recommendations for self-service options at the point of case creation. This is slightly better, but still prone to error. If the case creator clicks a link to a knowledge base article and doesn’t return to the case creation form, that is considered a “deflection”. But it doesn't account for the possibility that they return to the case creation process in the future.?Not does it account for scenarios where the article wasn't helpful, but they found a resolution elsewhere.

Other platforms carry this idea further by requiring the case creator to click a button indicating a recommended knowledge base article resolved their inquiry. This is great for tracking behavior in a very specific workflow, but provides no insight into self-service that occurs before the case creation process is initiated. Not to mention that it is highly dependent on the participation of the case creator, which is typically inconsistent.

If Not Deflection...

So, if not deflection, then what? Our goal with "deflection" is to measure how effective our self-service resources are at providing customers with solutions. If we can’t prove a negative and count how often a case isn’t opened, we can certainly prove the opposite: How often a case is opened.?

Rather than fixating on “deflecting” cases–which shouldn’t be a goal in the first place–we focus on the escalation path from a self-service channel to an agent-assisted channel. In other words, how often do customers attempt self-service and still need to reach out for assistance.?

Think of your knowledge base as a support channel–like email, chat or phone–and the concept of an escalation makes sense. In a tiered support environment, the escalation rate of cases from lower tiers to higher tiers (or from generalist teams to specialist teams, or from agents to managers) is a common metric for identifying areas of improvement within the support organization. A self-service channel is no different.

When a customer “escalates” from a self-service channel by contacting support, two things happen: We have a provable, measurable activity and we have a clear indicator of an underperforming resource. Using an escalation rate bypasses the need for smoke and mirrors, by measuring real activities. It also actively identifies resources that need more investment to be successful.

Measuring Escalations

We can define the escalation rate as the ratio of visitors to a self-service resource who opened a case compared to the total number of visitors to that resource. If you find that these resources have a lot of questionable traffic, use web analytics, such as time spent on a page or scroll depth per visit, to filter out visits that don't meet engagement targets.?

Ultimately, the important factor is attaching case creation to a specific self-service resource–the point of escalation where self-service failed and agent assistance was required. Different platforms might offer different mechanisms to achieve this outcome. The most obvious is putting click-to-call, chat buttons or case-creation form links directly on the page.

I suspect I lost several of you with that last statement, but hear me out.

Making it easy for customers to create cases isn’t a bad thing. Customers creating cases isn’t a bad thing. I will be the first to tell you that if I have to call a company or create a case, I’m already cranky. Forcing me to jump through hoops intentionally designed to make case creation onerous is only making me more cranky and less likely to be a repeat customer.

Intentionally making it difficult to open a new case is a great way to drive down CSAT. Especially for the subset of your customers who want to self-serve and are already frustrated when they cannot. Making it easy to create a case shows that you’re not afraid to interact with your customers. It's a demonstration that you’re willing to meet them where they need to be met.

Now, where were we?

Common web analytics tools allow you to associate click actions with the URL where they occurred, giving you precisely the data you need to determine your escalation rate. Resources that have a high escalation rate are those that are somehow failing customers who wish to self-serve. Improving those resources will drive down the escalation rate, and demonstrate what we're actually trying to prove: Our self-service resources are providing customers with solutions.

Shifting Mindsets

When we stop referring to self-service as “case deflection” we stop relying on supposition, conjecture and sleight-of-hand to drive business decisions.

We also stop implying that our goal is to deny customers the opportunity to engage with our business. We should never discourage customers from establishing relationships with support teams, or have them think that their need for assistance is a burden our business would rather not bear.

Instead, if we think of this as a “self-service escalation” we acknowledge the desired outcome: Provide a resource that allows customers to help themselves. And we acknowledge that these resources might not always be adequate. We have direct data of actual outcomes to inform business decisions that benefit self-service and agent-assisted channels.

It puts the focus on our ability to improve our services for the benefit of our customers, and not on the business equivalent of spiking a volleyball in our customers’ faces. Deflection!