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はルールに従って即座に会話を引き継ぎ、チームメイトが適切なタイミングで介入できるようにします。
3. オプション：クローズ時の検出
属性の「Detect on close」を有効にすると、会話がチームメイトまたは自動化によってクローズされたときに、Finが値を再チェックして更新します。これは属性の作成または編集時に有効化できます。
💡 なぜ重要か：スレッドの後半で新しい情報や文脈が出てきた場合、Finは分類を最終的に修正または調整する最後のチャンスを得ます。これにより、会話の後半で状況が変わってもレポートの正確性が保たれます。
Fin Attributesの設定方法
ステップ1：分類する内容を決める
Finに検出させたい構造化情報の種類を考えます。一般的な例は以下の通りです。
問題の種類（例：Billing、Projects、Account Management）
感情（ポジティブ、ニュートラル、ネガティブ）
緊急度（Urgent、High、Normal、Low）
スパム検出（Spam、Legitimate）
ステップ2：新しい属性を作成（または既存の属性を変換）
新しいFin Attributeを作成するには：
Fin > Train > Attributes にアクセスして開始します。
New.をクリックします。
属性のNameとDescriptionを入力します。
Attribute Valuesを追加します（それぞれに明確な説明を付けて）。
ヒント：効果的な属性名と説明の作成方法を学び、Finがサポート会話を高精度で分類できるようにしましょう。
To convert an existing attribute:
設定 > データ > 会話に移動し、リスト形式の属性の編集をクリックしてから、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 Attributeでなければなりません。controlling属性が無効またはworkflowsやAI Category Detectionでまだ分類中の場合、Finはその値を評価できません。その結果、dependent属性は有効でも検出されません。条件ロジックが期待通りに機能するよう、常にcontrolling属性が有効であることを確認してください。
仕組み
Conditionsのロジックは単純なIf/Then文です：
If Finがcontrolling属性の特定の値を検出した場合、thendependent属性の検出を試みます。
これらのルールは属性設定のサイドドロワーのConditionsタブで設定できます。各ルールで以下を定義します：
controlling属性の値を定義する。
そのcontrolling値が検出されたときにトリガーされる条件を選択する。
許可される条件値を指定する。
例：
Issue type = Refund request → それからRefund request reasonを検出する。
Sentiment = Negative sentiment → それからUrgencyを検出する。
このロジックがあると、Finはまずcontrolling属性を検出します。定義された値が一致すると、Finは連結された条件の検出を試みます。
注意：Conditionsロジックはルールベースのエスカレーションガイダンスで尊重されます。 条件がルールベースのエスカレーションガイダンスで参照されている場合、Finは各顧客メッセージ後に会話を再評価し、controllingと条件の値が一致するか確認します。
Fin Attributesの監視とレビュー
Fin Attributesが有効になると、Finは属性の適用状況を理解するためのリアルタイム統計を提供します。
以下が表示されます：
Conversations → Finが各属性および特定の属性値で検出した会話の数。
Resolved → Finが完全に解決できた会話の割合。
Routed → その属性を使って正常にルーティングされた会話の割合。
個別の会話にドリルダウンして、Finが属性をどのように適用したかをレビューし、正確性を検証できます。これにより、分類の精度を監視し、誤分類された会話をレビューし、パターンに基づいて属性説明を更新できます。
使用例
以下は、顧客がFin Attributesを使って会話を分類する方法の例です。
Issue Type属性の例：
Projects - Projectsは、チームメンバーの協力、時間追跡、マイルストーンや目標、ステータスを含む、特定の目的や成果物を達成するための関連タスクと活動の集合です。
Billing - Billingは、サブスクリプションプラン、請求書、支払い方法、割引、プラン機能、トライアル、アカウント制限、返金などの管理を含み、シームレスな請求体験を提供します。
Account Management - Account Managementは、アカウント作成、削除、個人情報や支払い情報の更新など、ユーザーアカウントに関連する議論をカバーします。
Sentiment属性の例：
Positive - Positive sentimentは、メッセージを書いたユーザーが一般的に満足しているか幸せで、ポジティブな感情を感じていることを意味します。
Negative - Negative sentimentは、メッセージを書いたユーザーが一般的に不満や不快感を感じており、ネガティブな感情を持っていることを意味します。
Neutral - Neutral sentimentは、メッセージを書いたユーザーが幸せでも不幸せでもなく、その感情を推測するのが難しいことを意味します。
Spam Detection属性の例：
Spam - Spamはカスタマーサポートエージェントに送られる自動スパムです。これには自動応答、ニュースレター、ゲスト投稿、その他CSアナリストが無視できる一般的なスパムメッセージが含まれます。
Legit - Legitな会話は、ユーザーに実際の問題があり、カスタマーサポートアナリストが対応すべきものです。
よくある質問
FinはFin Attributesを検出するために何を使っていますか？
FinはFin Attributesを検出するために何を使っていますか？
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が値を検出しなかったらどうなりますか？
Finは該当する属性がない場合、null値を返し、その属性は空のままになります。必要に応じて、未分類の会話をキャッチするために「Other」オプションを含めることができます。
注意: 属性が条件付きチェーンの一部である場合、制御属性がFin Attributeとして有効になっているかを確認してください。Finは制御属性が有効でない限り、依存属性を評価できません。
「Other」値はいつ含めるべきですか？
「Other」値はいつ含めるべきですか？
すべての属性に「Other」値が必要なわけではありませんが、多くのユースケースでは重要な安全策です。
属性が幅広いまたは変化するトピック（例：Issue TypeやProduct Area）をカバーする場合は、Other値を含めてください。これにより、Finはフォールバックを持ち、すべての会話が空白のままではなく分類されます。
集合的に網羅的な属性（例：SentimentやUrgencyテンプレート）には通常「Other」値は不要で、Finは常に定義済みのオプションのいずれかを割り当てられます。
なぜ私の条件付きFin Attributesが検出されないのですか？
なぜ私の条件付き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に切り替えるべきですか？
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に変換するとどうなりますか？
既存の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は何に使えませんか？
Fin AttributesはCustom Answersと併用できません。Custom Answersは2025年3月19日以降にIntercomに加入したお客様には利用できません。
Fin Attributesを使うには、すべての会話にFinを関与させる必要がありますか？
Fin Attributesを使うには、すべての会話にFinを関与させる必要がありますか？
はい。Fin AttributesはFinが会話に存在するときに適用されます。つまり、会話を分類するにはworkflowsにFinを含める必要があります。
特定の場合にFinに回答させたくない場合は、Escalation Rulesを使うことができます。これにより、Finは会話を分類してすぐに退出できます。会話やユーザー属性に基づいて制御可能です。
例えば、次のようにできます:
すべての会話でChannel = Emailの場合にエスカレーションする
すべての会話でAttribute = Billingの場合にエスカレーションする
こうすることで、すべての会話で一貫した分類の利点を得つつ、Finが回答するかどうかを完全にコントロールできます。
アップロードオプションの使用に制限はありますか？
アップロードオプションの使用に制限はありますか？
はい、属性ごとに250の値の制限があり、CSVファイルでリスト属性をアップロードする際の最大数です。
既存のIntercomプランでFin Attributesを使えますか？
既存のIntercomプランでFin Attributesを使えますか？
はい、Fin Attributesは現在すべてのプランで追加費用なしで利用可能です。価格変更がある場合は事前に必ず通知されます。