Measuring content gaps without a research budget

Proper user research is expensive and slow. Recruiting is the hard part, screening is the second hard part, and by the time you have eight interviews booked, the quarter is half gone. For large decisions that cost is worth paying.

For the specific question of what your website fails to explain, there is a much cheaper instrument, and it is already running: the people currently on your site.

Why visitor questions are a legitimate sample

The usual objection is that people who ask questions are not representative. That is true and worth stating plainly. Askers skew toward higher intent, higher patience and higher confusion tolerance. Most confused visitors leave silently.

But that skew works in your favour for this specific purpose. You are not trying to measure the whole population. You are trying to find gaps in your explanation, and the people willing to ask are precisely the ones who tried hardest to find the answer first. If they could not find it, the silent majority certainly did not.

Treat the sample as a lower bound. If three people asked, more than three needed it.

What it cannot tell you

Be clear about the limits, because overclaiming from this data is how teams end up building the wrong thing:

• It cannot tell you what people want that they did not think to ask about.
• It cannot tell you why someone chose a competitor, because they left without engaging.
• It cannot tell you willingness to pay.
• It cannot tell you whether your positioning is right, only whether it is clear.
• It cannot tell you about people who never reached your site.

Those questions still need real conversations. The point is not that question data replaces research. It is that it removes an entire category of thing you should never have been guessing about.

The three free signals you already have

Site search

If your site has a search box, the queries are a gap list. Empty result searches are the strongest signal on any website and most teams have never looked at them.

Chat questions

Covered above. Higher fidelity than search because they are phrased as complete thoughts rather than keywords.

Support and sales inbox

Pre sale email questions are the same signal arriving through a slower channel. If the same question appears in both chat and email, it is confirmed.

Making it a habit rather than a project

The reason this does not happen is not difficulty. It is that nobody owns it and it has no deadline. Fix that by attaching it to something that already recurs. A monthly content meeting, a sprint planning session, whatever exists. Fifteen minutes reading the top question groups, then three page edits.

A modest habit that runs every month beats a thorough audit that happens once and is never repeated.

The evidence you already have

Before any tooling, three sources sit in most companies unread. Support threads, sales call notes, and the site search log if search exists.

Support threads are the strongest, because a question that reached support was a question the site failed to answer, by definition. Read the last fifty and count. It takes an hour and produces a better list than most paid research.

Sales notes carry the questions that block purchases rather than the ones that block usage, which is a different and usually more valuable list.

Site search queries with no result, or with a result nobody clicked, are the cheapest signal of all and almost nobody looks at them.

Why chat logs beat all three

A chat log combines the properties of the others. Like a support thread it captures a real unanswered question. Unlike a support thread it captures the ones from people who would never have written in, which is the majority.

It also captures phrasing that a search log flattens. Someone types a full sentence with qualifiers, and those qualifiers are where the specific gap lives. Returns policy is a topic. Who pays return postage on an exchange is a fix.

And it is continuous rather than a one off audit, so the list stays current as the product and the audience change.

Turning a gap list into work someone will approve

Rank by frequency, then split into three: the answer exists and was not found, the answer exists and is wrong, and the answer does not exist. Only the third needs new writing.

Most teams assume the third bucket dominates. It usually does not, which is the good news, because reorganising and correcting are cheaper and faster than authoring.

Attach the count to each item. Nineteen people asked this and we answered none of them is a sentence that gets a paragraph written. A general observation that our documentation could be better is not.

Then close the loop by rerunning the same questions after the fix, so the next report shows what moved.

Prioritising when everything looks urgent

A gap list of forty items is as unusable as no list. Two filters cut it to something actionable.

First, intent. A gap that blocked someone close to a decision outranks a more frequent gap that blocked casual reading. Frequency alone favours easy general questions and buries the commercially expensive ones.

Second, effort. Separate the items that are one paragraph on an existing page from the ones that need a new page. The first group can usually be cleared in an afternoon, and clearing it makes the second group easier to argue for.

Do the cheap high intent items first. It is the combination that produces a visible result quickly, which is what keeps the process alive past the first month.

What to do with a gap you cannot fix

Some gaps are real and unanswerable publicly, usually because the answer is commercially sensitive or genuinely case by case.

Those become escalation rules rather than content. Naming them explicitly stops them reappearing on every roadmap and stops someone eventually writing a vague page that helps nobody.

Running the first audit before you have an assistant

None of this requires the tool to be installed. The first gap audit can be done today with material you already have, and doing it first makes the eventual deployment better.

Take the last fifty support threads and the last twenty sales calls. For each, write down the question in the asker's words, not in yours. Using your own phrasing collapses distinct gaps into one category and loses the specificity that makes a fix obvious.

Then check each against your site. Can you find the answer in under a minute, starting from the homepage, without using internal knowledge. Most people fail this on a third of their own questions and it is a useful shock.

Sort the failures into the three states: findable but not found, present but wrong, absent. You now have a roadmap and you have not installed anything.

The advantage of doing it first is that you deploy the assistant against content that already answers the common questions, so the early logs surface the second tier of gaps rather than the obvious ones you could have found by hand.

Terms in this articleIntent