Start with what your team already answers from
Whatever your support team opens first when a customer asks something is the right first source — usually that's a help centre or a docs site. It's already organised around real questions, which is exactly the shape the assistant needs: it doesn't do well with a source written for someone who already understands the product, because that's not who's asking.
Past resolved tickets are the second source worth connecting early, and the one teams skip. A help centre tells you what you decided to document; a ticket history tells you what people actually asked, including the phrasing and the edge cases that never made it into an article. Connecting both gives the assistant the official answer and the messy real-world version of the question at once.
A sitemap is a source, not a shortcut
Pointing the crawler at a sitemap is the fastest way to connect a large site, and it works — but it pulls in everything the sitemap lists, including pages that were never written to answer a question: a careers page, an old blog post, a marketing landing page with no factual content on it. None of that actively breaks anything, but it dilutes what gets retrieved, and a marketing claim surfacing in a support answer reads as a mistake even when it's technically true.
The fix isn't to avoid sitemap crawling — it's to exclude the sections that aren't documentation before the first crawl, rather than after a customer gets a strange answer and someone goes looking for why.
How re-indexing actually works
There's no training run and no model to retrain. The assistant answers by retrieving from an index of your connected sources at the moment of the question, so when an article changes, the fix is to edit the article — the index re-crawls it and the next answer reflects the edit. There's no separate step where you tell the assistant the policy changed.
That also means the reverse is true: an article that's wrong stays wrong until someone fixes the article, not the assistant. If a wrong answer keeps recurring, the useful question is never 'how do we override this in the settings' — it's 'which article is this coming from, and why does it say that.'
Signs an article is quietly making answers worse
A few patterns show up often enough to be worth checking for directly, rather than waiting to notice them in a bad transcript:
- Two articles answering variations of the same question with slightly different details — the assistant has no way to know one is stale, so it will sometimes cite the wrong one.
- An article that answers a question conditionally ("this applies unless you're on the annual plan") but states the condition in a sentence buried in the middle, rather than up front — retrieval tends to weight the opening of an article more heavily than a caveat three paragraphs down.
- A troubleshooting article written as a narrative ("first we tried X, which didn't work, so then...") instead of stating the working fix directly — it reads fine to a person skimming top to bottom, but it gives the assistant a wrong answer to quote before it reaches the right one.
- Old promotional or seasonal content still live in a connected source — a discount code page, a past-event announcement — that has nothing to do with support but is technically indexable.
What to connect later, once the basics are working
Once the primary knowledge base is connected and the assistant is answering the obvious questions correctly, it's worth adding narrower sources: a changelog, so it can answer "has this been fixed yet"; internal runbooks for topics you're comfortable automating; product pages, for pre-sale questions. None of these need to be there on day one — a knowledge base with fewer, cleaner sources outperforms one with everything connected and half of it unreviewed.