Self-serve support is a product surface
Most companies treat self-serve support as a way to reduce ticket volume. The framing is correct in the way an accountant's framing is correct — it's measuring the right thing for the wrong reason.
A help center optimized for ticket deflection is one design. A help center optimized for the user actually getting their question answered is another. They look similar. They behave very differently.
The deflection KPI
The metric that matters in most support orgs is "ticket deflection rate" — what percentage of users who land on the help center leave without filing a ticket. The framing is internal: success is measured by what the user didn't do (file a ticket), not what they did (solve the problem).
The KPI shapes the design. Help centers built for deflection optimize for "user does anything other than click the contact button." That includes: leaving without an answer, finding a kind-of-related article and giving up, filing a duplicate ticket from a different surface, using the chatbot until they're tired and going elsewhere.
All of those count as deflection. None of them are good.
What success actually looks like
The user who came to the help center wanted an answer to a specific question. Success is: they got the answer, fast, in a form they could use. The metric to measure is not deflection — it's resolution.
Resolution is harder to measure because it requires asking the user. But it's not that hard:
- Thumbs-up / thumbs-down at the bottom of every article. (Most products have this. Most products don't read it.)
- Free-text follow-up on the thumbs-down: "What were you trying to figure out?"
- A quarterly read of the thumbs-down verbatims.
That's it. Twenty hours per quarter, total. The output is a list of questions your users have that your help center didn't answer, sorted by frequency. Most of those questions correspond to articles that should exist, articles that exist but are wrong, or product features that should be more legible.
The "your help center is a product" reframe
A help center is a product surface, not a marketing surface. It has a primary action (find an answer), a primary failure mode (didn't find one), and a primary user (someone who is currently mildly frustrated and on a deadline). Designing for it is product design, not content design.
Some implications:
- The search bar is the most important element on the page. It should rank by relevance to the query, weight recency lower than relevance, and surface the answer in the result snippet — not just the article title.
- The article structure should be inverted-pyramid. Answer in the first sentence. Caveats afterward. Diagrams below. Most help articles are organized like a magazine feature, with the answer twelve paragraphs in. Users do not have time for that.
- Stale articles are worse than missing articles. A wrong answer the user trusts is more damaging than no answer at all. The maintenance cost of an article doesn't end at the publish button; it's a permanent liability you've taken on.
The deflection number is fine, just don't lead with it
There's nothing wrong with measuring deflection — it's a reasonable proxy for "the help center is doing some work." The mistake is using it as the primary KPI. It cannot tell you whether the user got their question answered. It can only tell you whether they didn't ask the support team for help.
Lead with resolution. Track deflection. The two metrics improve together when the help center is working, and diverge when it isn't — at which point you know to read the divergence as a signal that something is broken upstream.
Most teams have inverted this. The deflection number is reported in QBRs; resolution is not measured. The help center keeps deflecting users who didn't get answers, and the team keeps wondering why ticket volume hasn't fallen as fast as the dashboard says.