> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/ja/bijinesusbisu/zoom-workforce-management/expert-insights/workforce-management-activity-to-status-mapping.md).

# アクティビティからステータスへのマッピング

Rick Arps による執筆

<figure><img src="https://media.zoom.com/images/assets/Workforce+Management+Activity+to+Status+Mapping/Zz0wODcyODJiZTVhNzExMWVmYjZkMzQ2NzYwYWQ0YTk4Yg==?t=20250501092734" alt="A woman working from home, in an office chair with a laptop on her lap and wearing a headset."><figcaption></figcaption></figure>

アドヒアランスは強力なメトリックであり、ワークフォース管理 (WFM) ソリューション内で最も一般的に追跡される項目の1つです。アドヒアランスでは、エージェントがスケジュールされている活動と、実際に行っている活動の差分を計算します。WFMでよく見られる懸念の1つは、アドヒアランスが、エージェントがZoom コンタクトセンター (ZCC) で行っている内容と正しく一致していないことです。ここでは、使用される構造と、WFMがZCCで確認した内容を、スケジュール作成で使用されるさまざまなアクティビティにどのように一致させるかを見ていきます。

## アクティビティ

WFMでは、アクティビティとは、エージェントが実行するようにスケジュールできるあらゆるアクションのことです。アクティビティは、エージェントのシフトを構成するために使用されます。各アクティビティは、エージェントのアドヒアランス計算に含めるかどうかを有効または無効にできます。

一般的なアクティビティには、次のようなものがあります。

* 電話
* 休憩
* 食事
* ミーティング
* PTO\\\\

一般的に、生産的なアクティビティ（電話、チャットなど）はアドヒアランス計算に使用されますが、非生産的なアクティビティ（休憩、食事など）は使用されません。アドヒアランスは、エージェントがスケジュールどおりにお客様に対応していることを確認するために使われます。エージェントの休憩が5分遅れた場合、アドヒアランス違反として記録されるのは5分間だけです。休憩アクティビティもアドヒアランス計算に使用すると、休憩のうち5分間は通話中で、さらに通話時間のうち5分間は休憩中になるため、アドヒアランス違反として記録される時間は10分になります。

{% hint style="info" %}
**注**

アクティビティの設定は、Zoom WFM Webポータルの以下にあります **スケジュール設定 → アクティビティ**.
{% endhint %}

## ZCCステータス

ZCCでは、エージェントのステータスを使用して、エージェントのアクティビティと、追加のエンゲージメントをエージェントに割り当てられるタイミングを追跡します。組み込みのステータスは次のとおりです:\\\\

* Ready - エージェントはエンゲージメントを受けられるオンライン状態です
* Occupied - エージェントはアクティブなエンゲージメント中、またはエンゲージメントの後処理中です
* Not Ready - エージェントは通話の受付をオプトアウトしたか、オプトアウトされています\\\\

Not Ready には、エージェントがキューから外れた理由を示すサブステータスを設定できます。これらはよく理由と呼ばれます。理由のサンプルは次のとおりです:\\\\

* 休憩
* シフト終了
* 強制
* 食事
* ミーティング

## ステータスをアクティビティにマッピングする

WFMはZCCからエージェントのステータス情報を受け取り、このステータスをアクティビティ、ひいてはアドヒアランスにマッピングできる必要があります。これを行うために、エージェントステータスマッピングを使用します。

{% hint style="info" %}
**注**

エージェントステータスマッピングは、Zoom WFM Webポータルの以下にあります **設定 → エージェントステータス** **マッピング**.
{% endhint %}

ここでは、WFM内で設定されているすべてのアクティビティの一覧が表示されます。これらの対応を設定するには、エージェントがWFMのアクティビティを実行しているときに、ZCCでどのステータスになるかを考えます。

たとえば、エージェントに『電話』アクティビティのスケジュールがある場合、ステータスは『Ready』または『Occupied』であると想定されます。つまり、通話を受けられる状態であるか、実際に通話中であるかのいずれかです。

<figure><img src="https://media.zoom.com/images/assets/status-mapping3.png/Zz1kMjFkZGIxNjU4YTIxMWVmOTc4YTM2ZTI5YjBmM2E2Mw==" alt="Setting Agent Status Mapping via the menu."><figcaption></figcaption></figure>

別の例として、『Break』アクティビティでは、ZCCの理由コードをどのように使用できるかがわかります。エージェントが休憩中の場合、ZCCでは『Not Ready』ステータスになり、理由として『Break』を選択します。WFMでは、まずNot Readyステータスを追加し、次に『サブステータスを追加』を選択して理由を含めます。

<figure><img src="https://media.zoom.com/images/assets/status-mapping.png/Zz1kMjFkZGIxNjU4YTIxMWVmOTY5ZmMyMGIwNmQzNDQxNw==" alt="Another example of setting Agent Status Mapping via the menu." height="330" width="672"><figcaption></figcaption></figure>

これらのステータスをアクティビティにマッピングすると、実際のエージェントのアクティビティに基づいて、アドヒアランスを正しく計算できるようになります。

### 理由とサブステータスの特別な使用例

場合によっては、管理者がZCCの外にあるエージェントのアクティビティを追跡したいことがあります。たとえば、エージェントが日々の業務の一環としてケース作業を行う必要がある場合です。このために、WFMで『Case Work』アクティビティを作成し、ZCCの同名のカスタム理由コードにマッピングできます。すると、エージェントがケース作業を行う際に、ZCCでこの理由を選択し、WFMはエージェントのアドヒアランスを計算する際にこのアクティビティを正しく追跡できます。

<figure><img src="https://media.zoom.com/images/assets/status-mapping.png/Zz1kMjIzNjAxODU4YTIxMWVmOTY4NDdlMmVhODJlZDNlNA==" alt="Another example of setting Agent Status Mapping via the menu." height="350" width="711"><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://library.zoom.com/technical-library/ja/bijinesusbisu/zoom-workforce-management/expert-insights/workforce-management-activity-to-status-mapping.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
