Docs
Knowledge Base

Tag-Scoped Knowledge

Scope AI retrieval so each ticket only draws on knowledge meant for its audience.

Tag-scoped knowledge lets you restrict which knowledge base articles, crawled pages, and reply templates the AI considers for a given ticket. If your workspace serves multiple audiences — for example, one brand that supports both business customers (b2b) and consumers (b2c) — you can tag knowledge so a b2b ticket only retrieves b2b or shared content, and never sees b2c-only material. Workspaces that don't use tags are unaffected.

How audience scoping works

A ticket carries a set of audience tags drawn from its email alias, routing rules, and operator-applied tags. When the AI retrieves knowledge, it keeps only items whose audience tags overlap the ticket's tags, plus the shared pool of untagged items. This applies identically whether the ticket arrives by email or through the chat widget.

Three knowledge sources support audience tags:

  • Crawl sources — audience tags cascade to every article imported from that source
  • Knowledge base articles — audience tags apply only to that article
  • Reply templates — audience tags control which tickets see the template in AI suggestions

The shared pool

Knowledge with no audience tags is eligible for every ticket, regardless of the ticket's tags. This is the default state of all existing content, so retrieval is unchanged for workspaces that never set tags. Leave broadly-applicable knowledge — general policies, hours, shipping information — untagged so it stays in the shared pool.

How tickets get their tags

Tickets acquire audience tags in three ways:

  1. Email alias autoTags — every ticket sent to an alias inherits that alias's tags. See Multi-Alias Email.
  2. Routing rules — rules tag tickets based on the To address, subject, or other fields. See Multi-Alias Email.
  3. Operator action — operators apply tags manually, and auto-tag rules can add tags automatically.

Scoping only has an effect if tickets actually get tagged. If a ticket has no audience tags, retrieval falls back to the full knowledge pool.

Tagging a crawl source

  1. Go to Knowledge base in the sidebar
  2. Select the Website sources tab
  3. Add a source or edit an existing one
  4. Set Audience tags — the helper text reads: "Scope AI retrieval to tickets with these tags. Empty = shared pool."
  5. Save

Source-level audience tags propagate to every article that source produces, on the first crawl and on each re-crawl. For more on crawl sources, see Website crawling / Import.

Tagging a knowledge base article

  1. Go to Knowledge base in the sidebar
  2. Select the Articles tab
  3. Click New article or edit an existing article
  4. Set Tags
  5. Save

This is for manually authored articles. Crawled articles get their tags from the crawl source, and those tags are re-applied on every re-crawl. See Creating Articles for more on writing articles.

Tagging a reply template

  1. Go to Templates in the sidebar
  2. Create a new template or edit an existing one
  3. Set Audience tags — the helper text reads: "Scope AI template suggestions to tickets with these tags. Empty = shared pool."
  4. Save

This scopes which tickets see the template in AI suggestions, using the same match-any and shared-pool rules as knowledge base articles. For everything else about reply templates — variables, subject lines, and inserting them in the composer — see Reply Templates.

Match semantics

Three rules determine whether a piece of knowledge is eligible for a ticket:

  • Match-any (overlap), not match-all. Any single shared tag makes a piece of knowledge eligible. An article tagged b2b, b2c is retrieved on a ticket tagged only b2b. The product deliberately uses overlap rather than intersection.
  • Exact, case-sensitive strings. B2B and b2b are different tags. They only match if spelled identically.
  • System tags don't count. crawled is applied automatically to crawled articles and is never treated as an audience tag — on the ticket side or when deciding whether knowledge is shared. A crawled article with no other tags is therefore still in the shared pool.

What "untagged" means

There are two sides to "untagged":

  • Knowledge with tags = [] (no audience tags) is shared, eligible for every ticket.
  • A ticket with no audience tags triggers no filter at all; the entire knowledge pool is eligible. This is the backward-compatibility guarantee — workspaces not using tags see zero change in retrieval behavior.

Tag scoping applies to knowledge sources — crawled pages, KB articles, and reply templates. It does not restrict the AI's use of prior conversation history.

A worked example: B2B and B2C

Your workspace has a business inbox whose alias autoTags tickets b2b, and a consumer inbox whose alias autoTags tickets b2c. Given the following knowledge items:

Knowledge item (audience tags)b2b ticketb2c ticketWhy
Article tagged b2bYesNooverlaps the b2b ticket only
Article tagged b2b, b2cYesYesoverlaps both (match-any)
Article tagged b2cNoYesnever overlaps a b2b ticket
Untagged article ([])YesYesshared pool — eligible for all tickets
Crawled article tagged only crawledYesYescrawled is a system tag, not an audience tag → still shared

A ticket that has no audience tags would retrieve every row above.

Common pitfalls

  • Case mismatch. B2B won't match b2b. Pick one casing convention and use it for alias autoTags, routing rules, and knowledge tags alike.
  • Accidentally scoping shared content. Tagging a general article such as a refund policy or hours page with b2b silently removes it from b2c tickets. Leave content that applies to everyone untagged.
  • Re-crawl re-inheritance. A crawl source's audience tags are re-applied to its articles on every refresh, overwriting any audience tags you set manually on an individual crawled article. Set audience tags on the source, not on the crawled article.
  • Tags only help if tickets carry them. If your aliases or routing rules don't tag incoming tickets, knowledge-side tags have no effect. Verify tickets are getting tagged before relying on scoping.

On this page