Fin Attributesはすべての会話を自動的に分類します。属性を使うことで、問題の種類、感情、緊急度を定義できます。会話は即座にタグ付けされ、適切なチームにルーティングし、適切なアクションをトリガーし、手動作業なしで正確なレポートが得られます。

クイックスタート：3ステップでFin Attributesを設定する方法

検出する内容を決める
Finに分類させたい構造化された属性を選択します。例：問題の種類、感情、緊急度、スパムなど。
属性を作成または変換する
Fin → Train → Attributesにアクセスし、明確な説明で属性値を定義するか、既存のリスト形式の属性を変換します。
プレビューして有効化する
プレビューツールを使ってFinの精度をテストします。値の説明を調整し、その後実際の会話で属性を有効にします。

有効化後は検出された属性値をEscalation Rules、Workflows、およびReportingで使用できます。

主な利点

ビジネスに合わせたカスタム属性：Finをトレーニングして、問題の種類、緊急度、感情、スパム状態などの属性を検出させます。
インテリジェントで適応的な検出：Finは重要な瞬間にコンテキストを評価し、会話の進行に応じて値を更新します。
スマートなルーティングとエスカレーション：Fin AttributesをworkflowsやEscalation Rulesと組み合わせて、適切なタイミングで適切なチームに会話をルーティングします。
レポート対応の構造：検出されたすべての属性データはIntercomのレポートに流れ込み、詳細な洞察を提供します。手動でのタグ付けは不要です。
完全な透明性とコントロール：いつでもFinの属性ロジックを表示、検証、上書きできます。

注意：すでにAI Category Detectionを使用している場合は、Fin Attributesとの比較方法と移行方法を確認してください。

Finが会話に属性を適用する方法とタイミング

1. デフォルト：Finの役割が完了したときに属性を適用する

デフォルトでは、Finは会話における自分の役割が完了したと判断したときに属性を割り当てまたは更新します。例：

チームメンバーに引き継ぐとき
顧客が解決（ポジティブなフィードバック）を示したとき
顧客が非アクティブになったとき

💡 なぜ重要か：これらの瞬間は会話の意図や結果が明確になる自然なタイミングです。ここで属性を適用することで、ルーティングやレポートが顧客のニーズの最終的な文脈を反映します。早期の推測ではありません。

このデータを使って以下が可能です：

WorkflowsでのFin後のルーティングや引き継ぎロジックを定義（例：「問題の種類がBillingならFinanceチームへルーティング」）
Finが対応または引き継いだ問い合わせの種類に関する正確なレポートを生成する。

重要：Fin Attributesは会話に対してのみ自動検出・適用されます。ticketsには自動検出されないため、ticketsを扱う際はFin Attributesを手動で設定または更新する必要があります。

2. 動的再検出（Escalation Rulesで使用時）

Fin Attributeがescalation rulesで使用されると、Finは最新の顧客インタラクションに基づいてその属性を自動的に再評価します。

💡 なぜ重要か：この動作により、Finはエスカレーションが必要な顧客の意図や感情の変化に即座に反応します。例えば、問題の種類が一般的な質問から返金要求に変わった場合、Finはルールに従って即座に会話を引き継ぎ、チームメンバーが適切なタイミングで介入できるようにします。

注意：パイプラインは新しいユーザーメッセージごとに完全に再実行されますが、MLモデルは最新メッセージだけでなく会話全体の文脈に基づいて分類します。

3. オプション：クローズ時に検出

属性の「クローズ時に検出」を有効にすると、会話がチームメンバーまたは自動化によってクローズされた際にFinが値を再チェック・更新します。これは属性作成または編集時に有効化できます。

💡 なぜ重要か：スレッドの後半で新しい情報や文脈が出てきた場合、Finは分類を最終的に修正・調整するチャンスを得ます。これにより、会話の後半で状況が変わってもレポートの正確性が保たれます。

Fin Attributesの設定方法

ステップ1：分類する内容を決める

Finに検出させたい構造化情報の種類を考えます。一般的な例は以下の通りです：

問題の種類（例：Billing、Projects、Account Management）
感情（ポジティブ、ニュートラル、ネガティブ）
緊急度（Urgent、High、Normal、Low）
スパム検出（Spam、Legitimate）

ステップ2：新しい属性を作成（または既存の属性を変換）

新しいFin Attributeを作成するには：

開始するにはFin > Train > Attributes にアクセスしてください。
新規作成をクリック。
属性の名前と説明を入力します。
属性値を追加します（それぞれに明確な説明を付けて）。

ヒント：効果的な属性名と説明の作成方法を学び、Finがサポート会話を高精度で分類できるようにしましょう。

既存の属性を変換するには：

設定 > データ > 会話に移動し、リスト形式の属性の編集をクリックしてから、Let Fin detectをクリックします。
変換後、属性はFin AI Agent > Train > Attributesの下に表示されます。

注意：一度変換すると属性は元に戻せませんが、必要に応じて無効にすることは可能です。

ステップ3：有効化前のプレビュー

属性を有効にする前に、Fin AI Agent > Train > Attributesの組み込みプレビューを使って以下を行います：

属性値を例の顧客メッセージに対してテストする
Finが正しい値をどれだけ正確に適用するかを確認する
有効化前に名前と説明を繰り返し調整する

[オプション] ステップ4：条件ルールを追加

Conditionsを使って、Finが特定の属性を検出すべき正確なタイミングを制御するルールを作成します。これにより、より正確な分類が可能となり、ルーティングとレポートがよりクリーンになります。

Conditionsは属性同士をリンクさせ、依存関係を作ることで機能します。Finはまずcontrolling属性とその値を特定した後にのみ、dependent属性の検出を試みます。

注意：Finがdependent属性を検出する前に、controlling属性自体が有効なFin属性でなければなりません。controlling属性が無効またはworkflowsやAI Category Detectionで分類中の場合、Finはその値を評価できません。その結果、dependent属性は有効でも検出されません。条件ロジックが期待通りに機能するよう、controlling属性は常に有効にしてください。

仕組み

Conditionsのロジックは単純なIf/Then文です：

If Finがcontrolling属性の特定の値を検出した場合、then dependent属性の検出を試みます。

これらのルールは属性設定のサイドドロワー内のConditionsタブで設定できます。各ルールで以下を定義します：

controlling属性の値を定義する。
そのcontrolling値が検出されたときにトリガーされる条件を選択する。
許可される条件値を指定する。

例：

Issue type = Refund request → その後Refund request reasonを検出。
Sentiment = Negative sentiment → その後Urgencyを検出。

このロジックが適用されると、Finはまずcontrolling属性を検出します。定義された値が一致すれば、Finはリンクされた条件の検出を試みます。

注意：Conditionsロジックはルールベースのエスカレーションガイダンスで尊重されます。条件がルールベースのエスカレーションガイダンスで参照されている場合、Finは各顧客メッセージ後に会話を再評価し、controlling値と条件値が一致するか確認します。

Fin属性の監視とレビュー

Fin属性が有効になると、Finは属性の適用状況を理解するためのリアルタイム統計を提供します。

以下が表示されます：

Conversations → Finが検出した各属性および特定の属性値の会話数。
Resolved → Finが完全に解決できた会話の割合。
Routed → その属性を使って正常にルーティングされた会話の割合。

個別の会話にドリルダウンして、Finが属性をどのように適用したかをレビューし、正確性を検証できます。これにより、分類の精度を監視し、誤分類された会話を見直し、パターンに基づいて属性説明を更新できます。

使用例

以下は、顧客がFin属性を使って会話を分類する方法の例です。

Issue Type属性の例：

Projects - Projectsは、チームメンバーの協力、時間追跡、マイルストーンや目標、ステータスを含む、特定の目的や成果物を達成するための関連タスクと活動の集合です。
Billing - Billingは、サブスクリプションプラン、請求書、支払い方法、割引、プラン機能、トライアル、アカウント制限、返金などを管理し、シームレスな請求体験を提供します。
Account Management - Account Managementは、アカウント作成、削除、個人情報や支払い情報の更新など、ユーザーアカウントに関する議論を含みます。

Sentiment属性の例：

Positive - Positive sentimentは、メッセージを書いたユーザーが一般的に満足しているか幸せで、ポジティブな感情を感じていることを意味します。
Negative - Negative sentimentは、メッセージを書いたユーザーが一般的に不満や不快を感じており、ネガティブな感情を抱いていることを意味します。
Neutral - Neutral sentimentは、メッセージを書いたユーザーが幸せでも不幸せでもなく、その感情を推測するのが難しいことを意味します。

Spam Detection属性の例：

Spam - 顧客サポート担当者に送信される自動スパム。これには自動応答、ニュースレター、ゲスト投稿、その他CSアナリストが無視できる一般的なスパムメッセージが含まれます。
Legit - Legitな会話は、ユーザーに実際の問題があり、カスタマーサポートアナリストが対応すべきものです。

よくある質問

FinはFin属性を検出するために何を使っていますか？

Finは属性名、その説明、値の名前と説明を使って、どの属性値を適用するか評価します。これらすべてのフィールドがFinにとって解釈しやすい人間が読める形で書かれていることを確認してください。

会話に適用された属性が正確でない場合は？

名前と説明を確認することをお勧めします。ベストプラクティスを使い、プレビューツールで実際の顧客メッセージを使ってテストしてください。

プロのヒント：属性値ラベルと説明を見直す際には、Chat GPTやClaudeのようなAIライティングツールを使ってみると良いでしょう。

例のプロンプト：

You are an expert in customer-support AI. You are evaluating a taxonomy used by a LLM to classify customer support conversations. For each attribute (e.g., Topic, Sentiment), the LLM chooses the most appropriate attribute based on a combination of the attribute name and its description. This taxonomy will directly impact the LLM's ability to classify real customer support conversations. Your task is to assess the quality of this setup using the following best practices: Create clear, concise names - Choose short, descriptive names that immediately convey the attributes purpose. Write comprehensive descriptions - Take the time to write detailed descriptions and include all relevant information about what belongs in the attribute. Think about every type of conversation that should fall under this attribute and describe them in the description. Providing a detailed description will help Fin classify conversations correctly. You can include keywords and examples of customer questions. Make attributes distinct - Avoid creating attributes that overlap too much. Your attributes should be clearly different from each other, making it easy to determine which one best fits a given situation. This should be checked within each attribute only. It's fine for different attributes to apply to the same conversation. It shouldn't affect the score. Overlap with values in other attributes is allowed and does not affect this score. Ignore Archived Attributes - If a attribute is marked as archived, do not evaluate or score it. Add 5 Columns to the CSV Clarity/Conciseness (1–5), Description Comprehensiveness (1–5), Attribute Distinction (1–5), Final Score, Comment Assess each parameter for each attribute, and write a comment of why you applied this rating. Then calculate the overall score for this setup. After you've done this add one more column: Overlapping Attributes. If you think any given attribute overlaps with other attributes - list these attributes there.

Finが値を検出しない場合は？

Finは属性が適用されない場合、null値を返し、属性は空のままになります。必要に応じて、未分類の会話をキャッチするために「Other」オプションを含めることができます。

注意：属性が条件付きチェーンの一部である場合は、制御属性がFin Attributeとして有効になっていることを確認してください。Finは制御属性が有効でない限り、依存属性を評価できません。

「Other」値はいつ含めるべきですか？

すべての属性に「Other」値が必要なわけではありませんが、多くのユースケースでは重要な安全策です。

属性が幅広いまたは変化するトピック（例：Issue TypeやProduct Area）をカバーする場合は、Other値を含めてください。これにより、Finはフォールバックを持ち、すべての会話が空白のままにならずに分類されます。

集合的に網羅的な属性（例：SentimentやUrgencyテンプレート）には通常「Other」値は不要で、Finは常に定義済みのオプションのいずれかを割り当てられます。

なぜ私の条件付きFin Attributesが検出されないのですか？

条件付き検出は、制御属性と依存属性の両方が有効なFin Attributesである場合にのみ機能します。

依存属性がFin Attributeとして有効でも、制御属性が有効でない場合（例：制御属性がまだworkflowsや旧AI Category Detectionで管理されている場合）、条件が正しく設定されていてもFinは依存属性を検出しません。

条件付きロジックが機能するためには：

制御属性はFin Attributeに変換されている必要があります。
有効になっている必要があります。
Finが会話に存在し、制御属性の値を検出できる必要があります。
その時に初めてFinは依存属性の値を評価し適用します。

例のシナリオ：
「Topic」のような属性が複数の依存Fin Attributesを制御しているが、「Topic」がFin Attributeとして有効でない場合、Finはその値を評価できません。そのため、すべての依存属性が検出に失敗します。たとえ個別に有効であっても。

AI Category Detectionを使っていますが、Fin Attributesに切り替えるべきですか？

Fin AttributesはAI Category Detectionの次世代です。Fin Attributesは自動で動作し、workflowsのメンテナンスが少なく、Escalation Rulesとシームレスに連携し、Finがチームに渡す会話を完全にコントロールできます。

現在の設定は変わりませんが、より良い製品と体験のためにFin Attributesについて学び、切り替えることをお勧めします。

既存のAI Category Detection属性をFin Attributeに変換するとどうなりますか？

既存のAI Category Detectionの会話属性をFin Attributeに変換すると、Finは同じ基盤となる会話属性を使用します。つまり：

変換された属性は、既存のworkflowsやレポートで中断なく動作し続けます。
有効にすると、Finは重要な瞬間に属性値を分類し始めるため、最初はこれらの属性が2回更新されることがあります（AI Category DetectionとFinの両方で）。
簡単にするために、Finの属性適用に満足したらAI Category Detectionのworkflowブロックを最終的に削除できます。
変換は一方向の操作であり、属性をAI Category Detectionに戻すことはできませんが、必要に応じて無効化は可能です。

Fin Attributesは何に使えませんか？

Fin AttributesはCustom Answersと併用できません。Custom Answersは2025年3月19日以降にIntercomに加入したお客様には利用できません。

Fin Attributesを使うには、すべての会話にFinを関与させる必要がありますか？

はい。Fin AttributesはFinが会話に存在する場合に適用されます。つまり、会話を分類するにはworkflowsにFinを含める必要があります。

特定の場合にFinに回答させたくない場合は、Escalation Rulesを使うことができます。これにより、Finは会話やユーザー属性に基づいて分類後すぐに退出できます。

例えば、次のようにできます：

Channel = Emailのすべての会話をエスカレーションする
Attribute = Billingのすべての会話をエスカレーションする

このようにして、すべての会話で一貫した分類の利点を得ながら、Finが応答するかどうかを完全にコントロールできます。

アップロードオプションを使う場合の制限はありますか？

はい、属性ごとに250値の制限があり、CSVファイルでリスト属性をアップロードする際の最大値です。

会話に適用されたFin Attributeが正確でない場合は？

命名と説明がFin Attributesのベストプラクティスに従っているか確認してください。

既存のIntercomプランでFin Attributesを使えますか？

はい、Fin Attributesは現在すべてのプランで追加費用なしで利用可能です。価格変更がある場合は事前に必ず通知されます。

Fin属性の作成方法