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、High、Normal、Low）
スパム検出（Spam、Legitimate）
ケースタイプ（Salesforceの標準ケースフィールドで、Fin属性として同期可能）
ステップ2：新しい属性を作成（または既存の属性を変換）
新しいFin属性を作成するには：
Train > Attributesに移動します。
Newをクリックします。
属性の名前と説明を入力します。
各値に明確な説明を付けてValuesを追加します。
ヒント：効果的な属性名と説明の作成方法を学び、Finがサポート会話を高精度で分類できるようにしましょう。
既存の属性を変換するには：
Settings > Conversation dataに移動し、リストタイプ属性の編集をクリックしてからLet Fin detect.をクリックします。
変換後、属性はTrain > Attributesに表示されます。
注意：
Fin属性に変換すると元に戻せませんが、必要に応じて一時停止は可能です。
Zendesk supportから同期されるリストタイプ属性は最大1,000オプションですが、Fin属性は250オプションに制限されています。属性がこの制限を超える場合、Fin属性として保存できません。変換するには、エントリを統合するかオプション数を減らしてください。
ステップ3：有効化前にプレビュー
属性を有効にする前に、Train > Attributesの組み込みプレビューを使って：
例の顧客メッセージに対して属性値をテストし、
Finが正確に適切な値を適用するか確認し、
有効化前に名前と説明を繰り返し調整します。
[オプション] ステップ4：条件ルールの追加
Conditionsを使って、Finが特定の属性を検出する正確なタイミングを制御するルールを作成します。これにより、より正確な分類が可能になり、ルーティングやレポートがよりクリーンになります。
Conditionsは属性同士をリンクし、親/従属関係を作ります。Finはまず親属性とその値を特定した後にのみ従属属性の検出を試みます。
仕組み
Conditionsのロジックは単純なIf/Then文です。
IfFinが親属性の特定の値を検出した場合、then従属属性の検出を試みます。
これらのルールは属性設定のサイドドロワー内のConditionsタブで設定できます。各ルールで以下を定義します。
親属性値を定義してください。
その親値が検出されたときにトリガーされる条件を選択してください。
許可される条件値を指定してください。
例：
問題タイプ = Refund request の場合 → Refund request reason を検出します。
感情 = Negative sentiment の場合 → 緊急度を検出します。
このロジックが適用されると、Finはまず親属性を検出します。定義された値が一致すると、Finはリンクされた条件の検出を試みます。
注意：
条件ロジックはEscalation Rulesで尊重されます。条件がEscalation Ruleで参照されている場合、Finは各顧客メッセージ後に会話を再評価し、親値と条件値が一致するか確認します。
依存（条件付き）Fin属性の検出はベストエフォートであり保証されません。Finは親属性を特定した後に別の非決定的な分類試行を行い、親値が正しく設定されていてもnullを返すことがあります。
ヒント：親値に基づいて属性を決定的に設定する必要がある場合は、Workflow branchingを使用してください。親属性値は確実に設定されるため、それに基づく分岐は保証されます。
Fin属性を一時停止するとどうなりますか？
Fin属性を一時停止すると、Finは会話内でその属性の検出を停止します。再度検出が必要な場合は、Fin属性を再有効化して検出を再開できます。
Fin属性の監視とレビュー
属性が有効になると、Finは属性の適用状況を理解するためのリアルタイム統計を提供します。
以下が表示されます：
会話 → Finが各属性および特定の属性値で検出した会話数。
解決済み → Finが完全に解決できた会話の割合。
ルーティング済み → その属性を使って正常にルーティングされた会話の割合。
個別の会話を詳細に確認して、Finが属性をどのように適用したかをレビューし、正確性を検証できます。これにより、適用された属性の正確性を監視し、誤った属性の会話を見直し、パターンに基づいて属性説明を更新できます。
注意：属性パネルに表示される理由テキストは、表示するたびにオンデマンドで生成されます。固定記録として保存されていないため、閉じた会話でも表示ごとに文言が若干異なる場合があります。監査目的では、Finの決定の信頼できる記録は属性適用時に会話タイムラインに追加されたFinノートです。そのノートは固定スナップショットで変更されません。
Fin属性の例
以下は、顧客が会話でFin属性を使用している例です。
問題タイプ属性の例：
プロジェクト - プロジェクトは、チームメンバーの協力、時間追跡、マイルストーンや目標、ステータスを含む特定の目的や成果物を達成するための関連タスクと活動の集合です。
請求 - 請求は、サブスクリプションプラン、請求書、支払い方法、割引、プラン機能、トライアル、アカウント制限、返金などの管理を含み、シームレスな請求体験を提供します。
アカウント管理 - アカウント管理は、アカウント作成、削除、個人情報や支払い情報の更新など、ユーザーアカウントに関連する議論を扱います。
感情属性の例：
ポジティブ - ポジティブな感情は、メッセージを書いたユーザーが一般的に満足しているか幸せで、ポジティブな感情を感じていることを意味します。
ネガティブ - ネガティブな感情は、メッセージを書いたユーザーが一般的に不満や不快感を感じており、ネガティブな感情を抱いていることを意味します。
ニュートラル - ニュートラルな感情は、メッセージを書いたユーザーが幸せでも不幸せでもなく、その感情を推測するのが難しいことを意味します。
スパム検出属性の例：
スパム - 顧客サポート担当者に送信される自動スパム。これには自動応答、ニュースレター、ゲスト投稿、その他一般的なスパムメッセージが含まれ、CSアナリストは無視することがあります。
正当 - ユーザーに実際の問題があり、カスタマーサポートアナリストが対応すべき正当な会話。
よくある質問
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カテゴリ検出を使用していますが、Fin属性に切り替えるべきですか？
AIカテゴリ検出を使用していますが、Fin属性に切り替えるべきですか？
Fin属性はAIカテゴリ検出の次世代です。自動で動作し、workflowのメンテナンスが少なく、Escalation Rulesとシームレスに連携し、Finがチームに渡す会話を完全に制御できます。
現在の設定は変わりませんが、より良い製品と体験のためにFin属性について学び、切り替えることをお勧めします。
既存のAIカテゴリ検出属性をFin属性に変換するとどうなりますか？
既存のAIカテゴリ検出属性をFin属性に変換するとどうなりますか？
既存のAIカテゴリ検出会話属性をFin属性に変換すると、Finは同じ基盤となる会話属性を使用します。つまり：
変換された属性は、既存のworkflowやレポートで中断なく動作し続けます。
有効にすると、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をworkflowに含める必要があります。
特定の場合にFinに回答させたくない場合は、Escalation Rulesを使用できます。これにより、Finは会話やユーザー属性に基づいて会話を分類し、すぐに退出します。
例えば、次のようにできます：
Channel = Emailのすべての会話をエスカレーションする
Attribute = Billingのすべての会話をエスカレーションする
このようにして、すべての会話で一貫した分類の利点を得ながら、Finが応答するかどうかを完全に制御できます。