Skip to content

Content gaps

Every answer records the retrieval score that produced it. When that score is low, the assistant answered a real question on thin evidence — which means a visitor wanted something your website does not say clearly.

Inbox → Improvements is the list of those moments.

A question becomes a gap when the best passage found for it scored below 0.55, on the same scale you see on any message in a conversation. The cutoff is deliberately generous: it catches “the page exists but says it badly” as well as “the page does not exist”.

Questions are grouped into themes, so one entry is one page to write. A theme carries every wording visitors used — “do you offer scholarships”, “are there any scholarship opportunities”, “how can I apply for a bursary” — and its count is all of them added together. Expand a theme to see the individual wordings with their own counts; the weakest-scoring one is usually worth answering in so many words, because that is the phrasing your content misses hardest.

Not everything here is found automatically. An answer a colleague marked with Correct this answer on a conversation lands in the same queue, and so does a note left on a whole chat. See correcting an answer.

The open queue splits by who does the work, because these need different people:

  • Content — a page to write or improve. This is the main list.
  • Site issues — a visitor telling the assistant that the website itself is broken: a form that will not accept their phone number, a language switcher that does nothing. No amount of content closes these; they belong to whoever maintains the site.
  • Not our audience — visitors who wanted something you do not offer and never will. Read it as a signal about where your traffic comes from, not as work. It never counts toward the sidebar badge.

The top of the Content tab is what is worth doing now: the themes that together account for most of the questions your website is failing, at least three of them and at most twelve. Everything else stays one click away under “show the other N open”.

That slice adapts to your traffic, which is the point. A busy site’s questions concentrate in a handful of themes, so it gets a handful. A quiet site’s are spread thin, so it gets its best twelve — ranked by how often each was asked, how far below the bar the retrieval landed, how recently it came up, and how many of those visitors left frustrated. Either way there is always something concrete to work on, and never a wall of hundreds.

Each gap can produce a briefing: what visitors are actually asking, in their own words, and what an answer would have to cover. It is written to be handed to whoever writes your content, without them needing access to the dashboard or context about the tool.

That is the intended workflow — the gap list is not a to-do list for you, it is a content brief generator for whoever owns the website.

Two ways to close a row, and they are not equivalent. The queue offers them in that order:

  • I fixed it on the website. Publish or extend the page, then close the row. The crawler picks the page up on its next run, the gap stops recurring, and everyone who searched for it on Google finds it too. Nothing is stored in the workspace. If the published page does not really cover the question, the next visitor who asks reopens the row, so an optimistic click costs nothing.
  • Store the answer here. Instant, and it only ever helps people who reach the chat. It becomes a snippet that has to be maintained by hand, and it goes stale the day the real source changes.

Store the answer only when it genuinely does not belong on a public page, such as internal policy or a figure you do not publish. Publish the page for everything else. A stored answer as a stopgap while the page gets written is fine, as long as somebody still writes the page.

Storing an answer for a theme writes one snippet under the theme’s title and closes every wording beneath it. That matters beyond saving clicks: a dozen near-identical snippets would compete with each other in retrieval, so one good answer beats twelve partial ones.

Once you have published something, the gap should stop appearing. The progress view tracks that: gaps that have gone quiet since a given date, and gaps that have not. If a gap keeps recurring after you published the answer, the page exists but the retriever is not finding it — usually because the page uses your internal vocabulary and visitors use theirs.