Implementation worksheet · 5 min read
A User Assistance Adoption Scorecard
Score in-app assistance on five measures, none of which is raw usage: resolution rate (sessions where the user completed the task they were stuck on, not just opened help), escalation rate (assistance sessions that became support tickets — lower is better only if resolution is high), time-to-resolution compared with the support path, coverage (the share of top support topics with in-app assistance available at the point of need), and repeat rate for the same topic by the same user, which signals the answer did not land. Deflection counted as 'help opened and no ticket filed' is the metric to avoid: it counts silent abandonment as success, and abandonment is the most common outcome it hides.
Assistance tooling is easy to justify on usage and hard to justify on outcomes, so most scorecards quietly measure activity. The five below are harder to move and are the ones that correspond to whether users were actually helped.
Put it into practice
1. Define resolution per topic, not globally
For 'how do I export', resolution is an export completed within the session. Global proxies like 'did not open a ticket' do not survive scrutiny and cannot be acted on.
2. Measure escalation honestly
An assistance session that becomes a ticket is not a failure if the question genuinely needed a human. Track it alongside resolution rather than as a penalty on its own.
3. Compare against the support path
Median time from question to resolution, in-app versus ticket. If in-app is not faster, the investment is buying convenience rather than speed, which is a different case to make.
4. Measure coverage against real demand
Take the top twenty support topics and check whether each has in-app assistance where the user hits the problem. Coverage of topics nobody asks about is the most common way this tooling looks busy and does nothing.
5. Watch the repeat rate
The same user returning to the same topic within a week means the answer did not land. It is the most under-used signal in assistance analytics and the fastest route to a content fix.
Assistance scorecard
Copy this structure into your review document and record your observed result for each row.
| Measure | Definition | This period | Target |
|---|---|---|---|
| Resolution rate | task completed in session | ||
| Escalation rate | session became a ticket | ||
| Time to resolution | vs support path median | ||
| Coverage | top-20 topics with in-app help | ||
| Repeat rate | same user, same topic, 7 days |
A failure worth checking
The deflection illusion: help is opened 4,000 times a month and only 300 tickets follow, so the team reports 92% deflection. Most of the other 3,700 closed the widget and gave up — deflection counted their silence as success, and the only visible consequence is a churn number nobody connects back to it.
Common questions
Is deflection ever a fair measure?
Only when paired with resolution. Deflection alone cannot distinguish a solved problem from an abandoned one, and those are the two outcomes you most need to tell apart.
How do we measure resolution without heavy instrumentation?
Pick the five highest-volume topics and instrument just those. Five well-measured topics beat twenty guessed ones, and the pattern usually generalises.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.