What a tag is
Two pieces. A type that says which lens this tag uses, and a place in the hierarchy that says how specific it is. Together they let you classify at the right altitude — broad when you want trends, narrow when you want precision.
1Two lenses
— what is it about, vs. what’s notable about it
Topic
red — the subject
What the conversation is about
The substance of the request. Returns, Billing, Shipping, Technical issue. Topic tags are how you bucket conversations by subject for filtering, routing, and rolling up trends.
Metadata
blue — the context
What’s notable about the conversation
Side information that travels with the conversation regardless of subject. VIP, Escalated, Follow-up needed, First-contact. Metadata tags answer “what should we know about this one” rather than “what is this one about.”
Type lives on the root tag, not on every node. When you create a top-level tag you choose Topic or Metadata. Anything you add underneath it inherits that type — a sub-tag of a Topic root is itself a Topic tag. This keeps the library coherent: a single branch of the tree can’t mix the two lenses.
And tags can nest, so the same library serves both broad reports and narrow ones ↓
2Hierarchy
— sub-tags let you drill down without exploding the top level
Roots are broad
Returns, Billing, Shipping. The buckets you’d use in a board-level report — coarse enough that every conversation in that bucket is recognisably the same kind of work.
Sub-tags are specific
Under Returns: Defective product, Wrong item, Changed mind, Size exchange. Under Billing: Invoice request, Payment failed, Refund status. Specific enough to drive a workflow, not just a report.
Roll up or drill down without changing how you tag. When a conversation is tagged Defective product, it’s implicitly also a Returns conversation. So a question like “how many returns this month?” and “how many defective returns this month?” both have answers from the same data — just at different levels of the tree.
How a tag gets applied
Three paths. An agent picks one in the conversation view, an admin applies many at once across a selection, or Sidekick reads the conversation and applies tags on its own. The same tag library feeds all three.
1Manual, in the conversation
— the agent picks tags as they work
In-thread
Add or remove a tag from the conversation panel
Inside any conversation, the tag dialog opens a searchable picker scoped to your full tag library. Type to search (matches expand their ancestors automatically), pick from the tree, and the tag is on. Removing one is a click. Tags appear inline on the conversation so the next agent who opens it sees what’s already known.
When you need to label many conversations at once ↓
2Bulk, from the Monitor
— one tag, many conversations
Selection
Select conversations, apply a tag to all of them
From the Monitor, select any group of conversations and open the bulk tag dialog. Type a tag name — if it exists, it’s suggested; if it doesn’t, you can create it inline. The tag is applied to every conversation in the selection in one step. Useful for retroactive cleanup, post-incident labelling, or grouping a batch you want to revisit.
And when you don’t want to think about it at all ↓
3Automatically, by Sidekick
— opt-in per tag, evaluated as the conversation evolves
Opt-in per tag
a switch on each tag
You choose which tags Sidekick is allowed to apply
Each tag has an AI Auto-Tag toggle. Off by default. When on, Sidekick can apply that tag automatically — provided you’ve given it a description it can match against. Tags without a description don’t participate.
Continuous
debounced per conversation
Re-evaluated as the conversation evolves
New messages queue an auto-tag job with a short debounce, so a flurry of replies turns into one evaluation, not many. Sidekick keeps a rolling summary per conversation, so it isn’t starting from scratch each time — it tags in light of everything said so far.
Vector + LLM
how the choice is made
A short-list, then a deliberate pick
Each auto-tag-enabled tag is embedded from its description. When a job runs, Sidekick vector-searches for the closest tags to the current conversation, then asks the model — in a single call — to update the summary and pick which of the candidates actually apply. Vector search proposes; the model decides.
Additive
never silently un-tags
Auto-tagging adds, never removes
Tags Sidekick selects are written to the conversation. Tags that no longer fit aren’t removed automatically — once a tag is on a conversation, an agent or a rule has to take it off. Auto-tagging is a labelling layer, not a self-correcting one.
The description is the prompt. A tag’s description isn’t cosmetic — it’s what gets embedded for the vector search and what the model sees when it’s deciding. “Refunds” is a hint. “Customer is asking about a refund for a completed order, including refund status, partial refunds, and refund timelines” is a working tag. Write them like you’re briefing a new teammate.
What a tag activates
A tag earns its keep when other parts of the product read from it. Four places do, today.
1Filterable views
— tags as a slicing dimension
Build views around tags
The Monitor lets you save views that filter by tag — alone or combined with team, channel, agent, AI status. “All open conversations tagged Billing”, “VIP escalations from this week”, “Anything Sidekick tagged Defective product but the agent hasn’t touched yet.” Tags are how you bend the inbox to the question you’re asking right now.
And rules can read or write them ↓
2Automation Rules
— both as triggers and as actions
Trigger
on tag added / removed
Run when a tag is applied
Rules can listen for tag added or tag removed events — whether the tag came from an agent, a bulk action, or Sidekick. The conversation that just got tagged is the rule’s subject; what to do next is up to you.
Condition
on conversation tags
Branch on which tags are present
Inside any rule, conditions can ask whether the conversation carries a particular tag. Combine with channel, status, customer, or any other condition to narrow the rule down to exactly the situation you mean.
Action: Add tag
tag from a rule
Apply a tag as an outcome
Rules can apply a tag — existing or created inline — as one of their actions. Useful for marking conversations a downstream rule will need to pick up, or for auditing what a workflow did.
Action: Remove tag
undo, on completion
Take a tag off when the work is done
The mirror action: clear a tag once whatever it represented has been resolved. Combined with tag added as a trigger, you can build small state machines — tag goes on when the work needs doing, comes off when it’s done.
Specialist agents can prefer the topics they’re built for ↓
3Agent stack routing
— specialists associated with tags
Associate a specialist with the tags it should handle
Inside an Agent Stack, each Specialist Agent can be linked to a set of tags — the topics that specialist is built for. When the router is choosing where a conversation should go, those tags are part of the signal. A Returns Specialist linked to Returns and its sub-tags is the natural pick when those tags are present.
And tiers can carry tags forward automatically ↓
4Customer tier auto-tags
— tags that travel with the contact
Tags applied because of who is asking, not what they’re asking
Each Customer Level can carry a list of tags that get applied to conversations from contacts at that level. VIP contacts arrive pre-tagged VIP; partner accounts arrive tagged Partner. The same downstream machinery (views, rules, routing) then reacts to the tag without caring how it got there.
Managing your tag library
Tag Management is where the library lives. Three panes — roots on the left, the tree of the selected root in the middle, the editor on the right. Everything you can do to a tag happens here.
1What you can do
— from one screen, on any tag
+
Create a root tag
Name, description, and choose Topic or Metadata.
→
Add a child
Sub-tags inherit the root’s type automatically.
⚙
Edit name & description
The description doubles as the AI auto-tag prompt.
☀
Toggle AI auto-tag
Per-tag switch — opt in only the tags you trust.
⇅
Re-parent
Move a tag — or a whole subtree — to a new parent.
☉
Search the tree
Matches expand their ancestors so you can see context.
The library is shared across every place tags surface. One tag, one definition, one description. The same Returns tag the agent picks in a conversation is the one Sidekick can auto-apply, the one a rule can listen for, the one an agent stack can route on, the one a tier can carry forward. Edit it once and every consumer sees the new behaviour.
