How to measure ticket deflection in Jira Service Management

Most support teams can only estimate deflection. Here's how to calculate a deflection metric from your JSM help center, and what to report alongside it.
What is ticket deflection?
Ticket deflection is when a customer resolves an issue through self-service, usually a help article, and doesn't need to submit a ticket. It's the main return on a help center. Every deflected ticket is agent time spent on problems that need a person.
Why is deflection hard to see in JSM?
JSM does have a deflection report. Its Requests deflected report counts a deflection when a customer is raising a request in the portal, selects a suggested article, and votes it helpful. That's a real signal, but it depends on the customer taking an extra step after their problem is solved. A customer who reads the answer and closes the tab isn't counted.
So teams lean on other proxies too, such as article views and ticket volume. These hold up until someone in a budget meeting asks how many tickets the help center actually prevented. Article views don't link to a ticket that didn't happen. Ticket volume moves for plenty of reasons unrelated to help content, like a product release, a pricing change, or a new customer cohort.

A deflection metric you can calculate
Start counting when a customer opens a request form. Every request then ends with a submission or an exit, and you know whether the customer read a help article along the way. Service analytics tracks exactly this for help centers built with Refined. It counts an article interaction when the customer views a knowledge base article for at least 60 seconds during the request.
That gives you a metric:
Likely deflection rate in % = (Requests exited after an article interaction ÷ Requests started) x 100
For example, say customers started 1,000 requests last month and 180 of them ended without a submission after the customer read an article. Your likely deflection rate is 18%.
The word "likely" matters. An exit after reading suggests the customer found the answer, but it doesn't confirm the problem was solved, and some customers will come back through another channel. Say so in your report. A conservative number with a clear method holds up better under questioning than a big number with no method behind it.
What to report next to it
A deflection rate on its own rewards fewer tickets, even if customers are struggling to get them. Put these next to it:
- Submission rate by request type. This shows where customers still need an agent, and which request types always will.
- Exits without reading. These are customers who left the form without reading anything. Some found help elsewhere and some gave up, so it's worth watching if the number climbs.
- Follow-up effort. Views per request, comments per request, and My Requests page views show how often customers come back to check on a request they've already submitted. Rising numbers can point to slow updates.
- The articles behind the number. The "before exit" view lists the articles customers read before they left. Naming them turns your knowledge base team's work into something leadership can see.

Where measurement fits
We think about knowledge and service as a flywheel. Context feeds experience, experience produces outcome signals, and optimization turns those signals into better context. Measuring deflection is the step where your help center produces those signals. It turns into improvement once you act on it.
Set your baseline now
Service analytics is part of the Advanced edition. Start tracking now, and next quarter you'll have a baseline to compare against.
Or, if you aren’t already using Refined Sites for JSM.
Read more about





