Use support documentation to answer pre-purchase questions: an inventory and publish/keep-private sheet

To use support documentation for pre-purchase questions, start from the questions buyers actually ask, not from your help centre's table of contents. List the capability and implementation questions, match each one to the help article that already answers it, then make a publication decision per article: publish as it stands, rewrite for a buyer, keep it for customers, or write something new. The decision is about the audience and the risk in each article, not about how useful it is. Nothing here guarantees that an AI engine will cite a help page; treat each change as a hypothesis to test.

In short

• Buyers ask capability and implementation questions before they buy ("does it support X?", "how long does setup take?"). Your support team may already have answered them in writing.
• Build a support-content inventory: one row per article, mapped to a buyer question, with an audience and a risk note.
• Decide per article: publish as is, rewrite for buyers, keep gated, or write new. Never publish an article only because it is accurate.
• Public help pages should state limits and prerequisites plainly. A buyer can act on a page that says what a feature cannot do; a page that hides it leaves the question open.
• Measure by watching the prompts that motivated each change, and log every edit so you can read the result later.

Why do support docs matter for pre-purchase questions?

Support documentation can be some of the most specific writing a company has about what its product does, provided it is kept current. Marketing pages describe benefits; help articles describe steps, prerequisites, settings and limits. A buyer asking "can it export to our document system, and what do we need first?" is asking a question your help centre may answer better than any sales page.

That does not mean help articles are automatically the right thing for a buyer to land on. They are written for someone who already has an account, and they assume context. Some contain material that should never be public: internal workarounds, customer names, incident details, unreleased behaviour.

So the job has two halves. Find where a help article can serve a buyer's question, and find where it cannot without editing or should not be public at all. The rest of this post gives you a sheet for both.

Which pre-purchase questions can support docs answer?

Support docs answer capability and implementation questions best: what a product can do, what it needs, how setup works and where the limits are. They are a poor fit for questions about price, fit, or comparison, which need a page written for that purpose.

A working split:

• Capability questions: "Does it support single sign-on?", "Can it review scanned PDFs?", "What file types can it import?"
• Implementation questions: "What do we need before we start?", "Who on our side has to be involved?", "What does setup involve?"
• Limit questions: "What does it not do?", "What happens above the usage limit?"
• Not for support docs: "How much does it cost?", "Is it better than the alternative?", "Should a team our size buy it?" These need a pricing page, a comparison page or a sales conversation.

Where do the questions come from? Start with the prompts you already track, which are the questions you ask AI engines on your buyers' behalf. A prompt is a question a monitoring tool asks AI engines so you can see the answers over time. If you have not chosen yours yet, How to choose AI tracking prompts that reflect buying decisions covers it. Add the questions your sales and support teams hear before a purchase.

How do you find the help articles worth publishing?

Look for the gap between what engines cite for your prompts and what your own pages say. A citation gap is the difference between what the pages an AI engine cites for a prompt contain and what your own page offers. Your help articles may be the pages you already own that could close it.

In DiscoveredBy, citation gaps turn tracked prompts where a competitor is winning into a ranked queue of specific changes. A prompt becomes a candidate only when you appear in under 30% of its runs over the trailing window and at least one citation in that window points at a domain that is not yours. Citation gap opportunities are generated only on plans that include the feature; see plans and limits. For each candidate prompt the product looks for the page of yours most likely to compete: an explicit mapping if one has been set, otherwise a page of yours already cited for that prompt, otherwise your existing page with the closest keyword overlap. Below a minimum overlap it treats that as no match and recommends creating a new page.

This is useful for support content in two ways. If a help article is the best match for a prompt, the evidence shows what the competing cited pages have that the article lacks. If no page of yours matches closely enough, that suggests you have no public page near the topic, whether or not your support team has the answer written down privately. Find the citation gaps that deserve your next content update covers how to prioritise them.

The fix types are not always "write an article". The Articles docs describe the brief as deciding the asset: from updating a page you already own, to publishing something new, to holding off entirely. Only a brand new article or a comparison page gets drafted; for other outcomes, including a page you own or a docs or FAQ-only page, the brief itself is the deliverable. That loosely maps onto the publication decisions below.

Enlarge image

Enlarge image

What goes into a support-content inventory?

An inventory has one row per help article and enough columns to make a decision without reopening the article. Keep the columns below so that each decision rests on a recorded fact rather than an opinion.

Fill in the accuracy check honestly. A help article can be perfectly written and still describe last year's interface. Publishing it moves that error from a small audience of customers to every buyer who reads it, and, if an engine reads it, possibly into answers you do not control.

How do you decide what to publish and what to keep private?

Decide in a fixed order: risk first, then audience fit, then value. An article with customer-only material is not a candidate for publication as written, however helpful it is, and an article that only makes sense to a logged-in admin needs a rewrite before a buyer will get anything from it.

Run each article through these checks in order and stop at the first one that applies.

PUBLICATION DECISION SHEET (one per article)

Article: ______________________   URL: ______________________
Buyer question it answers: ______________________________________

0. Does any article answer the buyer question at all?
   NO  -> mark "Write new" and brief it. Stop.
   YES -> go to 1 with the closest article

1. Does it contain customer-only material?
   (customer names, ticket details, account data, internal workarounds,
   security-sensitive setup, unreleased features, contract terms)
   YES -> Can that material be removed without changing the meaning?
            YES -> mark "Rewrite" and list what to remove
            NO  -> mark "Keep gated". Write a separate public page if the
                   buyer question still deserves an answer.
   NO  -> go to 2

2. Has the content been checked against the current product?
   NO  -> stop; check it first (date and reviewer: ____________)
   YES -> go to 3

3. Does it make sense to someone who is not yet a customer?
   (no assumed login, no unexplained product terms, states what the
   product needs first)
   NO  -> mark "Rewrite for buyers" and list the missing context
   YES -> go to 4

4. Does it state limits, prerequisites and exceptions?
   NO  -> mark "Rewrite": add them before publishing
   YES -> go to 5

5. Does it duplicate a public page?
   YES -> consolidate; keep one page and point the other to it,
          then mark "Publish as is" for the one you keep
   NO  -> mark "Publish as is"

Decision: ____________   Owner: ____________   Review date: ____________

The order matters. Starting with "is it useful?" makes it easy to approve a useful article that quietly includes a customer's name or an unreleased setting.

Enlarge image

What counts as customer-only material?

Treat anything that identifies or exposes a specific customer, anything a customer told you in confidence, and any internal operating detail as customer-only. In practice that includes names and logos, ticket text, screenshots with real data, account-specific configuration, internal escalation paths, and workarounds that rely on undocumented behaviour. When in doubt, ask whoever owns the customer relationship; do not decide it in a spreadsheet.

What does a buyer-ready help article look like?

A buyer-ready article leads with the question, states what the product does and does not do, lists prerequisites, and says when it was last checked. It is short enough to read in one sitting and specific enough to be verified.

A quick checklist to apply before publishing a help article to a buyer audience:

• The title contains the capability or task in plain words a buyer would type.
• The first paragraph answers the question directly, before any steps.
• Prerequisites come before instructions (plans, roles, accounts, other systems).
• Limits and exceptions are stated in their own section, not buried in a note.
• Product terms are defined in a sentence the first time they appear.
• Screenshots contain no real customer data.
• Claims that need proof only your company can supply (a customer count, a performance figure, a compliance status) are either backed by a source you can point to or left out.
• A last-reviewed date is visible.
• It links to the related pricing, integration or setup page instead of restating them.

One product behaviour is worth borrowing. On plans that ground drafts in evidence, DiscoveredBy's article drafting can pause when the brief for a brand new page asks for proof only you can supply, such as pricing or customer proof it cannot invent, and lists what it needs under "Proof only you have". Apply the same discipline to a help article: if a claim needs evidence you cannot show, do not write it.

Worked example: Quillstone's help centre

Illustrative example: Quillstone and its competitors are fictional, and the numbers are made up to show the method.

Quillstone sells document-review software to mid-sized legal and compliance teams. Its marketing lead tracks ten pre-purchase prompts and finds two where a competitor, "Brieflane", is cited and Quillstone is not. Both prompts ask about capability and setup: "Can document-review software import scanned contracts?" and "What is needed to set up single sign-on for a document-review tool?"

She asks support for the nine help articles most often linked in sales replies, adds one buyer question sales hears that has no article, and builds a ten-row inventory. Row 2 is the closest article to the first gap prompt and row 3 to the second; both are currently behind the login. The accuracy check has passed for every row except where noted.

The tally is four "publish as is" (rows 1, 2, 4, 9), three "rewrite" (rows 3, 5, 7), two "keep gated" (rows 6, 8) and one "write new" (row 10): ten decisions for ten rows, nine of them for existing articles.

Two things are worth noticing. First, only four of the nine existing articles could go live untouched, and one buyer question had no article at all, so the assumption that "we already have this documented" was only partly true. Second, row 8 is a buyer question with no safe public answer yet. The right response is not to publish the release note but to decide, with product, when a public statement about that connector will be accurate.

Row 3 is tied to the single sign-on prompt. The team rewrites it to lead with the answer, lists prerequisites first, states which roles are needed, and adds a limits section. They log the edit with a date and the prompt it targets, then leave the prompt running. A change in later answers might be associated with the edit, but other pages or engine changes could explain it just as well. Did your content update help? covers how to read that result.

What can this approach not tell you?

It cannot tell you that publishing help articles will make an AI engine cite them, and it cannot tell you why an engine chose the pages it did. Cited pages are an observation of an answer, not proof of what drove it.

Some limits to state plainly:

• The gap evidence describes pages, not causes. A citation gap shows what a competing cited page contains that your page lacks. It does not prove that adding it will earn a citation, and the product describes confidence as reflecting how much evidence was found and whether a specific page could be matched, not how sure it is that the fix will work.
• The sheet cannot decide legal or security questions. Whether something is safe to publish belongs to the people who own that risk.
• Coverage is only as good as your prompt list. A question you do not track will not appear in the gap queue.
• Help articles are not a replacement for pages written for buyers. Price, fit and comparison questions still need their own pages.
• The product does not publish for you. Its articles workflow never publishes a page; you put it live on your own schedule and paste the live URL back so the change can be monitored.

Common mistakes

• Publishing the whole help centre. Volume is not the aim. Publish the articles that answer buyer questions and pass the checks above.
• Copying a support article onto a marketing page. Answer the buyer's question in the buyer's terms and link to the article for detail.
• Skipping the accuracy check. A stale public article can mislead a buyer who acts on it, which a missing article cannot do.
• Hiding limits. A page that leaves out what the feature cannot do leaves the buyer to find the limit elsewhere or on a sales call.
• Not logging edits. Without a dated record of what changed and which prompt it targets, you cannot tell later whether an edit mattered.

Frequently asked questions

Should we make our entire help centre public?

Not necessarily. Make public the articles that answer buyer questions and pass the accuracy and customer-only checks. A help centre behind a login can stay that way; you can publish selected, rewritten articles separately.

Are support docs better than blog posts for AI search?

There is no basis for saying so in general. They are often more specific, which can suit capability questions, but whether an engine cites any page depends on the engine and the prompt. Compare the pages cited for your own prompts instead of assuming.

How do we handle articles that mention a customer by name?

Treat them as customer-only. Either remove the customer detail without changing the meaning, or keep the article gated and write a separate public page if the buyer question deserves an answer. Get sign-off from whoever owns the customer relationship.

Can DiscoveredBy tell me which help articles to publish?

Depending on your plan, it can show which tracked prompts have a citation gap and which of your pages it matched to each, and its briefs can recommend an asset such as a docs or FAQ-only page. It does not know what is confidential in your support content, so the publication decision stays with you.

How often should we review the inventory?

Review an article whenever the product behaviour it describes changes, and put a last-reviewed date on each one. A fixed calendar review is a reasonable backstop, but a product change is the better trigger.

Next step

Build the inventory for your ten most-linked help articles, run each through the decision sheet, and log the first three rewrites against the prompts that motivated them. To find those prompts, review your citation gaps. Accepting one creates a candidate topic in Articles, and choosing that topic starts the brief; Turn an AI citation gap into a content brief your writer can use walks through that step. The Optimize features page describes the related tools, and you can sign in or create an account to start from your own tracked prompts.