目的をラベルに変換する

目的を定義したら、その目的をラベルに変換する作業を開始できます。ラベルには、特定の目的を達成するためにデータセット内でキャプチャする概念と意図をすべて含める必要があります。

含めることができるラベルの代表的なグループは次のとおりです。

• プロセスまたはリクエストの種類
• サービス品質または失敗需要
• 根本原因と例外
• 顧客またはクライアントのエクスペリエンス
• 感情
• 製品タイプ
• システムとデータ

これらは、ユース ケースや業界に関係なく、UiPath のユーザーが使用している代表的なラベルです。このすべてをご自身のモデルに適用できるわけではありません。また、目的を達成するには、ほかにも重要なラベルの種類がある場合があります。

このセクションでは、これらのラベルの各種類について、それぞれが何をキャプチャし、何に回答するのに役立つかを含めて、詳しく説明します。

ラベルの種類	キャプチャする内容	回答に役立つ内容
プロセスまたはリクエストの種類	チームが処理する必要があるコア プロセスまたは受信リクエストをキャプチャします。多くの場合、チームが所有するタスクのサービス カタログに直接一致し、サブプロセスまたはリクエストに対応する追加の特異性レベルをキャプチャする階層として編成します。	これらはモデルの基本的なラベルであり、チャネル全体にわたって洞察、監視、アクションを提供するのに役立ちます。プロセスの改善の機会を特定したり、自動化を可能にしてプロセスを効率化したりするには、プラットフォームによってプロセスそのものを識別できる必要があります。 分析の場合は、他のすべてのラベルの種類と組み合わせて、根本原因、感情、サービス品質などに焦点を当てた洞察を生成します。メタデータを使用してデータをさらにセグメント化すると、これらのリクエストの性質とソースをさらに理解するのに役立ちます。 自動化の場合、これらはプロセスをエンドツーエンドで自動ルーティングおよび自動化するのに不可欠です。
根本原因と例外	これらのラベルは、チームや顧客の問い合わせを引き起こしている問題の根本原因や例外の種類をキャプチャすることを目的としています。たとえば、金融サービス運用チームの場合、取引の詳細の欠落などです。	これらは、プロセスの改善の機会を特定するために重要です。根本原因のラベルをプロセスまたはリクエストの種類のラベルにマッピングすると、コミュニケーション チャネルに存在する問題を明確に把握できます。
サービス品質または失敗需要	コミュニケーション チャネル内のサービスのレベル、またはプロセスやサービスの失敗から生まれた需要 (例: 催促、エスカレーション) に関連する概念をキャプチャします。	これらは次のような質問に答えるのに役立ちます。 顧客が、解決できる最悪の問題 (ペイン ポイント) を経験しているのはどこか。 どのプロセスで繰り返しミスをしているか、またはSLA を達成できていないか チャネルのどの領域が顧客の最も否定的な感情を引き起こしていますか? 逆に、強みのある領域とパフォーマンスに優れた領域を特定することもできます。重要なのは、プラットフォームの サービス品質 (QoS) 監視機能内でも使用できる点です。この機能は、チャネルのパフォーマンスを 1 つの QoS メトリックに集約して経時的に追跡し、ベンチマークに設定して他のチャネルやチームと比較できる強力な分析ツールです。
感情	感情分析が有効化 (B2B コミュニケーション チャネルでは推奨事項) されていないモデルをトレーニングする場合は、代わりに、コミュニケーションで表されている感情をキャプチャするラベルを使用できます。たとえば、「顧客の不満」や「顧客の満足」などです。	これらは、クライアント、顧客、さらには従業員のエクスペリエンスに関連する洞察を提供することを目的としています。 表されている感情を予測された他の概念にマッピングすることで、悪影響および好影響が最も大きい、プロセスとカスタマー ジャーニーの解決できる主要な問題 (ペイン ポイント) を見つけることができます。
顧客またはクライアントのエクスペリエンス	これらは、クライアントまたは顧客が得た特定のエクスペリエンスに関連しており、多くの場合、受信リクエストの種類をキャプチャするラベルと密接に関係しています。たとえば、B2C 小売企業では「商品が届かなかった」などです。	これらは、クライアントまたは顧客がなぜ企業に問い合わせを行っているかを示す究極の原因であるため、強力な洞察が得られます。 根本原因に関連するラベルと重複する場合もありますが、そちらは送信者のエクスペリエンスに焦点を当てており、上流の根本原因ではない可能性があります。
製品	チームやチャネルが、顧客、サービス提供者、または販売者として扱うさまざまな製品をキャプチャします。たとえば、「ETF」や「財産保険」などです。	分析でこれらのラベルを他のラベルの種類と組み合わせると、どの製品がどのプロセスやリクエストの種類、または根本原因や例外に関連しているかについて、より深い洞察を提供できます。
システムとデータ	どのチームも、Outlook だけでなく多数のシステムとデータ ソースを日常業務で操作します。これらのラベルは、Salesforce や SAP など、これらのシステムへの参照をキャプチャします。	前の製品と同様に、通常は他のラベルと組み合わせることで、より詳細な洞察を提供できます。システムとデータに関連するラベルをプロセスおよび例外の種類と組み合わせると、上流の優先すべき改善の機会を特定するのに役立ちます。

ラベルおよび対象となるタクソノミー構造を定義したら、コミュニケーション データから抽出する主要なデータ ポイント (フィールド) を定義する必要があります。フィールドは、下流の自動化を促進するために使用されますが、分析にも役立ちます。フィールドを正しく定義および設定する方法について詳しくは、「一般フィールドを使用する」をご覧ください。