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 over the help-impression log, conditioned on the tenant and the current page, returns the ranked likely articles. CTR-based ranking — articles that users on the same page clicked rise; articles that were shown and not clicked sink. The drawer renders the top-N by predicted click probability for this tenant and this page, and a typed search narrows the candidates to articles that contain the words.
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_impressions",
"where": {
"customer_id": "CUST-0000",
"article_id.customer_id": {
"$or": [
"*",
"CUST-0000"
]
},
"page": "/invoices"
},
"recommend": "article_id",
"goal": {
"clicked": true
},
"limit": 5,
"select": [
"$p",
"article_id",
"title",
"body",
"category",
"tags",
"page_context",
"customer_id"
]
}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.
Frequently asked
How does the drawer rank new articles with no click history?
A new article has no clicks yet, so it starts from a low baseline. 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: one more click moves an article's probability only as much as one more observation should. A product that wants a steadier list can cache the ranking for a while.
Does the drawer learn from negative feedback (article opened, marked unhelpful)?
Only implicitly. The demo logs two signals: an article was shown, and an article was clicked. An article that is shown often on a page and rarely clicked sinks there, because its click probability falls. There is no helpful or unhelpful vote in the demo; a product that collects one can store it on the same impression rows and rank toward it as the goal.
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, impression, click) is universal; the corpus and the context taxonomy differ by domain.
