Reading the Room: What Unanswered Questions Reveal
How unanswered-question detection turns help centre chat into a prioritised backlog of the articles your users actually need next.
An answer bot that cannot answer something has two options. It can say so, or it can produce four confident paragraphs assembled from adjacent articles that do not quite cover the question. Most systems pick the second, because a non-answer feels like a product failure and generating something feels like a save. It is not a save. It is the same failure with the evidence deleted.
We would rather record the miss. An unanswered question is the most useful thing your help centre produces.
A miss is a research finding
Consider what has to be true for a question to reach your help centre and come back empty. Someone was using your product. They hit something they could not work out. They cared enough to type it. They phrased it in their own words, unprompted, with no survey question shaping the answer.
That is better research than most companies commission. It arrives free, continuously, in the exact vocabulary your users think in rather than the vocabulary your team uses internally. And unlike a support ticket it has passed through almost no filters - asking a search box costs nothing, so you hear from the impatient and the private as well as the diligent.
The only thing standing between that and a documentation backlog is whether the system bothers to write down that it failed.
What we do with it
Every question asked of a SupportPages help centre is recorded with whether it was answered, which articles were used as sources, and whether the reader marked it useful. The unanswered ones surface as a list.
That list is the closest thing to a correct content roadmap most teams will ever have. Not "what should we document next" answered from a meeting, but "here are the eleven things people asked this fortnight that we had nothing for", ranked by how often they were asked.
Clustering matters more than raw counts. Eight people asking eight differently-worded versions of the same underlying question is one article, not eight, and the phrasings themselves are a gift - they tell you which words to put in the title so the article is findable by the next person who asks.
There is a second, subtler read on the same data. Questions that were answered, but from an article that is technically about something else, are a signal that a section is doing double duty and should be split. Those show up as answers with low usefulness ratings and a source article whose title does not match the question. Slower to act on, but they explain a lot about why a help centre "has everything" and still frustrates people.
The uncomfortable version
Some unanswered questions are not documentation gaps. They are product gaps wearing a documentation costume.
"How do I export to CSV" asked forty times, when there is no CSV export, is not an article. Writing one - "SupportPages does not currently support CSV export" - is technically responsive and will make everybody involved feel worse. The right destination for that cluster is the product backlog, and the honest interim answer is a roadmap note rather than a help page.
This is the part teams get wrong. A gap list is not a writing list. It is a list of expectations your product set and did not meet, and roughly one in five of them wants engineering rather than prose.
The clustering is rough
The clustering is currently rough. Questions are grouped by similarity, and near-duplicates that use entirely different vocabulary - "how do I add someone" versus "invite a colleague" - do not always land in the same cluster. That means the counts undercount, and a genuinely popular gap can look like three medium ones. We would rather undercluster than merge two distinct questions, but it makes the ranking softer than it should be.
There is no automatic route from a gap to a draft. You see the list, you decide, you trigger generation. Closing that loop entirely is tempting and I keep deciding against it, because "the bot noticed a gap and published a page about it" is exactly the sort of thing that produces a help centre nobody wrote and nobody trusts.
And the whole mechanism only sees questions from people who asked. The reader who never opens the help centre at all is still invisible here, and that is a much larger group.
Where it lives
The help centre analytics tab, under unanswered questions. If it is empty and you have traffic, that is worth investigating on its own - it usually means the answer layer is being too generous about what counts as answered.
Read the top five in your users' own words. At least one will not be a documentation problem.
About the Author
Simon Moxon has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building SupportPages.io - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't.