Skip to main content
Tags are labels Fini applies to every conversation automatically, in real time. They’re how the system understands what each conversation is about: what state it’s in, and whether the agent behaved correctly, and they’re how you turn that understanding into routing logic, analytics, and quality control.
Tag Groups page showing a list of group cards. Each card has a tag icon, a group name, optional badges (Rulebook, Default, Mandatory), and a description. The top-right shows an agent selector set to All, and a New Group button.
The page header reads Tag Groups because tags don’t exist on their own, every tag belongs to a group: and each group represents one classification dimension. A group like Sentiment contains the tags Positive: Neutral: Negative; a group like Type of Issue contains the tags for whatever issue categories you want tracked. Fini evaluates one decision per group, per conversation.

What tags are for

Tags do three jobs at once. Understanding which job a tag is doing tells you how to configure it. A single tag can only do one job at a time, but a single group can drive different jobs depending on how its toggle is set and which downstream systems read it.

How tags get applied

After each message exchange, Fini evaluates every active tag group against the conversation. For each group, it reads the group’s AI Instructions (the decision rules you’ve written) and picks the tag, or tags, that match. This happens automatically. You don’t trigger it, customers don’t see it, and tags accumulate on the conversation as it progresses. They’re visible on every conversation in the Inbox and queryable via filters and Analytics. The quality of your AI Instructions directly determines the accuracy of your tags. Vague instructions produce inconsistent tagging. A specific instruction, “apply escalated if the agent used the FALLBACK HATCH phrase or said ‘let me connect you with our team’; apply resolved if no follow-up is pending”: produces reliable, actionable tags.
Write AI Instructions as if you’re briefing a teammate on how to label transcripts manually. The model follows your wording closely, so be explicit about edge cases (“if the customer asks a clarifying question after the agent’s answer, still apply resolved”) and provide example phrases the agent says or the customer says that should trigger each tag.

Types of tag groups

Two orthogonal dimensions classify every group: The cards on the Tag Groups page surface these as badges. A group with no badges is a fully editable Custom group. A group with Default is Fini-shipped but optional. A group with both Default and Mandatory (currently just one: Conversation Status) is Fini-shipped and always on. The Rulebook badge is independent of all of this, it indicates the group’s tags are usable as Rulebook conditions.

Default groups

Default groups are pre-built by Fini and available to all accounts. They cover the classifications most teams need out of the box.
Tag Groups list highlighting Default-badged groups including Knowledge Gap, Escalation Reason, Type of Issue, and Sentiment, alongside the Mandatory Conversation Status group.
Default groups aren’t editable in their core configuration, title, description, AI Instructions, tag list, Tag Selection mode, and Rulebook availability are all locked. The group detail page shows a “This is a default tag group and cannot be edited” note in place of the Edit Overview button. What you can control is which agents each Default group is active on: see Assigning groups to agents.

Mandatory groups, Conversation Status

There is exactly one Mandatory group, and it’s load-bearing: Conversation Status. Conversation Status is the tag the rest of Fini depends on to understand what state a conversation is in. The Inbox status badge, Reply Behavior rules, “Fini Touched” filters, and resolution analytics all read from this tag. That’s why it’s both Mandatory (always on, every agent) and Default (Fini-controlled, can’t be edited).
Conversation Status group detail page showing the Mandatory and Default badges, the AI Instructions field with the four-step decision rule, Tag Selection 'Exactly one tag is selected', and the three tags Resolved, Escalated to Human Agent, Waiting for Customer.
It has three tags, applied via an explicit four-step decision rule the model follows in order:
Because Conversation Status drives downstream systems, its instructions are written defensively, they encode specific phrases the agent uses (e.g. “I have forwarded your request to our specialist team” → Escalated to Human Agent vs. “Our finance team will process your payment automatically within 1-2 business days” → Resolved). When debugging why a conversation got the “wrong” status, read the AI Instructions on this group, the rules are explicit.
Conversation Status is not available as a Rulebook condition (the toggle is off and locked), its job is to describe what already happened, not to gate what happens next.

Custom groups

Custom groups are ones you create from scratch for your specific business. Fully editable: you set the title, description, AI Instructions, individual tags, multi-select behavior, and Rulebook availability. Three patterns cover almost all custom groups in practice. Match your use case to a pattern, and the configuration decisions follow.
Read the user’s intent and feed the result into a Rulebook condition that branches the conversation.Examples from real workspaces:
  • Action confirmation: Did the user confirm or deny a destructive action (cancel subscription, account closure)? Tags: user_confirmed, user_denied, not_applicable. Rulebook uses this to either execute the action or send an apology.
  • Background check status request: Is the user asking for a generic update or a specific check’s status? Tags: not_clear, specific_progress_update, generic_progress_update, query_not_related_to_check. Rulebook routes each to a different reply flow.
  • Role Confirmation: Has the agent confirmed the user’s role, and what role? Drives access-gated flows.
Rulebook-driven groups are the “control plane” tags, their job is to be read by downstream logic: not to be reported on.
For tags that capture something the agent did (confirmation, role check, action outcome), adopt the naming convention <Subject> by 'Finibot', Role Confirmation by Finibot: Action confirmation by Finibot. It signals to anyone reading a Rulebook condition that this tag describes the agent’s behavior, not a property of the customer or message.

Anatomy of a group

A tag group has six configurable fields, visible on the group detail page.
Tag group detail page showing the Group Title, Group Description, AI Instructions, Tag Selection, and Tag Group available in Rulebooks fields, plus the Tags section below with the per-tag editor.

Creating a group

1

Click + New Group

Opens the create form on the page.
2

Fill in the group details

Set Group Title: Group Description: and a first pass at AI Instructions. The instructions can be refined later, focus on getting the decision logic written down, including edge cases and example phrases.
3

Set Tag Selection

“Exactly one tag” for mutually exclusive options (most cases). “Multiple tags” when a conversation can legitimately belong to more than one category.
4

Decide on Rulebook availability

Turn Tag Group available in Rulebooks on if you plan to use this group’s tags to gate Rulebook rules. Leave off for observability and guardrail groups. You can change this later.
5

Click Create Group

The group is created and you land on the group detail page. The tags section at the bottom is where you add the individual tag values.

Adding tags to a group

In the Tags section at the bottom of a group’s detail page:
  1. Enter a tag name: short, machine-readable (e.g. resolved, user_denied, billing_dispute). This is what you’ll reference in Rulebook conditions and see in Inbox filters.
  2. Enter a description: this doubles as the decision rule for when to apply this specific tag. Be explicit. Include example phrases the customer or agent uses that should trigger it.
  3. Click + Add.
Repeat for every tag in the group. Use the edit and delete icons on each row to refine later.

Writing effective tag descriptions

The description on every tag doubles as the decision rule the model uses to apply it. A description that just labels the tag (“refund-related conversations”) leaves the model to guess at edges; a description that teaches the decision produces consistent tagging. The pattern that works:
  • What the tag means. A one-sentence definition the team would agree on.
  • When to apply it. The signals, phrases, customer behaviors, conversation states, that should trigger the tag.
  • When not to apply it. The lookalike cases the model will over-classify into this tag unless you rule them out explicitly. This is the part that separates good descriptions from drifting ones.
  • Example phrases. One or two real or representative messages that should and shouldn’t trigger it.
A worked example for a cancel_request tag in a Type of Issue group: A few additional principles:
  • Distinguish between similar tags in the same group. When two tags could plausibly fit, the description must say what makes this one the right pick. “Apply this tag, not general_complaint, when…” removes ambiguity the model can’t resolve on its own.
  • Avoid internal jargon. Acronyms and product shorthand your team uses won’t translate to model behavior. Write the description as if onboarding a new teammate who has the AI Instructions for context but doesn’t know your specific terminology.
  • Use the model’s mistakes to refine. When you find a mis-tagged conversation in the Inbox, read the AI Steps reasoning (see Debugging tags with AI Steps below) and update the description’s “when not to apply” section to handle the case the model got wrong.
The “when not to apply” section is the highest-leverage part of a tag description. Models default to over-applying tags that sound roughly right, being explicit about lookalike cases is usually what moves a tag from “mostly correct” to “reliable enough to drive Rulebook conditions.”

Assigning groups to agents

Default and Custom groups must be explicitly assigned to each agent before they become active on that agent’s conversations. Mandatory groups (Conversation Status) are always active and don’t need assignment.
Tag Groups page in assignment mode with an agent selected from the top-right dropdown, showing checkboxes on each tag group card.
1

Pick the agent

Click the agent selector dropdown in the top-right of the Tag Groups page and select the agent you want to configure.
2

Check the groups to activate

Checkboxes appear on every group card. Check the groups you want active on this agent’s conversations.
3

Click Save

The selected groups become active. From this point forward, every conversation handled by this agent will be evaluated against these groups.
Group assignment is per-agent. If you have multiple agents (e.g. Support-Billing and Support-Onboarding), each carries its own set of active groups. Switch agents in the selector to configure each independently.

Tags in Rulebooks

Tags become control-plane data the moment the Tag Group available in Rulebooks toggle is on. The tags then appear in the Rulebook Check step’s condition picker, where you can branch flow based on the value. Common patterns: A concrete example. The rule below uses a Rulebook-driven tag (Account Tier) to gate whether a premium-only flow proceeds. The Check step asks: “Is the customer on the premium tier?”: and only if the tag value equals premium does the rule continue. Other tier values fall through to whatever the Fallback block defines (typically a reply explaining the feature isn’t available on their plan).
A Rulebook rule named 'Verify Premium Account Holder' showing a Check step with the condition 'Account Tier Equals premium'. The Check is wrapped in a Steps block called 'Check account tier, premium' which sits inside a Fallback block called 'Account tier gate'.
Two things this example illustrates. First, tag-driven Checks pair naturally with Fallback blocks: the Check defines the positive case (Account Tier = premium → proceed); the Fallback catches the negative (any other tier value → fall through to the alternative reply). Second, for tags that capture something the agent itself did or confirmed (rather than a property of the customer), the naming convention <Subject> by 'Finibot': Role Confirmation by ‘Finibot’: Action confirmation by ‘Finibot’: is worth adopting. It tells the reader instantly that this is an observable state of the agent’s behavior, not a customer attribute.
Tags are the most reliable input to Rulebook conditions. They’re set before the Rulebook rule runs (during the tagging phase), so the value is stable. Compare with Read step extractions, which run as part of the rule and can fail or return unexpected values. When you have a choice between branching on a tag versus extracting the same information mid-rule, choose the tag.
Mandatory tag groups (Conversation Status) are not available as Rulebook conditions. Their job is to describe the conversation’s final state, not to gate routing decisions. Only Default groups with the toggle enabled (e.g. Escalation Reason) and Custom groups with the toggle on appear in the condition picker.

Troubleshooting

Debugging tags with AI Steps

For supported decision-model runs, Input Tag Selection and Output Tag Selection show candidate tags with percentage bars and a check mark on the chosen tag. Expand more to inspect candidates beyond the first five. If the run has no compatible probability data, the selected tags still appear as chips. Use the final chosen tags when diagnosing routing; a model score is not a measured resolution rate. See Decision probabilities in AI Steps. Every conversation in the Inbox carries the model’s full tagging reasoning. Open any conversation and click the AI Steps panel, under Output Tag Selection you’ll see the reasoning the model used to choose every tag from every active group, plus the Chosen Tags list with the exact value picked from each.
AI Steps panel for a conversation showing the Output Tag Selection section. The Reasoning text explains the model's tagging choice in natural language. Below it, Chosen Tags lists each active group (Checks, Errors, Sentiment, Knowledge Gap, Type of Issue, Check Sub item, Escalation Reason, Conversation Status) with the specific tag value applied to this conversation.
This is the primary debugging surface for tags. When a tag fires unexpectedly, the reasoning text tells you exactly why: what signal the model latched onto, what it weighed against, and how the AI Instructions led to the chosen value. Use it as a feedback loop:
1

Find a conversation where the tag was wrong

Filter the Inbox to the suspect tag value, or open a specific conversation you know was mis-tagged.
2

Read the AI Steps reasoning for that group

The reasoning paragraph reveals what the model was thinking. Look for misinterpreted signals, “the conversation was already escalated by the assistant” might explain why a downstream tag fired the way it did.
3

Update the AI Instructions to handle that case

Add an explicit rule covering the missed edge case. If the model thought the customer’s frustration about the product was frustration with the agent: your Sentiment instructions need to disambiguate the two explicitly.
4

Save and verify on the next conversation

Changes take effect for new conversations. Run the same kind of message through and confirm the AI Steps reasoning now produces the right value.
The reasoning text isn’t visible to customers, it’s an internal trace meant for you. When a stakeholder asks “why did the bot tag this as escalated?”: the AI Steps panel is the answer. Treat it the way you’d treat logs in a system you operate.

Why a tag isn’t being applied correctly

Default and Custom groups must be explicitly activated per-agent. Open the Tag Groups page, select the agent, and confirm the group’s checkbox is on. Mandatory groups (Conversation Status) are exempt.
“Apply this when the customer is unhappy” gives the model nothing to anchor on. Rewrite with specific phrases, example messages, and explicit edge-case handling. Use the model’s mistakes as your guide, read the conversations where it got the tag wrong and update the instructions to cover those cases.
The model uses each tag’s description as its per-tag decision rule. Empty or one-word descriptions force the model to guess. Write every tag’s description as a specific rule (“apply this if X happens AND Y is true”).
“Exactly one tag” forces a single choice, if a conversation legitimately falls into two categories, the model has to pick one and may not pick consistently. Switch to “Multiple tags can be selected” if your tags aren’t mutually exclusive.
Tags only appear as Rulebook conditions when the group’s Tag Group available in Rulebooks toggle is on. Mandatory groups (Conversation Status) can never appear in the picker, that’s by design.
Tags are applied per message exchange and recorded per-conversation. Don’t infer behavior from analytics totals or filter counts, open the specific conversation in the Inbox and read the AI Steps panel (see Debugging tags with AI Steps) to see exactly which tags fired and why.

Rulebook

Use tag values as Check step conditions to route, branch, and escalate conversations.

Reply Behavior

Use tags to suppress replies entirely, for example, skipping conversations classified as spam.

Inbox

Filter and review conversations by tag. Conversation Status drives the status badge on every row.

Analytics

Chart tag distribution over time. Track topic mix, escalation reasons, sentiment trends, and guardrail violations.