Your buyers already told you what the site is missing

The number that tells you nothing

A founder shows me a dashboard. Traffic to the pricing page is up, time on page is down, and the conversion rate has moved a fraction in a direction that could be noise. He wants to know what it means.

It does not mean anything. Not because the data is bad, but because none of those numbers contains the thing he actually wants to know, which is why somebody arrived at that page and left without doing anything.

Then I ask a different question. What do people ask on sales calls that the site does not answer. He answers immediately, without checking anything, and the answer is specific: they ask whether the seat count includes read only users, and it comes up almost every time.

That second answer is worth more than the dashboard, it took four seconds, and nobody had written it down anywhere.

Why a question beats a metric

This is not an argument against analytics. Analytics tells you what happened at a scale you cannot observe directly, and you need that. It is an argument about which one you should look at first when you are deciding what to change.

A metric is an aggregate of behaviour with the intent removed. Bounce rate tells you people left. It does not tell you whether they left because they got what they came for, because the page was slow, or because the answer they needed was not there. Every interpretation of a metric is a story you supply.

A question is the intent, stated by the person who had it, in their own words. There is nothing to interpret. When somebody asks whether the seat count includes read only users, you know exactly what they wanted, exactly what was missing, and exactly what would fix it.

The trade is scale for certainty. You get far fewer questions than pageviews, and each one tells you something a million pageviews cannot.

A metric tells you what happened with the reason removed. A question is the reason, with the scale removed.

They already exist, and nobody owns them

The useful thing about this is that you do not have to go and collect anything new. Your company is already full of these and they are being thrown away continuously.

Sales calls, where the same objection appears in the same place in the conversation. Support threads, where the same clarification gets typed out again by somebody who has typed it forty times. Site search, if you have it, which is people telling you in writing what they came for and could not find. Pre sales email, which is usually the highest intent and least examined source in the whole company. Onboarding calls, where somebody asks what a thing does after they have already paid for it, which is a fairly loud signal about the site.

None of that is connected to the website. The person who has the information is not the person who edits the page, and there is no route between them. So the question keeps being answered one person at a time, indefinitely, at considerable cost, and the page that would answer it for everyone never gets written.

That gap is the actual problem. It is organisational rather than technical, which is why buying an analytics tool never solves it.

Where to look first, and what it costs

If you want to start this week, the order below is roughly by effort against yield. None of it requires anything to be built.

The first one is the highest yield thing in this article and it takes about twenty minutes.

Volume is the wrong sorter

The instinct once you have a list is to rank by frequency and start at the top. That is reasonable and it is not quite right, and getting this wrong is why some teams do this exercise and conclude it was not worth it.

The most frequently asked question is often the easiest one, asked by the people earliest in their thinking. The question asked once, by the buyer at the largest company, about whether you support their identity provider, may be the most expensive unanswered question on your site.

So rank by what the question implies rather than by how often it appears. A question that only occurs to somebody who is seriously evaluating you is worth more than one that occurs to everybody browsing. A question that appears late in a sales cycle is worth more than one that appears in the first minute.

The practical version: keep two lists. Common questions, which shape the pages people read early. Late stage questions, which shape the pages that close deals. They need different pages and they are usually confused with each other.

The objection I get, and why it is mostly wrong

The pushback is always the same and it is worth taking seriously because it contains something true.

It goes: the people who ask questions are not representative. They are the vocal minority, the ones who did not read carefully, the ones who would have bought anyway. Optimising for them means optimising for the loudest rather than the largest.

The true part is that questioners are not a random sample. They are self selected and they skew toward people already engaged enough to ask.

The part that is wrong is the conclusion. Being engaged enough to ask is a qualification, not a bias. Somebody who emails to ask whether you support their identity provider is further along than any anonymous session in your analytics, and their question is about the thing that will decide whether they buy. You are not sampling the population, you are sampling the people who were close.

There is a real version of the objection, which is that fixing one loud person's problem is not the same as fixing a common one. That is what the two lists in the previous section are for. Frequency tells you how widely a question is held. Position in the sales cycle tells you how much it costs to leave unanswered. Neither alone is enough.

What a question is actually telling you

Not every recurring question means a page is missing, and treating them all the same produces a site full of FAQ entries that nobody needed.

Sometimes the answer is on the site and cannot be found, which is a structure problem rather than a content problem. Adding another page makes it worse. The fix is a heading that answers the question rather than naming a topic.

Sometimes the answer is on the site and is not believed, which usually means it is stated vaguely or in marketing language. The fix is specificity, not volume.

Sometimes the question reveals that the product does something people do not expect, which is a positioning finding rather than a content one, and it is worth escalating rather than answering.

And sometimes the page genuinely does not exist. That is the case people assume by default and it is maybe half of them.

Working out which of the four you have takes about a minute per question and it is the difference between this exercise producing a better site and producing a longer one.

Where teams get this wrong

Turning every question into an FAQ entry. An FAQ that restates what the page already says adds nothing and creates a second place for a fact to live, which is the beginning of contradiction. The best answer to a recurring question is usually a section on the relevant page with a heading that states the answer.

Collecting without a route back. Setting up a way to gather questions and having them land in a document nobody owns is worse than not collecting, because it creates the impression the problem is handled.

Waiting for volume. People delay this because they want a statistically meaningful sample. There is no sample size at which a question your sales team answers weekly becomes more valid. Three is enough to act on.

Letting the marketing team be the only reader. The questions that matter most arrive at sales and support. If they are the only people who see them and nobody else does, the site cannot learn.

What this does to the content plan

The practical consequence is a change in where the content plan comes from, and it is a bigger change than it sounds.

Most content plans are generated internally. Somebody sits down, thinks about the audience, considers what would be useful, and produces a list of topics. That list is a set of guesses made by people who already understand the product, which is precisely the wrong qualification for guessing what confuses somebody who does not.

A question led plan looks different. It is shorter, less balanced, and considerably less tidy. It will have three pages about billing edge cases and nothing at all about a topic the team assumed was central. It will feel underweighted on strategy and overweighted on specifics.

That imbalance is the plan being right rather than wrong. The site is not a curriculum. It is a set of answers to things people actually stopped and asked about, and the shape of what people ask is never as balanced as the shape of what a company would like to talk about.

The hard part is political rather than editorial. A plan built from questions is harder to present, because it does not map onto the pillars somebody put in a deck. It is worth the argument.

What good looks like

A company doing this well has a short list, visible to more than one team, of the questions being asked that the site does not answer. It is not long. It is reviewed on a cadence somebody owns.

Sales stops sending workaround links, because the page exists. New pages get proposed with a reason attached rather than as a content calendar item. And when somebody asks why a page was written, there is an answer better than it seemed like a good topic.

The tell is the direction of the content plan. In most companies it is generated internally, from what marketing thinks would be good to write about. In a company doing this well, a meaningful share of it comes from outside, from people who wanted something and could not get it.

How to evaluate whether it is working

The measurement here is unusually direct, which is why I trust it more than most website measurement.

If you added a section because sales answered a question every week, the check is whether they still answer it every week. Ask them in six weeks. The causal chain is short, the observation is real, and it is not confounded by traffic mix or seasonality.

That is a better evidence loop than almost anything available in an analytics tool for this class of change, and it costs one conversation.

Where Creobot fits, honestly

Creobot is the conversation engine we are building and it is in private development, so take this as the reasoning rather than a product description.

The premise is the gap described above. A site assistant that answers from your pages is useful. The more valuable output is the questions it could not answer, because those are visitor intent, in the visitor's own words, timestamped, on a specific page, with no interpretation needed. That is exactly the artifact that currently exists only in the heads of your sales team.

The design consequence is that Creobot treats a failed answer as a first class output rather than an error to be minimised. A question with no page behind it is not a gap in the assistant, it is a gap in the site, and the honest thing is to surface it as such and route it somewhere a person reads.

Creogen is the other half, where a recorded question becomes a change to a named page with an expectation attached.

None of that is necessary to start. Twenty minutes with your sales team gets you most of the way, and it is worth knowing whether the exercise is valuable before anyone builds anything.

The argument, briefly

Most website decisions are made from aggregate behaviour with the intent stripped out, and then the intent gets reconstructed by whoever is presenting.

The intent is available. It is sitting in your sales calls and your support inbox and it is more specific than anything a dashboard will produce. It is not collected because nobody is measured on collecting it and there is no route from the person who hears it to the person who can act on it.

Building that route is cheap. Ask two people what they get asked, write it down, and find out whether the site answers it. If the answer is no more than twice, you have found more actionable work than a quarter of analytics review will produce.