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 the customer themselves 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.

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 the QLogic example above, and nobody ever clicks on the “Problem Solved” (or similair) 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

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 obviously 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 they can start monitoring the trends, refining the definition, and most importantly: implementing improvements.

Beware of True But Useless Facts

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. 

I like this simple but powerful report much better since 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 facilitiating 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 often times 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.

Conclusion

These are my definitions and experiences over 20-years of deflection tracking. It’s really not as complex as many people fear. It simply requires some thoughtful analysis about each organization’s unique business model and an ability to monitor trends and then make adjustments.