目的をラベルに変換する

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

タクソノミーを構成するためのラベルの代表的なグループ

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

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

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

Once you’ve defined your labels and your target taxonomy structure, it’s important to define the key data points (i.e. general fields) you want to extract from your comms data. These are typically used to facilitate downstream automation, but can also be useful for analytics. For guidance on defining and setting up your general fields correctly, please see our training guide here.