The problem
In-app help drawers are the place where help articles go to be ignored. The user opens the drawer; sees a list of articles ordered by either alphabet or editorial priority; doesn't see the article that would answer their current question; closes the drawer; opens a support ticket. The cycle wastes the help corpus you've already written.
The information that should drive the help drawer is the user's current context. What screen are they on? What action did they just attempt? What have similar users in similar contexts clicked? The data is available; the drawer just isn't using it.
How it works
_recommend on the help-articles table conditioned on the user's current context returns the ranked likely articles. CTR-based ranking — articles that users in similar contexts clicked and found useful rise; articles that get opened but bounced sink. The drawer renders the top-N by predicted click probability for this user, this screen, this action.
The pattern is identical to product recommendations applied to help content. Same _recommend operator, same calibration story, same data-driven ranking. The team writes the articles; the system decides which to surface when.
{
"from": "help_views",
"where": {
"customer_id": "CUST-04812",
"current_screen": "invoice_form"
},
"recommend": "article_id",
"goal": { "helpful": true },
"limit": 5
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 🧾 Accounting demo today. Click through to the live application and inspect the queries that produce the result. Source is on GitHub under Apache 2.0.
Frequently asked
How does the drawer rank new articles with no click history?
New articles get baseline ranking based on attribute similarity to existing articles. As impressions accumulate, the ranking shifts toward observed CTR. The team's editorial role becomes "write the article"; the system handles "surface it to the right users."
Can the drawer surface articles in the user's preferred language?
Yes. Language as a condition in the where clause; the prediction scopes to the language. Multi-language help corpora work as separate predictions per language with shared CTR signal where appropriate.
What if the help article rank changes constantly as new clicks accumulate?
The ranking is stable for typical patterns and shifts only when CTR actually changes. Smoothing over a moving window prevents per-click flicker. Most deployments smooth over 24 hours of clicks; bursty patterns smooth tighter.
Does the drawer learn from negative feedback (article opened, marked unhelpful)?
Yes. "Helpful" and "unhelpful" both feed the prediction. Articles consistently marked unhelpful for a context sink in the ranking for that context — even if their CTR is high (users open them then bounce). The full feedback loop captures both engagement and satisfaction.
Can the help drawer be used outside SaaS (e-commerce help, banking app help)?
Yes. Any in-app help context — banking app, e-commerce checkout, healthcare portal — runs the same pattern. The signal (context, click, helpful) is universal; the corpus and the context taxonomy differ by domain.
