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:
- Email alias autoTags — every ticket sent to an alias inherits that alias's tags. See Multi-Alias Email.
- Routing rules — rules tag tickets based on the
Toaddress, subject, or other fields. See Multi-Alias Email. - 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
- Go to Knowledge base in the sidebar
- Select the Website sources tab
- Add a source or edit an existing one
- Set Audience tags — the helper text reads: "Scope AI retrieval to tickets with these tags. Empty = shared pool."
- 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
- Go to Knowledge base in the sidebar
- Select the Articles tab
- Click New article or edit an existing article
- Set Tags
- 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
- Go to Templates in the sidebar
- Create a new template or edit an existing one
- Set Audience tags — the helper text reads: "Scope AI template suggestions to tickets with these tags. Empty = shared pool."
- 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, b2cis retrieved on a ticket tagged onlyb2b. The product deliberately uses overlap rather than intersection. - Exact, case-sensitive strings.
B2Bandb2bare different tags. They only match if spelled identically. - System tags don't count.
crawledis 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 ticket | b2c ticket | Why |
|---|---|---|---|
Article tagged b2b | Yes | No | overlaps the b2b ticket only |
Article tagged b2b, b2c | Yes | Yes | overlaps both (match-any) |
Article tagged b2c | No | Yes | never overlaps a b2b ticket |
Untagged article ([]) | Yes | Yes | shared pool — eligible for all tickets |
Crawled article tagged only crawled | Yes | Yes | crawled 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.
B2Bwon't matchb2b. 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
b2bsilently removes it fromb2ctickets. 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.