Fin属性は、Finが会話の内容をリアルタイムで理解し分類できるようにします。これにより、問題タイプ、感情、緊急度などの構造化された属性値を適用し、より賢いトリアージ、ルーティング、レポート作成を可能にします。
主な利点
ビジネスを反映したカスタム属性：Finに問題タイプ、緊急度、感情、スパム状態などの属性を検出させてトレーニングします。
リアルタイムで適応的な検出：Finは会話の文脈を継続的に評価し、進行に応じて値を更新します。
スマートなルーティングとエスカレーション：Fin属性をworkflowsやエスカレーションルールと組み合わせて、適切なタイミングで適切なチームに会話をルーティングします。
レポート対応の構造：検出されたすべての属性データはFinレポートに流れ込み、深い洞察を提供します。手動タグ付けは不要です。
完全な透明性とコントロール：いつでもFinの属性ロジックを表示、検証、上書きできます。
注意：すでにAI Category Detectionを使用している場合、Fin属性との比較方法と移行方法を学んでください。
Finが属性を適用する方法
デフォルトでは、Finが会話に関与している場合、重要なタイミングで有効な属性を分類します。
チームメイトに引き継ぐとき。
顧客が解決（ポジティブなフィードバック）を示したとき。
顧客が非アクティブになったとき。
エスカレーションルールを設定すると、Finは各メッセージ後に会話を再評価し、より動的でリアルタイムな分類を可能にします。
注意：Finは会話開始直後に属性分類を複数回連続で実行することがあります。各回はその時点で利用可能な全コンテキストを使用し、後の結果が前の値を上書きします（後勝ち）。つまり、新しい会話の最初の数秒間は属性値が安定していない可能性があります。会話開始直後に評価されるworkflowのFin属性を使用する場合は、一時的な値も含めてあらゆる値に対応できるよう設計するか、値が安定するまで会話の後半で分岐をトリガーしてください。
Fin属性の設定方法
ステップ1：分類する内容を決める
Finに検出させたい構造化情報の種類を考えましょう。一般的な例は以下の通りです：
問題タイプ（例：Billing、Projects、Account Management）
感情（ポジティブ、ニュートラル、ネガティブ）
緊急度（Urgent、高、Normal、Low）
スパム検出（Spam、Legitimate）
ステップ2：新しい属性を作成する（または既存の属性を変換する）
新しいFin属性を作成するには：
Train > Attributesに移動します。
新規作成をクリックします。
属性の名前と説明を入力します。
各値（明確な説明付き）を追加します。
ヒント：Finがサポート会話を高精度で分類できるように、効果的な属性名と説明の作成方法を学びましょう。
既存の属性を変換するには：
Settings > Conversation dataに移動し、リストタイプ属性の編集をクリックしてからLet Fin detect.をクリックします。
変換後、属性はTrain > Attributesに表示されます。
注意：
Fin属性に変換すると元に戻せませんが、必要に応じて無効にすることは可能です。
Zendesk supportから同期されたリストタイプ属性は最大1,000オプションですが、Fin属性は250オプションに制限されています。属性がこの制限を超える場合、Fin属性として保存できません。変換するには、エントリを統合するかオプション数を減らすことを検討してください。
ステップ3：有効化前にプレビューする
属性を有効にする前に、Train > Attributesの組み込みプレビューを使って：
顧客メッセージの例に対して属性値をテストする
Finが正確に適切な値を適用するか確認する
有効化前に名前と説明を繰り返し調整する
[オプション] ステップ4：条件ルールを追加する
条件を使って、Finが特定の属性を検出する正確なタイミングを制御するルールを作成します。これにより、より正確な分類が可能になり、ルーティングやレポートがよりクリーンになります。
条件は属性同士をリンクさせ、親/従属関係を作ることで機能します。Finはまず親属性とその値を特定した後にのみ、従属属性の検出を試みます。
仕組み
条件のロジックは単純なIf/Then文です：
もしFinが親属性の特定の値を検出したら、次に従属属性の検出を試みます。
これらのルールは属性設定のサイドドロワーのConditionsタブで設定できます。各ルールで以下を定義します：
親属性の値を定義します。
親の値が検出されたときにトリガーされる条件を選択してください。
許可される条件値を指定してください。
例：
Issue type = Refund request の場合 → Refund request reason を検出します。
Sentiment = Negative sentiment の場合 → Urgency を検出します。
このロジックが適用されると、Fin は最初に親属性を検出します。定義された値が一致すると、Fin はリンクされた条件の検出を試みます。
注意：
条件ロジックはEscalation Rulesで尊重されます。条件がEscalation Ruleで参照されている場合、Finは各顧客メッセージ後に会話を再評価し、親と条件の値が一致するか確認します。
依存（条件付き）Fin属性の検出はベストエフォートであり、保証されません。Finは親属性を特定した後に別の非決定的な分類試行を行い、親の値が正しく設定されていてもnullを返すことがあります。
ヒント：親の値に基づいて属性を決定的に設定する必要がある場合は、Workflow branchingを使用してください。親属性値は確実に設定されるため、分岐は保証されます。
Fin属性の監視とレビュー
属性が有効になると、Finは属性の適用状況を理解するためのリアルタイム統計を提供します。
以下が表示されます:
Conversations → Finが各属性および特定の属性値で検出した会話数。
Resolved → Finが完全に解決できた会話の割合。
Routed → その属性を使って正常にルーティングされた会話の割合。
個別の会話にドリルダウンして、Finが属性をどのように適用したかを確認し、精度を検証できます。これにより、適用された属性の精度を監視し、誤った属性の会話をレビューし、パターンに基づいて属性説明を更新できます。
注意：属性パネルに表示される理由テキストは、表示するたびにオンデマンドで生成されます。固定記録として保存されていないため、閉じた会話でも表現が多少異なる場合があります。監査目的では、Finの決定の信頼できる記録は、属性が適用された時点で会話タイムラインに追加されたFinノートです。そのノートは固定スナップショットで変更されません。
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 - 顧客サポート担当者に送信される自動スパム。これには自動応答、ニュースレター、ゲスト投稿、その他無視可能な一般的なスパムメッセージが含まれます。
Legit - Legitimate conversationsは、ユーザーに実際の問題があり、カスタマーサポート担当者が対応すべき会話です。
FAQs
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が値を検出しない場合は？
Finは属性が適用されない場合、null値を返し、属性は空のままになります。未分類の会話をキャッチするために「Other」オプションを含めることもできます。
AI Category Detectionを使用していますが、Fin Attributesに切り替えるべきですか？
AI Category Detectionを使用していますが、Fin Attributesに切り替えるべきですか？
Fin AttributesはAI Category Detectionの次世代です。自動で動作し、ワークフローのメンテナンスが少なく、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による1回、Finによる1回）。
簡単にするために、Finの属性適用に満足したら、最終的にAI Category Detectionのworkflowブロックを削除できます。
変換は一方向の操作であり、属性をAI Category Detectionに戻すことはできませんが、必要に応じて無効にすることは可能です。
Fin Attributesを使用するには、すべての会話にFinを関与させる必要がありますか？
Fin Attributesを使用するには、すべての会話にFinを関与させる必要がありますか？
はい。Fin Attributesは、会話にFinが存在する場合にFinによって適用されます。つまり、会話を分類するには、workflowsにFinを含める必要があります。
特定の場合にFinに回答させたくない場合は、Escalation Rulesを使用できます。これにより、Finは会話やユーザー属性に基づいて会話を分類し、すぐに退出します。
例えば、次のようにできます：
Channel = Emailのすべての会話をエスカレーションする
Attribute = Billingのすべての会話をエスカレーションする
この方法で、すべての会話にわたって一貫した分類の利点を得ながら、Finが応答するかどうかを完全に制御できます。