Choose a job before choosing your sources
Start with one clear purpose: answering onboarding questions, explaining product plans, or helping customers find support articles. A narrow first use case gives you a useful way to judge the answers.
List ten questions your team receives repeatedly. For each question, write down the page that contains the approved answer. If no such page exists, create the answer before adding more content. A larger knowledge base will not fix a missing policy.
Collect the pages customers actually need
Use your help center, setup guides, product documentation, and current policies. Leave out expired offers, duplicated pages, and draft documents that customers should not rely on. If two documents disagree, resolve the conflict at the source.
In Helpnest, add a website URL to crawl content or upload supported documents. You can also paste text and create Q&A pairs for short, specific answers. Check the data sources guide for supported formats and source management.
Make each answer understandable on its own
A section called “Limits” is less useful than “File upload limits on the Growth plan.” Use descriptive headings, name the product or plan, and spell out exceptions. A short page with one current answer is often easier to maintain than a long page mixing several unrelated topics.
Avoid uploading credentials, private customer records, or internal notes to a public-facing support agent. Decide what the agent should be allowed to explain before you add the material.
Test with questions that are difficult on purpose
Use the playground to ask your ten real questions, then add variations with typos and incomplete context. Test an unsupported request too: the agent should acknowledge missing information rather than invent an account-specific answer.
For every test, inspect whether the answer matches your policy, whether the source actually supports it, and whether the visitor has a clear next step. Record failures as missing content, unclear instructions, or questions that need a human. This makes revisions more useful than repeatedly changing the greeting.
Treat training as maintenance
After changing a policy or setup guide, re-sync the relevant source and test the affected questions again. Do not assume a saved website source automatically reflects every future edit. Review conversations for new gaps and add concise answers where they belong.
Keep a small regression checklist: the same questions, expected facts, and escalation cases. Re-run it after a content update or model change. The goal is a maintained support resource, not a one-time upload.
Build on what you know.
See the setup workflow in our docs, or join the Helpnest waitlist.
Read the quickstart →