Case Deflection, Defined & Measured

What exactly is deflection, and how do we measure it? This is one of the most frequently asked questions I receive from clients.

There is overwhelming evidence that customers want to resolve their own issues via self-service, and doing so is far cheaper for the vendor than assisted service. This is one instance where customer satisfaction aligns perfectly with cost efficiency, meaning everyone from the CFO to the Chief Customer Officer to your actual customer loves case deflection. If done correctly, that is.

But to measure something, you must first define it. So, let’s look at what constitutes a good deflection event and how success is measured.

Explicit Deflection

Accessing a create case or contact us form indicates a strong intent to escalate an issue from self-service to an assisted service case. I define “explicit deflection” as a user abandoning this escalation attempt in lieu of obtaining their resolution during that workflow. Most modern self-service portals can facilitate and track such a process.

GoPro support deflection attempt with Coveo

Here’s an example from GoPro, one of my favorite clients because they make “heroes” out of every customer, including on self-service! From their support homepage, a user can click on the “Contact Support” icon to signify their explicit intent to create a new case. As a customer types information on the left-hand side,  the “Helpful Articles”  widget proactively presents potential solutions based on weighted context from the create case form. This example utilizes the subject, description, and operating system fields as inputs to a knowledge search and considers the session to be an “explicit deflection” if the user views one of the recommended documents and then does not click the “Submit” button.

Support organizations often consider prompting each user to definitively confirm that their problem was solved. I have tried this with many different clients, including this 2006 example from Q-Logic’s support site using the Kanisa Self-Service. Nobody ever clicks on the “Problem Solved” (or similar) button. Personally, I think that a failure to continue in the case creation process after viewing relevant knowledge that was suggested during that process confirms an explicit deflection on its own.

Always Be Closing (Cases), a.k.a. Repetitive Deflection

Knova Update Case widget

While deflection is more obvious during the initial case creation, don’t forget to embed this concept within your entire self-service case management workflow. With QLogic, we designed a process so that anytime a customer updated an open case and provided additional context, such as in the red box highlighted above, another attempt was made to immediately solve the issue by re-querying the knowledge base. We decided to give partial deflection credit for these scenarios since the case had already entered the assisted service channel but was still being solved faster and more automatically than requiring an agent to continue assisting.

Implicit Deflection

Even better than deflecting a user’s issue within the case creation process is offering the right answer before they attempt to create a case – otherwise known as implicit deflection. In my opinion, this category is far too often overlooked by support organizations because it is slightly more difficult to define and measure.

Some support organizations will place a button on each piece of content to ask the customer if the content being viewed resolved an issue that they otherwise would have submitted a case for. But just like my experience with the “Problem Solved” button (above), customers rarely take the time to provide this sort of feedback.

Another way of counting implicit deflection is to automatically categorize content as case-solving versus educational, and then treat the document views differently between the two, including the viewing of case-solving content being included in the implicit deflection totals.

Some content can be identified as case resolving, such as articles about how to recover from a catastrophic failure or a password reset document. These are the types of issues that users will never ignore but can instead be counted on to create a case whenever the problem can’t be self-solved. After tagging this content, views of these articles can be safely assumed to have prevented case creation, aka implicit case deflection.

This tagging process isn’t terribly difficult. You can ask your authors to provide this indicator when creating the content. You can also create triggers that automate the tagging, such as after a document is linked to a certain number of closed cases since this is quite literally the content that has actually resolved cases when viewed by your agents and thus should also be counted as a deflection when viewed by your customers.

I’ve had some clients count each document view for this type of content as an implicit deflection. Others register a percentage as an implicit deflection to account for accidental viewing and other actions that weren’t real deflection attempts. Some clients even skip the tagging process and count a percentage of all document views as an implicit deflection. In my opinion, the definition doesn’t have to be perfect as long as it starts reasonable and allows trends to be measured and improvements to be applied.

Not Case Deflecting, But Still Incredibly Important

Even more overlooked than implicit deflection are sessions where customers don’t have a case-worthy problem but learn something valuable through the consumption of knowledge, ideally proactively.

Next issue avoidance is when you educate a user about a potential problem before they even encounter the issue. As one simple example, if you know that a customer recently upgraded their software and you also know that customers with that specific configuration might encounter a known defect with this new software version that doesn’t appear until weeks or even months later, you should let them know about it in advance so that they can prevent this problem from occuring, or at least implement a workaround. 

Content that helps improve product adoption can be even more powerful for both the vendor and the customer/end user. This is the type of documentation that describes new features or highlights better ways of doing things.

It truly amazes me how many support organizations focus purely on problems that are reported by their customers rather than the proactive prevention of those problems alongside proactive recommendations of how to better use their product or solution. The consumption of this “informational content,” if properly understood, is even more valuable than a case deflection and falls within the more general “Self-Service Success” metric.

Forget Perfect Measurement and Start Monitoring Trends

No deflection definition will ever be perfect. But the faster an organization agrees on a reasonable definition, the quicker it can start monitoring the trends, refining the definition, and most importantly: implementing improvements.

Beware of True But Useless Facts

Knova Success by Microsite report

This report shows deflection success. But these types of reports are really just “true but useless facts” if there is no way to understand the causation of deflection failure and quickly enact improvements. I prefer actionable analytics. 

Coveo Case Deflection Dashboard

I like this simple but powerful report from Coveo because it both trends the number of deflection events over time while also showing the exact queries passed to the search widget that resulted in the successful deflection. A similar-looking report shows the opposite information – queries that did not result in a direct deflection – thus facilitating a continuous improvement process.

If your reporting software can separate out explicit versus implicit deflection metrics, this will help produce one set of inarguable numbers for the explicit deflections while having a more flexible model for implicit deflection that is still important but is perhaps subject to interpretation or caveats. If you can join the deflection data with case cost information to show how much money the different types of deflections produce, that’s even better because reports with dollar signs are oftentimes the best kind of business intelligence. This can be as simple as multiplying each deflection count by an average cost per case. Better yet, if your organization is undergoing a product transformation such as a transition from perpetual to SaaS licensing, quantifying the value of the “informational” content that drives increased adoption and subscription revenue can be even more valuable than the “cost savings” associated with case deflection.


These are the approaches that have worked well for me over the past 20 years. It’s not as complex as many people fear. It simply requires some thoughtful analysis of each organization’s unique business model and an ability to monitor trends and then make adjustments.

Share this post to:


3 responses to “Case Deflection, Defined & Measured”

  1. Fantastic post Scott! Three thoughts:
    1) I spent a lot of time on this topic at TSW last week, and am amazed that regardless of all the data showing customers prefer self-service to assisted service, I still get pushback that “customers really just want to call us.” No, they don’t. And if you really think that, you aren’t listening to your customers, your peers, or industry trends.
    2) I’m the first to admit that measuring success and deflection is not an exact science. But measure SOMETHING. Start somewhere–post session surveys, focus groups, “useful/not useful” tags, etc.
    3) And finally, successful self-service isn’t a miracle. Pacesetters all have things in common (KCS, unified search, multiple paths to knowledge, etc.). The best practices are well understood. If I’ve learned anything doing this for nearly 30 years, culture and resistance to process change are the stumbling blocks, not technology.

  2. […] tied to specific business goals. Things like customer adoption, self service success and deflection, or agent efficiency and proficiency gains. This is the “demand” portion of the […]

  3. […] (Editor’s note: this blog post is based on a longer article which originally appeared here.)  […]