# Ticket deflection rate: how to measure it and what is good Author: Forum Cat Author URL: https://forumcat.com/blog/author/forum-cat Published: 2026-09-04 Category: Customer support Category URL: https://forumcat.com/blog/category/customer-support Meta Title: Ticket deflection rate: how to measure it Meta Description: One formula for deflection rate, what it cannot see, and how to judge a good number against your own baseline month. No borrowed benchmarks. URL: https://forumcat.com/blog/ticket-deflection-rate Ticket deflection rate is the share of people who needed help and got it without opening a ticket. Take the help-seekers who did not write in, divide by all help-seekers, and multiply by 100. Count people who were looking for help, not page views. There is no published benchmark worth chasing, because the numbers you find are measuring different populations. The figure that matters is your own baseline month and the direction it moves after that. This post gives one formula, explains both sides of it, and says what the number cannot see. It quotes no third-party figure at all, and the reason for that is below. ## What ticket deflection means Ticket deflection means answering a question before it becomes an email. The customer had a problem, found the answer on a public page, and never wrote to you. A ticket is one customer request that a person on your team has to handle. It usually arrives as an email, a chat, or a form. Each one costs staff time, which is why teams try to answer common questions in public first. That work is called [ticket deflection](https://forumcat.com/use-cases/ticket-deflection). Deflection does not mean turning people away. The customer still gets the answer, from a page instead of from a person. ## How to calculate the rate The formula is one line. Deflection rate = help-seekers who did not open a ticket, divided by all help-seekers, times 100. A help-seeker is someone who searched your help pages or opened your forum with a problem. Somebody who read your pricing page is not a help-seeker. Somebody who typed "reset password" into your help search is one. Here is how to count each side. 1. Pick one calendar month. Use whole months, because support volume moves through a month. 2. Count help-seekers. Use searches on your help pages and forum, plus visits to a help article or a thread from search results. 3. Count tickets opened in that month by people who fit the same description. 4. Subtract the tickets from the help-seekers. That is the top of the fraction. 5. Divide by all help-seekers and multiply by 100. Set one counting rule before you start. The same person, with the same problem, in the same week, counts once. Without that rule, a frustrated customer who searched nine times looks like nine people. Say 1,000 people searched your forum or help pages in a month. Of those, 300 opened a ticket that month. That leaves 700 who did not. 700 divided by 1,000 is 0.7, which is 70 percent. Those figures are made up for the arithmetic, not measured from anything. ## Why published benchmarks do not help The benchmark numbers you find online are not comparable to each other. Vendors put different things on the top and the bottom of that fraction. One counts deflected contacts over attempted contacts. Another counts help-center visitors over people who opened tickets. A third counts sessions minus tickets, divided by sessions. Each is a defensible choice. Each describes a different group of people. Two rates that look identical can therefore mean unrelated things. One may count everyone who landed on a help page. The other may count only people who started writing a ticket and stopped. Comparing your figure to a stranger's is comparing nothing. That is why there is no benchmark in this post. Any figure quoted here would carry the same problem. Write down your own formula, keep it fixed, and compare your months to each other. ## What the number cannot see Deflection rate is a trend line. It does not measure how much value your help pages create. Some readers were never going to write in. They would have shrugged and moved on, or given up on the product quietly. Your pages helped them, and the formula treats them the same as a rescued ticket. Some people read the answer and wrote in anyway. Maybe the answer was unclear. Maybe they wanted a human to confirm it. They show up on the ticket side even though the page did its job. A page view is also not a solved problem. Somebody can open a thread, read two lines, and leave more confused. Nothing in the arithmetic knows that. So treat the rate as rough. Do not report it to two decimal places, and do not tie anyone's bonus to it. A move of several points across a quarter is a signal. A move of half a point in one week is noise. ## How to set a baseline Pick one month before you change anything, and write the number down. That is your baseline. Every later number is read against it. Then change one thing. Publish the ten answers your inbox repeats most, or add search to your help site. Changing three things at once means you learn nothing about which one worked. Read the number again after a full month, not after a week. Support volume moves with releases, billing dates, and holidays. A launch week and a quiet week give different numbers. Compare the same month next year, not last week. December against December tells you more than December against November. Keep the numbers in one sheet with a note on what you changed each month. ![The analytics page in a Forumcat dashboard showing question and view counts](https://prod.superblogcdn.com/site_cuid_cms24a31a00k901w1st1x9bu5/images/10-analytics-light-1788188142296-compressed.png) _The top half of the fraction, one month at a time._ ## Three numbers that move earlier Deflection rate is slow. Three smaller numbers move sooner and are easier to trust, so watch these while the main figure catches up. The first is repeat tickets. Count the tickets this month that asked a question you have already answered in public. Every one of those is a page that people are not finding. The fix is usually the title, not the answer. The second is no-result searches. A no-result search is when someone typed words into your search box and found no matching page. That list is a to-do list written by your customers, in their own words. The third is linked answers. Count the support replies this month that linked to a public thread. That number shows whether your team is using the public answers they wrote. It also grows the deflection rate later, because each link teaches a customer that the answers live there. All three are countable by hand in an hour. None of them need a new tool. ## What raises the rate Four habits move the number, and none of them are technical. Answer in the customer's words. If people write "the card on file will not update", title the public answer that way. A title like "Payment method management" uses words nobody types. Keep one public thread per repeated question. Two threads on the same problem split the traffic and confuse search. Merge or close the weaker one. Show existing answers while somebody types a new question. Suggestions at that moment stop a repeat before it becomes a ticket. On Forumcat, the portal suggests existing threads while a customer types a title, and search covers every question and every answer. Link to the public answer in your email replies. Answer the person properly, then paste the link. The next person who searches will find that thread instead of writing to you. This also lowers what each request costs you, which the post on [the cost of a support ticket](https://forumcat.com/blog/cost-of-a-support-ticket) works through. ![Search results in a Forumcat portal for the query webhook, listing solved questions](https://prod.superblogcdn.com/site_cuid_cms24a31a00k901w1st1x9bu5/images/03-search-webhook-1788188135310-compressed.png) _A search that finds an answer is a ticket that never gets written._ ## Where the numbers come from Be clear about which tool holds which half of the fraction. Getting this wrong is how teams end up with a number nobody trusts. The Forumcat dashboard has an analytics page with question and view counts. That covers the top half, the people who came looking for an answer. It is the view you would use to set a baseline month. The ticket side comes from your help desk. Forumcat is not a ticketing system and does not connect to one. There is no import, no sync, and no integration. You read the ticket count from your help desk and do the division yourself, in a sheet. That split is fine for a monthly number. It is a copy of two figures once a month, into one row. If you want the self-serve half of that setup, a [hosted support forum](https://forumcat.com/support-forum) on a Forumcat subdomain is $9 one time, with a 7-day free trial and no card. Keep reading: [how to cut support tickets with a self-service forum](https://forumcat.com/blog/cut-support-tickets-self-service-forum) and [what a customer portal is](https://forumcat.com/blog/what-is-a-customer-portal). ## FAQs Q: What is a good ticket deflection rate? A: There is no reliable public benchmark, because vendors calculate the rate differently. A number from another company is measuring a different population than yours. Set your own baseline month, keep the formula fixed, and judge yourself on the direction it moves. Steady growth over two quarters is a good result. Q: How do you calculate ticket deflection rate? A: Divide the help-seekers who did not open a ticket by all help-seekers, then multiply by 100. A help-seeker is someone who searched your help pages or opened your forum with a problem. Count the same person with the same problem once per week. Use whole calendar months on both sides. Q: What is the difference between deflection and resolution? A: Deflection counts people who got help without opening a ticket. Resolution counts tickets that were opened and then closed with an answer. Deflection is measured before a ticket exists, and resolution is measured after. A team can have strong resolution and weak deflection at the same time. Q: Why is my deflection rate hard to measure? A: Because the top of the fraction is a guess about intent. You cannot tell from traffic alone who needed help and who was browsing. Some people read an answer and write in anyway, and some would never have written in at all. Pick one definition, write it down, and stay with it. Q: How long before deflection rate changes? A: Give it two or three full months. New public answers need time to be found by search engines and by your own team. Repeat tickets and no-result searches move sooner, often within weeks, so watch those first. --- This blog is powered by Superblog. Visit https://superblog.ai to know more. ---