How many help centre articles does an AI support agent need?

Far fewer than most people assume, and the count is the wrong measure. In three real DTC help centres we tested, every single answer came from between three and five pages — typically the shipping policy, the returns or refund policy, an FAQ page and a contact page. One store had 59 crawlable pages and answered its questions out of three of them. Coverage of the questions customers actually ask matters; total page count does not.

Why does my AI agent escalate a question when the page exists?

Because a page on a topic is not the same as an answer to a question. In one store we tested, a warranty page existed and was retrieved successfully — it was cited, at 0.94 confidence, on a different question about return shipping. The warranty question itself still came back as a knowledge gap at zero confidence, because the page never stated how long the product is expected to last or what happens when it fails.

Which customer questions are most often missing from help centres?

In our three-store sample the same three were missing every time: how to choose a size, what to do when a discount code fails at checkout, and what happens if the product fails after a few months. All three block or reverse a purchase, and none of them are covered by a standard shipping-and-returns policy pair.

How can I tell a real content gap from a broken crawl?

By checking whether anything was indexed at all before reading the gap list. A crawler that was rate-limited or blocked returns an empty corpus, and an empty corpus fails every question — which renders as a long, confident list of gaps that is actually zero information. Our teardown refuses to mark a report sendable when the corpus is empty or incomplete, for exactly this reason.

The smallest help centre answered the most questions

What we actually did

Three Shopify stores, all real, all trading, none of them customers of ours. We crawled each public help centre, indexed it exactly as we would for a merchant, and asked the same fixed set of 15 questions — the ones that make up most of a Tier-1 queue. The list is not curated per store and it is not a secret: it lives in our codebase as TIER1_QUESTIONS, so every store gets the identical exam.

A question counts as answered only if the agent produced an answer above its confidence threshold and cited a real retrieved passage. Anything else is a gap.

The stores are anonymised. They did not ask to be written about, and the point of this page is the pattern, not the scoreboard.

The result that changed how we talk about this

Store	Pages crawled	Passages indexed	Passages per page	Answered
Store A	13	97	7.5	12 / 15
Store B	25	204	8.2	6 / 15
Store C	59	148	2.5	9 / 15

Store C has more than four times the pages of Store A and answered fewer questions. Look at the fourth column for why: 2.5 passages per page means most of those 59 pages are thin — a heading, a sentence, a link somewhere else. They exist. They index. They carry almost nothing to retrieve.

Every answer, in all three stores, came from three to five pages. Store A used five: returns, shipping, FAQs, contact, terms. Stores B and C used three each. Store C's other 56 pages contributed nothing to any of the 15 questions. If you are wondering where to spend an afternoon, it is not on page 60.

Having the page is not having the answer

This is the finding worth reading twice, because it is invisible from the inside.

Store B has a warranty page. It crawled fine, it indexed fine, and the retriever used it successfully — it was cited, at 0.94 confidence, on the question about who pays for return shipping. The page is real and it works.

The warranty question itself — "how long is this supposed to last, and what if it fails after a few months?" — came back as a knowledge gap at zero confidence, with no citations at all.

The page is about warranty. It never says how long the product is expected to last, or what happens when it fails. A human skims it and thinks "warranty: covered." A retrieval system asks the customer's actual question and finds nothing to quote.

Auditing your help centre by reading your own page titles will never surface this. The titles are all correct.

The 15 questions, and how three real stores did

Use this as a checklist. The counts are out of three stores, so treat them as a direction, not a statistic.

Customer question	Stores that could answer it
How long do I have to return something?	3 / 3
Do I pay return shipping, or do you send a label?	3 / 3
Where is my order? I've had no shipping update.	3 / 3
Will I have to pay customs or import duties?	3 / 3
My item arrived damaged. What do I do?	3 / 3
How long after you get my return will I see the refund?	2 / 3
Can I exchange for a different size instead of returning?	2 / 3
How long will delivery take once I order?	2 / 3
Do you ship to my country outside the US?	2 / 3
How do I reach a real person, and how fast do you reply?	2 / 3
I need to change the address on an order I just placed.	1 / 3
What payment methods do you accept?	1 / 3
How do I know what size to order?	0 / 3
My discount code isn't working at checkout.	0 / 3
How long should this last, and what if it fails?	0 / 3

The three nobody had

Sizing, failing discount codes, and product durability. Zero for three, and the shape they share is worth naming: none of them are covered by a shipping policy or a returns policy. Those two documents are what every store writes first, and between them they answer the top five questions on this list — which is exactly why the gap is invisible. You wrote the docs, the common tickets went quiet, and the remaining ones look like unavoidable human work.

They are not unavoidable. They are three articles.

Sizing blocks a purchase and drives the largest single category of returns. A size chart image is not enough — retrieval cannot read your chart. Write the guidance in sentences.
Discount code fails is a customer standing at checkout with their card out. The answer is usually a list of four rules (one code per order, excludes sale items, expired, minimum spend) that nobody has ever written down.
Durability and failure is the one people avoid because it commits you to something. That is precisely why the customer is asking.

How to tell a real gap from a broken crawl

This section exists because we got it wrong first, and the failure is instructive if you ever run this kind of analysis on your own site.

A crawler that gets rate-limited or blocked returns an empty corpus. An empty corpus fails every question. What lands on your desk is a long, confident, damning list of gaps — and it contains zero information, because the questions were never really asked.

In one of our runs the crawler indexed 0 pages and dutifully reported 15 gaps. Read quickly, that store has no help centre at all. In truth we had simply been throttled.

So the report refuses to send itself. A teardown is marked sendable only when the corpus is non-empty, nothing was throttled, and every question actually ran. Otherwise it carries a blocker instead of conclusions — "nothing was indexed — every question would fail for that reason alone." A partial list presented as complete is not an incomplete claim, it is a false one.

If you are testing your own help centre this way, check what got indexed before you read a single finding.

What to do with this

Take the 15 questions above and ask them of your own help centre — not by searching for the topic, but by asking the question the way a customer types it.
Stop counting articles. Count which of the 15 a stranger could answer using only your public pages.
Fix depth before breadth. A thin page that mentions a topic is worse than no page: it looks like coverage on an audit and returns nothing on a query.
Write the three nobody has. Sizing, promo failures, durability.

Honest scope: this is three stores, not a benchmark. N=3 is enough to show a mechanism — thin pages retrieve badly, topic pages miss questions, empty crawls produce fake gap lists — and nowhere near enough to publish an industry average. We will say so again when it is more. The 15 questions are fixed in code (TIER1_QUESTIONS), so the exam does not drift between stores or over time.

If you would rather not do this by hand, the Help Centre Audit is this exact analysis on your store, verified by a human before it reaches you, plus the rewrites. And if you want to see the same idea running continuously against your live tickets instead of a fixed question list, that is knowledge-gap insights.