This is one of the most frequently asked questions I receive from clients and prospects. 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. Let’s look at what constitutes a good deflection event and how success is measured.
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 self-service portals can facilitate and track such a process.
Here’s an example from GoPro, a former client of mine who makes heroes out of every customer, including on self-service! From the GoPro 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” and “Operating System” fields and is considered an “explicit deflection” if the user views a document and then does not click the “Submit” button.
The deflection attempt doesn’t have to be on the same screen as the create case fields. I designed this form for Q-Logic a decade ago. It starts with the collection of information as if a case will be submitted.
The knowledge search is then performed as a separate step after the customer provides the product, operating system, and a brief problem description on the prior step – all of which is used as weighted context in the current search query.
Separating the two steps out forces an acknowledgment of the deflection attempt. If the user view a document and either clicks “Problem Solved” or simply doesn’t click “Next Step” to create the case – that can be confidently counted as an explicit deflection.
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 self-service case management workflow. Anytime the Q-Logic customer would respond to an open case, we provided additional context, as indicated by the red box in the example above. Leverage this new information and try once more at a deflection attempt. You might decide to give only partial deflection credit for these scenarios since the case did already enter your assisted service channel.
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. In my opinion, this category is far too often overlooked by companies because it is slightly more difficult to define and measure. Vendors are often concerned that they can’t possibly be confident that their customer would have created a case had they not found their answer organically? My response is usually, “Does it even matter? They solved a problem, so let’s count that as a success.” Let me explain further…
First, let’s think about how to reasonably determine if the customer would have created a case. There are several options here:
Ask the Customer
Each article could theoretically have some sort of button where the customer confirms that the content resolved their issue and that they will not be submitting a case even though they would have otherwise. But that is far too wordy for most customers to read.
Some simpler actions I’ve used for directly measuring implicit deflection include:
- The user rates document extremely high (5 out of 5 stars, thumbs up, etc). This is quick and easy for your customer to actually do.
- The user clicks a simpler “Yes, this solved my problem” (or similar) button. While not specifically indicating if they would have otherwise created a case, you are at least confirming that they had a problem and it is now solved, thus some implicit deflection credit is due.
- The user provides positive feedback (manual text) on the document.
I’ve had clients count positive actions like the above as an implicit deflection on a 1:1 ratio while others registered only a percentage of the actions as deflections since they were more informal than having been executed within a “create case” form. Some clients even count each and every document view as a partial deflection credit (ie. 20%). The definition doesn’t have to be perfect as long as it starts reasonable and allows you to measure trends and make improvements.
Correlate Document Views with Past Case Volume
A better 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.
The most obvious example is articles which help resolve product halting issues where a customer couldn’t possibly proceed without a solution. This could be as complex as a product upgrade or config change required after an operating system update broke the product, or as simple as a password reset process that helps your customer gain access back to your product or service. When these are viewed, they should absolutely be counted as a successful deflection so long as the customer did not continue to create a case (a process which any good web self-service portal and CRM platform should be able to track for you).
And don’t think you have to go manually re-tag all of your content with those two categories. It might be as simple as giving implicit deflection credit to any document that has been linked to 10 or more closed cases – which is a pretty good indicator that people generally would have typically created a case had the document not been found on self-service.
You can also take a document which used to be internal-only facing but was recently published to self-service and provide a certain amount of deflection credit anytime that document is viewed by a customer. This is justifiable because, prior to being published publicly, the only resolution was to create a case and essentially have a service rep read the instructions from that document back to the customer. At least for a certain amount of time, the simple action of publishing something publicly should be given due credit for the deflection it produces.
The opposite kind of document would be those which are informational only, such as best practices on how to tune your product or service for better performance. This is the sort of problem your customer didn’t even know existed until you proactively told them. These documents are still important and should be given some implicit deflection credit, especially if they help prevent future issues. Your organization can decide what sort of weighting to provide this action. You should also give those documents credit for the more general “self-service success” that they produce because educating your customer about how to better use your product is even better than fixing a bug they’ve experienced. I’ll cover this broader “self-service success” topic in a future blog post.
Implicit Deflection is Important
Regardless of how you measure implicit deflection, just remember that a document viewed during a regular search or browse session is no less of a deflection event than one viewed during a case creation form if it truly solved the user’s problem and prevented them from creating a case.
Forget Perfect Measurement and Start Monitoring Trends
…but the faster you agree on a reasonable definition, the quicker you can start monitoring the trends and refining the definition.
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 failure to deflect and quickly enact improvements.
I’m a big fan of actionable analytics. Otherwise, you’re just looking at true but useless facts.Click to tweet
I like this 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. This allows the deflection experience to be tuned for continuous improvement.
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.
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 your business and an ability to monitor trends and then make adjustments.
I’d love to hear your thoughts. Please leave a comment below and share this post with others to get their perspective as well!