Turning a Support Search Into a Content Roadmap
Chat's help-deflection data and Knowledge's zero-result search queries answer the same question from two directions — here's how to run that workflow manually today.
A good knowledge base reduces repeat support tickets — research on this consistently lands somewhere in the 25-60% range for ticket reduction depending on how well self-service content actually matches what customers are asking, and a majority of customers say they'd rather find an answer themselves than open a ticket at all. The lever behind those numbers isn't "have a knowledge base" in the abstract — it's whether your knowledge base actually covers what people are searching for. Piskes has two independent, real data sources that each answer half of that question. They're not joined into a single dashboard today, but the workflow of connecting them by hand is worth doing regardless.
The two data sources
On the chat side, Chat's widget can suggest a relevant Knowledge article as a visitor types, before a conversation even starts — the help-deflection mechanic covered in its own guide. Every one of those suggestion attempts is a record of what a support visitor was actually asking about at the moment they were about to open a conversation.
On the knowledge side, Knowledge's analytics track zeroResultQueries — the exact search terms readers typed into your docs site that returned nothing (see the piece on what zero-result searches tell you). Every one of those is a record of what a self-service reader was looking for and didn't find.
Put next to each other, these two lists answer a genuinely useful question that neither answers alone: what are people asking about, across both channels, that your documentation doesn't currently cover well?
What's real here, and what isn't yet
To be direct about the current state: this is not, today, a single unified dashboard that automatically correlates the two. Each mechanism is real, shipped, and independently verifiable — help deflection queries the chat widget's suggestion endpoint, zero-result tracking runs off Knowledge's own analytics — but nothing in the product currently joins them into one combined report. The workflow below is something an admin runs manually across both apps' existing analytics pages, not a button that does it for you yet.
Running the workflow manually
- Pull zero-result queries from Knowledge's analytics page for your space — these are readers who searched your docs directly and found nothing.
- Pull the queries or topics behind chat conversations that started despite (or without) a help-deflection match — a rough proxy for what Chat's suggestion endpoint isn't currently resolving well, cross-referenced against your conversation topics or tags if you're using conversation tagging.
- Look for overlap and volume. A phrase or topic that shows up as a zero-result search and keeps generating live conversations is a strong, doubly-confirmed signal — it's failing readers in both self-service and live-chat contexts, not just one.
- Write the article, then check it against both channels going forward. A properly targeted new article should start reducing both the zero-result count for that topic and the volume of conversations that start around it.
Why this is worth doing even without a unified view
The 40-60% ticket-reduction figures cited across knowledge-base research aren't hypothetical for a platform that already has both of the underlying signals — they're a description of what happens when self-service content actually matches real demand. Piskes already has the two data sources that measure exactly that gap; running the correlation by hand today costs an admin some time across two dashboards, but doesn't require waiting on a feature that doesn't exist yet. If a combined view gets built later, this manual workflow is exactly what it would automate — which is also a reasonable way to think about whether it's worth building.