Written, 14 August 2026

Writing for the questions nobody asks twice

Count what your customers ask for a week and you get a short head and a very long tail. The head is boring and mostly already documented. The tail is full of real people with real questions you failed, each one concrete and specific and apparently fixable. Working through it feels like the responsible thing to do. It is, with one important exception, the wrong place to spend the next month.

Why the tail is the seductive part

The head of the list is unrewarding to look at. It is a handful of questions you already knew about, which are already answered somewhere on the site, and the work it implies is restructuring rather than writing. Nobody feels productive restructuring.

The tail is the opposite. Every row is a specific person who wanted something specific and did not get it. Each one is small enough to fix in twenty minutes. It reads like a to do list, it produces visible output, and every item you clear feels like a customer helped. It is the most satisfying document in the whole exercise and it is mostly a distraction.

It is worth being clear about what is being argued here. Not that rare questions do not matter, and not that the people asking them do not deserve an answer. The argument is narrower: writing a page per rare question is an expensive way to serve them, it does not work as well as it looks, and there is a cheaper thing that serves all of them at once.

Three reasons the tail resists being written

The first is that singletons are frequently not repeatable. What made the question unique was a combination: this person, this product, this circumstance, this misunderstanding. The next person with a superficially similar question has a different combination, and the page you wrote for the first one does not answer them.

The second is that the phrasing is idiosyncratic. Part of why it appears once is that it was asked in words nobody else uses. So the page you write, titled with that phrasing, is not found by the next person even when their question is genuinely the same, and you have created a page that answers a question nobody will search for in those terms.

The third is the one that compounds. Every page you publish is permanent until somebody removes it. It can go out of date, it can contradict another page, it needs to be checked whenever a related fact changes, and it dilutes the set a reader or a retrieval system has to choose from. A page that answers a question asked once carries the same maintenance cost as one asked daily and returns almost nothing.

The arithmetic of a help centre that grew this way

Run the tail strategy for two years and you have a large help centre. Most of it was written for one person each. Almost none of it has been reviewed since it was written, because there is too much of it to review and no signal about which parts matter.

The compounding damage is not that the rare pages are wrong, although some are. It is what they do to the pages that matter. A search across a large set of thin pages returns worse results than a search across a small set of good ones. A reader looking for the returns policy has more wrong things to click. A retrieval system has more near misses to choose between. Every rare page you add makes the common answers very slightly harder to reach.

This is how help centres get the reputation they have. Nobody sets out to build one nobody trusts. It is the accumulated result of two years of reasonable decisions to answer the question in front of you.

The tail is a diagnostic, not a backlog

Read the tail, but read it for patterns rather than for items. That is a different activity and it takes an hour rather than a month.

Look for nouns that recur across otherwise unrelated questions. If a particular product, a particular form, or a particular step turns up in fifteen unique questions, that is not fifteen questions. That is one thing on your site that is unclear, and the fix is upstream, on that page or in that step, not in fifteen new answers.

Look also for several singletons that would all be answered by one missing fact. Six different questions that all reduce to whether the thing works with a particular kind of account, or whether the price includes delivery, or which sizes exist. Write the fact once, in the place people already are, and six tail items disappear without a single new page.

The exception: the rare question with a real cost

Here is the exception that proves the rule, and it is the reason frequency alone is the wrong axis. The right axis is frequency multiplied by what a missing answer costs.

Some questions are asked rarely and cost enormously when unanswered. Whether your building is accessible to a wheelchair user. Whether your product is safe alongside a particular medical condition or a particular medication. Whether a service is available in someone's area before they travel to you. Whether a qualification is accepted. Whether an animal is allowed. Whether a payment method is taken. Whether there are stairs.

What these have in common is that the person is planning around the answer. They will travel, or spend, or commit, or arrive with the wrong thing. A missing answer here does not cost a minor inconvenience, it costs a wasted journey, an exclusion, a refund, or a genuine harm, and in some of these cases it costs a complaint of a kind that is difficult to answer well. Write these. Write them even if they have been asked once, even if they are asked once a year, even if the page gets almost no traffic. The traffic was never the point.

Half the tail is not a tail

Before concluding you have a long tail, check that you counted properly. A tail measured by exact wording is mostly an artefact of the counting, because everybody phrases things differently and identical wants look distinct in a spreadsheet.

Count by what the person wanted instead. Ten questions about ten different items that all ask whether the item is in stock are one want with ten instances, not ten singletons. Questions phrased as a complaint, as a query and as a request for help frequently reduce to the same underlying want. The merge is a judgment call and it is the judgment that does the work.

Do the merge before you decide anything. A tail that looks unmanageable before merging often has a perfectly ordinary shape afterwards, with a slightly longer head than you thought and a genuine tail that is smaller and easier to sort.

What to do with the rest of it

Do not write them, and do not delete the list either. A question asked once in March and once in July is not a singleton, and the only way to notice that is to have kept both. Some rare questions are seasonal and look unique because you sampled one season.

The more important move is to make the failure path good, because the tail is exactly where visitors meet it. Every unanswerable question ends in the same place, so improving that place serves the entire tail at once, at a fixed cost that does not grow as the tail grows. A refusal that names the right route and sets an honest expectation is worth more to the tail than a hundred pages, because it works for the questions you have not thought of yet as well as the ones you have.

That is the honest resolution of the whole problem. You cannot write an answer for every rare question and you do not have to. You need one good route out, and a short list of rare questions that were never really about frequency.

A rule you can apply on a Monday

Take the tail. For each item ask one question: would a wrong answer or a missing answer cost this person a journey, money, safety, or access to the thing they came for. Not would it annoy them. Cost them.

If yes, write it, whatever the frequency, and write it as a proper page with the condition stated plainly rather than as a line in a long FAQ where it will be missed. If no, leave it to the route and keep it on the list.

That sorting takes an afternoon for a list that would take a month to write out, and it leaves you with a small number of pages that genuinely had to exist. It also gives you a defensible answer when somebody asks why a particular question is not documented, which is a better position than either having written everything or having written nothing.

If you take one thing away

The one thing
Sort your rare questions by what a missing answer costs somebody rather than by how often they are asked, write only the ones with a real cost, and spend the rest of the effort on the route out.

Everything above is the reasoning. This is the part that changes what you do on Monday.

Questions

Is a large tail a sign that something is wrong?
Not on its own. A broad product range or a complex service naturally produces a lot of one off questions and always will. The thing to check is whether the head is properly answered, because a business with a long tail and an unanswered head has a documentation problem, and one with a long tail and a solid head has a normal business.
Do thin pages written for rare questions help us in search?
Rarely enough that it is a poor reason to write them. A page written for a phrasing one person used is not a phrasing others search for. The more reliable effect is the one nobody counts: a large set of unreviewed thin pages makes your important pages harder to find, both for readers and for anything reading the site.
What about a rare question that is embarrassing rather than costly?
Judge it by the same test and be honest about the answer. If somebody would waste a journey, lose money or be excluded, it qualifies. If the only cost is that the business looks disorganised when it cannot answer, that is a real cost but a small one, and it belongs behind everything in the first category.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.