Support KB Conditions: When Does This Answer Apply?

Support KB Conditions: When Does This Answer Apply?

Support KB articles should include conditions that define when an answer applies so AI can deliver the right information to the right customer.
Accurate information is not enough. AI also needs to know who the answer is for and when it should be used.
Without that information, AI can retrieve the right article and still give the wrong answer to the wrong customer.
A feature may only exist on certain plans. A workflow may require admin permissions. A setting may only be available on mobile. The answer itself can be completely accurate and still be wrong for the person receiving it.
Conditions exist to prevent that.


Why conditions matter

Consider this answer:
Enable Advanced Reporting from Settings.
That answer might sound accurate.
Now add the conditions:
  • Business and Enterprise plans only
  • Admin role required
  • Web platform only
Without those conditions, a Starter customer on mobile receives instructions they cannot use.
The problem was not the answer.
The problem was missing conditions.
The right answer for the wrong situation is still the wrong answer.


The "Applies to" section

For customer-facing content, conditions are often easiest to communicate through an Applies to section.
If you prefer a different label, alternatives work too:
  • Who this is for
  • Availability
  • Requirements
The name matters less than consistency.

Common condition types include:

Condition
Description
Example
Plan
Include when features differ across pricing tiers.
Business and Enterprise plans
Platform
Include when behavior differs by device or application.
Web only
User role
Include when permissions affect access.
Admin users only
Integrations
Include when a connected product or service is required.
Stripe integration required
Region
Include when features vary by geography or legal requirements.
Available in the US and Canada
The conditions you use depend on your product. Some products may also need product version, account state, feature flags, subscription status, legacy account types, or other product-specific conditions. These are common examples, not a required set of fields.

The decision rule

If it changes the outcome, include it.
If it doesn't change the outcome, omit it.

What unnecessary conditions look like:

Applies to
  • Web
  • Mobile
  • Desktop
Use conditions to make boundaries clear, not to confirm that an answer applies everywhere.

Better:

Applies to
  • Platform: Mobile only
Conditions should explain what must be true for the answer to apply.


Structured vs embedded conditions

Not every condition needs a formal block.
Use a structured section when multiple conditions exist or when customers repeatedly need the information. Use natural language when the condition only matters once.

Structured example:

Applies to
  • Plan: Business and Enterprise
  • Role: Admin users
  • Platform: Web platform
Use natural language when the condition only matters once.

Natural language example:

This setting only appears after connecting Stripe.
The goal is not maximum structure. The goal is clear applicability.


Conditions are not access controls

Conditions written inside an article help customers, support teams, and AI systems understand when an answer applies.
They do not replace system-level controls.
For example, an Applies to section can say that a feature is available on Business and Enterprise plans. That helps the reader understand the answer. But if an AI system needs to prevent Starter customers from receiving certain instructions, it should rely on real customer data, not only on the AI interpreting the article text correctly.
Use written conditions to make applicability clear.
Use system-level rules, filters, or customer data when retrieval needs to be controlled more strictly.
The goal is not to restrict every answer. The goal is to reduce situations where AI gives an answer that does not apply to the customer.


Use consistent values

Conditions only work when the values themselves stay consistent.
If your plans are Starter, Business, and Enterprise, use those exact words everywhere. If your platforms are Web and Mobile App, use those exact labels across every article.
Conditions break when different words are used for the same thing. Consistency here isn't a writing preference. It's part of the system.


The conditions test

Before publishing an article, ask:
  • Can every customer actually use this answer?
  • Does access depend on plan?
  • Does access depend on platform?
  • Does access depend on user role?
  • Does access depend on integrations, account state, or other requirements?
If the answer depends on specific conditions, include it.
Conditions are what turn a correct answer into the right answer for the right situation.