How to Tell If Your Help Center Is Actually Reducing Support Tickets

A head of customer success at a SaaS startup told us their support tool reported an 84.5% resolution rate. When we asked if that matched reality, they said: "That number is a lie. I would guess it's probably more like 50%."

The metric counted any conversation where the customer didn't immediately reopen a ticket as "resolved." It couldn't distinguish between a customer who got the right answer and one who got an outdated answer, tried to follow it, and came back two days later with what the system logged as a brand new issue.

After dozens of conversations with support teams trying to reduce support tickets, we've found this gap is more the norm than the exception.

Why most help center metrics miss the real picture

According to research published in the Harvard Business Review, 81% of customers try to solve problems on their own before contacting support. The standard ticket deflection playbook follows from that stat: write articles covering your most common ticket topics, then measure whether support volume goes down.

Zendesk's measurement docs define the self-service score as total help center users divided by total ticket requesters. That formula tells you whether people visit the help center. It tells you nothing about whether they got a correct answer once they were there.

What does deflection rate actually measure?

Deflection rate is a useful signal when your help center is new and you're building coverage from zero. It answers the question: are customers finding content at all?

It stops being useful the moment your product starts outpacing your documentation. A help center with 500 articles and a high deflection rate can be actively misleading if 200 of those articles describe a version of the product that shipped six months ago. The visits count. The page views count. The fact that the article sent the reader in the wrong direction does not.

Why do stale articles create more tickets than missing ones?

A missing article is straightforward. The customer can't find what they need, so they submit a ticket. That ticket gets categorized correctly because there's no content to misdirect them.

A stale article is worse. The customer finds it, follows the instructions, and the product doesn't behave the way the article described because a feature got renamed or a workflow changed. They submit a ticket about the symptom they hit, not the article that caused it. The support team logs it as a product question or a bug. Nobody connects it back to the stale source.

These tickets look like different issues each time, so they never get flagged as recurring questions with a common root cause. The article keeps its page views. The deflection dashboard keeps looking healthy.(We wrote a separate guide on how to find stale content in your knowledge base if you want the tactical version.)

A support lead managing four help centers with close to a thousand articles described it plainly: "I know there's misinformation. There's outdated information. Things slip through the cracks because I'm only one person."

The ticket volume your dashboard can't see

A head of support operations at a recruiting SaaS company told us: "Currently, we don't know what's working, what is not working because everyone is coming and asking us on Slack."

Every customer account had its own Slack channel. Users stopped checking the help center because they'd get a faster, more accurate answer from a person than from help docs that might be out of date. We've written about why Slack becomes your unofficial help center before. A quick summary - Self-service metrics only track what happens inside the help center. If customers route around it, that behavior never appears in deflection numbers.

Some teams are aware of the problem and compensate for it. Agents flag wrong articles in Slack. Support leads keep mental lists of what's outdated. Those informal systems work up to a point. They break when the team grows, when the person holding the context leaves, or when the volume of product changes outpaces what anyone can track manually.

The same blind spot applies to partial answers. The SaaS startup with the inflated resolution rate put it this way: "Often we will read the answers and see it was a good answer, but it told 40% of the story. Now that's gonna create follow-up issues." The follow-up gets logged as a new topic. The original resolution keeps its stats. The connection between the two never surfaces.

How to measure what's actually working

How do you run a contact driver analysis?

Start from the other end. Instead of counting help center visits, pull your last 30 days of tickets. Group them by topic. For each high-volume topic, check two things: does an article exist that covers this, and is that article accurate today against the current state of the product?

The gap between "article exists" and "article is current" is where your real ticket volume lives. Zendesk's "tickets created after search" metric and missed searches data tell you what content is absent. They don't tell you why someone failed when the article was there.

What does it look like when a help center is actually reducing tickets?

One Pageloop customer, a 60-person SaaS company with a single person running support and the help center, kept their documentation current through continuous updates rather than periodic audits. Over three months, they handled 3,600 customer conversations. 545 needed a human reply: a 15% human-touch rate, down 15 percentage points from the period before they started keeping articles consistently accurate.

70% of their help center work was updating existing content to match product changes. 30% was creating new articles. That ratio matters. The teams that focus on writing more articles while the existing ones go stale end up with a bigger help center that performs worse. The teams that focus on accuracy end up with a smaller, more reliable one.

Support at that company also became their largest driver of inbound ARR, with help center interactions converting better than any paid marketing channel. When your documentation is accurate, customers trust the help center enough to use it as a product resource, not just a last resort before filing a ticket.

Pageloop connects to your product's release flow and flags which help docs are affected by each change before customers encounter the mismatch. The audit runs against your existing knowledge base on Zendesk, Intercom, or wherever you host your docs. Instead of running a quarterly support audit that's outdated by the time you finish, you catch staleness at the source.

What to do this week

Open your ticketing system and pull the last 30 days of tickets. Group the top 10 topics by volume. If you don't already tag tickets by theme, spend an hour sorting a sample into buckets like how-to questions, billing, bugs, and confusion. For each high-volume topic, find the corresponding help center article and read it against the current product, step by step, with the product open in another tab.

If seven of those ten articles are accurate, your help center is doing its job. Your remaining ticket volume is genuine complexity or missing coverage. That's a manageable situation.

If four or five describe a version of the product that no longer exists, your deflection metrics have been wrong for a while. Those articles are generating traffic, getting counted as self-service attempts, and producing tickets that get categorized as new issues rather than documentation failures.

Run that diagnostic once and you know which problem you have. Run it after every major release and you'll see whether your help center is keeping pace with your product or falling behind it.

Image Courtesy Unsplash and Birmingham Museums Trust
February in the Isle of Wight (1866) by John Brett