News and analysis
AI support knowledge: preparing answers alongside a product release
Prepare AI support knowledge for a release: plan eligibility, older versions, accountable owners, test questions and corrections after launch.
A client portal release changes who can approve documents. Engineering ships the feature, marketing announces it, and AI support continues using the old instructions. The customer receives a confident explanation that was correct yesterday. Product delivery and knowledge updates need a shared point of readiness.
In June 2026, Intercom described its new product introduction process, or NPI. Its June 26 article makes agent readiness part of release preparation: create knowledge, review existing material and test answers before launch. This is a support provider's account of its own practice rather than an independent evaluation. The underlying principle is still useful for a small product without a dedicated NPI manager.
What knowledge readiness means
An internal “what we built” document explains the feature to the team. Customer knowledge must explain who can use it, where to enable it, which restrictions apply and what to do when the expected result does not appear. “Available on certain plans” leaves too much room for inference.
Consider a hypothetical portal where a new role can approve documents. A useful answer needs the role name, permitted actions, restrictions on older plans and the access start date. With a phased rollout, the release date alone does not establish a particular customer's eligibility. A test question such as “Why can't I see the button?” must consider these conditions rather than merely retrieve an article bearing the new feature name.
The site's approach to AI workflows with verifiable results starts with a bounded task and reference examples. For knowledge readiness, that task could be narrow: explain eligibility for one new feature without changing customer records. This separates answer quality from the ability to execute actions.
One change package instead of several retellings
Before release, assemble a fact package confirmed by the feature owner. Include the customer workflow, eligibility conditions, known exceptions, setup instructions and the route for reporting problems. Support owns clear wording; the product team confirms limitations; a designated editor resolves contradictions between materials.
Intercom's NPI process captures feature ownership, beta and release dates, plan availability and troubleshooting information, then uses the package to prepare content. Another team might keep the package in a release ticket. The tool matters less than a verified source and a person authorised to correct a fact.
Separate knowledge from conversational rules. Plan eligibility belongs in the knowledge base; an instruction to escalate a disputed request belongs in behaviour guidance. AI support conversation design explores that boundary. Combining both in one long instruction turns a plan update into a review of the entire conversation policy.
Updating also means retiring and retaining
Intercom's May 27 knowledge management guide covers both creating a knowledge base and maintaining it. Its listed sources include public articles, internal guidance, past conversations and documents. Bringing them together does not make every statement current: an old conversation may contain a temporary exception, and an internal note may contain information customers should not receive.
A release therefore needs a search for dependent content. A new article does not correct an old interface hint, a staff reply template or a duplicate guide. For each match, choose whether to update it, remove it from use or retain it for a clearly identified older version. Archiving everything old may harm customers who have not migrated.
In the hypothetical portal, some organisations retain the previous role. Both guides may remain useful if each states its applicable version and access conditions. If the system cannot reliably select the right instructions, a clarification or human handoff is preferable to confidently mixing rules. The limiting factor is available context rather than the model's writing ability.
Test the questions that follow the announcement
Build acceptance examples around customer actions: enable the feature, check a permission, troubleshoot an error and restore previous behaviour. Add everyday wording and incomplete messages alongside official terminology. Record the expected source, acceptable explanation and grounds for declining to answer for each example.
“Approval disappeared” might refer to a changed interface, an insufficient role or an unavailable plan feature. Giving all three situations the same answer exposes a failure to distinguish conditions. If the information exists but the system misses the passage, another article may not help. Check retrieval first. The guide to hybrid search and tokenization explains why exact names and identifiers deserve their own tests.
Acceptance also needs to cover language. Russian and English instructions may describe the same feature with different terminology; testing one does not validate the other. A screenshot helps a person, but the key actions should be written out. Intercom likewise recommends pairing visual instructions with explanatory text.
Connect launch preparation to early corrections
A small team can add a knowledge owner, a list of changed materials and question-test results to the release ticket. For critical topics, restrict automated answers until the source has been checked. After launch, collect conversations about the specific feature, identify incorrect explanations and examine whether customers need to contact support again.
Intercom describes monitoring complex launches for up to four weeks and standard launches for two. Those periods are company practice rather than a universal rule. Choose a window based on conversation volume and rollout pace so that exceptions and questions from older customers become visible.
Chatbots that pass work into business systems require a clear account of what reaches an employee after the dialogue. Knowledge readiness begins earlier: every changed feature needs a current, understandable and testable answer. Start with the next release and map the affected knowledge before publishing the announcement.