Fin Attributesはすべての会話を自動的に分類します。属性を使うことで、問題の種類、感情、緊急度などを定義できます。会話は即座にタグ付けされ、適切なチームにルーティングし、適切なアクションをトリガーし、手動の手間なく正確なレポートを得られます。
クイックスタート：3ステップでFin Attributesを設定する方法
検出する内容を決める
Finに分類させたい構造化属性を選択します。例：問題の種類、感情、緊急度、またはスパム。
属性を作成または変換する
Fin → Train → Attributesにアクセスします。明確な説明で属性値を定義するか、既存のリスト形式の属性を変換してください。
プレビューと有効化
プレビューツールを使ってFinの精度をテストします。値の説明を調整し、その後実際の会話で属性を有効にします。
有効化後は、検出された属性値をEscalation Rules、Workflows、およびReportingで使用できます。
主な利点
ビジネスに合わせたカスタム属性：Finをトレーニングして、問題の種類、緊急度、感情、スパム状態などの属性を検出します。
インテリジェントで適応的な検出：Finは重要な瞬間に文脈を評価し、会話の進行に応じて値を更新します。
スマートなルーティングとエスカレーション：Fin AttributesをworkflowsやEscalation Rulesと組み合わせて、適切なタイミングで適切なチームに会話をルーティングします。
レポート対応の構造：検出されたすべての属性データはIntercomのレポートに流れ込み、深い洞察を得られます。手動のタグ付けは不要です。
完全な透明性とコントロール：いつでもFinの属性ロジックを表示、検証、上書きできます。
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モデルは最新のメッセージだけでなく会話全体の文脈に基づいて分類します。
注意：Finは会話開始時に属性分類を複数回連続して実行することがあります。各回はその時点で利用可能な全文脈を使用し、後の分類結果が前の結果を上書きします（後勝ち）。つまり、新しい会話の最初の数秒間は属性値が安定していない可能性があります。会話開始直後に評価されるworkflowの分岐でFin Attributeを使う場合は、一時的な値も含めてあらゆる値に対応できるよう設計するか、値が安定するまで分岐を遅らせてください。
3. オプション：クローズ時に検出
属性の「クローズ時に検出」を有効にすると、会話がチームメイトまたは自動化でクローズされたときにFinが値を再チェック・更新します。これは属性作成または編集時に有効化できます。
💡 なぜ重要か：スレッドの後半で新しい情報や文脈が出てきた場合、Finが最終的に分類を修正・調整する最後のチャンスを得ます。これにより、会話の後半で状況が変わってもレポートの正確性が保たれます。
メールチャネル：Finはメール会話をクローズするときに「クローズ時に検出」属性（スパムなど）を正しく適用し、Messengerでの既存の動作と一致させます。
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 Attributeでなければなりません。controlling属性が無効またはworkflowsで分類中の場合、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属性を検出し、定義された値が一致すればリンクされた条件の検出を試みます。
注意: Conditionsロジックはルールベースのエスカレーションガイダンスで尊重されます。 条件がルールベースのエスカレーションガイダンスで参照されている場合、Finは各顧客メッセージ後に会話を再評価し、controlling値と条件値が一致するか確認します。
Fin Attributesの監視とレビュー
Fin Attributesが有効になると、Finは属性の適用状況をリアルタイムで把握できる統計情報を提供します。
以下が表示されます:
Conversations → Finが各属性および特定の属性値で検出した会話数。
Resolved → Finが完全に解決できた会話の割合。
Routed → その属性を使って正常にルーティングされた会話の割合。
個別の会話にドリルダウンして、Finが属性をどのように適用したかを確認し、精度を検証できます。これにより、分類精度の監視、誤分類された会話のレビュー、パターンに基づく属性説明の更新が可能になります。
注意: 属性パネルに表示される理由テキストは、表示するたびにオンデマンドで生成されます。固定記録として保存されていないため、活動のない終了済み会話でも表示ごとに文言が多少異なる場合があります。監査目的では、Finの判断の信頼できる記録は属性適用時に会話タイムラインに追加されたFinノートです。そのノートは固定スナップショットで変更されません。
使用例
以下は、顧客がFin Attributesを使って会話を分類している例です。
Issue Type属性の例:
Projects - Projectsは、チームメンバーの協力、時間追跡、マイルストーンや目標、ステータスを含む特定の目的や成果物を達成するための関連タスクと活動の集合です。
Billing - Billingは、サブスクリプションプラン、請求書、支払い方法、割引、プラン機能、トライアル、アカウント制限、返金などの管理を含み、シームレスな請求体験を提供します。
Account Management - Account Managementは、アカウント作成、削除、個人情報や支払い情報の更新など、ユーザーアカウントに関する議論を扱います。
Sentiment属性の例:
Positive - ポジティブな感情とは、メッセージを書いたユーザーが一般的に満足しているか幸せで、ポジティブな感情を感じていることを意味します。
Negative - ネガティブな感情とは、メッセージを書いたユーザーが一般的に不満や不快感を感じており、ネガティブな感情を抱いていることを意味します。
Neutral - ニュートラルな感情とは、メッセージを書いたユーザーが幸せでも不幸せでもなく、その感情を推測するのが難しいことを意味します。
Spam Detection属性の例:
Spam - 顧客サポート担当者に送信される自動スパム。これには自動応答、ニュースレター、ゲスト投稿、その他CSアナリストが無視できる一般的なスパムメッセージが含まれます。
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で管理されている場合）、Finは条件が正しく設定されていても依存属性を検出しません。
条件付きロジックが機能するためには:
制御属性はFin Attributeに変換されている必要があります。
有効になっている必要があります。
Finが会話に存在し、制御属性の値を検出できる必要があります。
その時にのみ、Finは依存属性の値を評価して適用します。
例のシナリオ：
「Topic」のような属性が複数の依存するFin Attributesを制御しているが、「Topic」がFin Attributeとして有効でない場合、Finはその値を評価できません。そのため、すべての依存属性が検出に失敗します。たとえ個別に有効であっても。
Fin Attributesは何に使えませんか？
Fin Attributesは何に使えませんか？
Fin Attributesはカスタム回答と併用できません。カスタム回答は2025年3月19日以降にIntercomに参加したお客様には利用できません。
Fin Attributesを使うには、すべての会話にFinを関与させる必要がありますか？
Fin Attributesを使うには、すべての会話にFinを関与させる必要がありますか？
はい。Fin AttributesはFinが会話に存在する場合に適用されます。つまり、会話を分類するにはworkflowsにFinを含める必要があります。
特定の場合にFinに回答させたくない場合は、エスカレーションルールを使用できます。これにより、Finは会話を分類した後、選択した会話またはユーザー属性に基づいてすぐに退出します。
例えば、次のようにできます:
Channel = Emailのすべての会話をエスカレーションする
Attribute = Billingのすべての会話をエスカレーションする
こうすることで、すべての会話で一貫した分類の利点を得ながら、Finが回答するかどうかを完全にコントロールできます。
アップロードオプションの使用に制限はありますか？
アップロードオプションの使用に制限はありますか？
はい、属性ごとに250の値の制限があります。これはCSVファイルでリスト属性をアップロードする際の最大数です。
既存のIntercomプランでFin Attributesを使えますか？
既存のIntercomプランでFin Attributesを使えますか？
はい、Fin Attributesは現在すべてのプランで追加費用なしで利用可能です。価格変更がある場合は事前に必ず通知されます。