平均調整処理時間（AAHT）は、チームメンバーが会話に実際に費やす時間をより正確に把握できます。従来の処理時間は、会話が割り当てられてから終了するまでのすべての時間をカウントし、非アクティブな期間も含みますが、調整処理時間はチームメンバーが本当に関与している瞬間のみを追跡します。

時計はチームメンバーがブラウザで割り当てられた会話を開いたときにスタートし、別の会話に切り替えたとき、または会話がスヌーズ、再割り当て、またはクローズされたときに一時停止します。さらに、チームメンバーが非アクティブになり自動的に離席状態に設定された場合も一時停止します。

仕組み

時計はチームメンバーがInboxで会話を開いたときにスタートし、次のいずれかが起こるまで動き続けます：別の会話に切り替えた、会話がスヌーズ、クローズ、または再割り当てされた、または非アクティブにより自動離席になった。チームメンバーが会話に積極的に参加している時間のみがカウントされます。

典型的なシナリオ

チームメンバーが朝のキューを処理している様子：

9:00 — 新しい会話がチームメンバーのinboxに届きます。割り当てられていますが、まだ開いていません。時計は動いていません。
9:02 — チームメンバーが会話をクリックして読み始めます。時計がスタートします。
9:08 — さらに情報が必要なため、同じ顧客の別の会話に切り替えます。最初の会話の時計は一時停止し、2つ目の会話の時計がスタートします。
9:12 — 必要な情報を得て最初の会話に戻ります。最初の会話の時計が再開し、2つ目の会話の時計は一時停止します。
9:14 — 返信を作成中に、別のブラウザタブでJiraを開いて関連するticketを確認します。時計は動き続けます — Intercomの会話にまだいます。
9:18 — 返信を送信し、会話を翌日のフォローアップのためにスヌーズします。時計は一時停止します。

これにより、最初の会話の処理時間は10分（9:02→9:08 + 9:12→9:18）と記録されます。

処理時間としてカウントされるもの

時計は、会話がチームメンバーのInboxでアクティブな会話である場合に動作します — 以下の場合を含みます：

会話がInboxで開かれ、表示されている場合
チームメンバーが返信を入力したり、メモを書いたり、スレッドを読んでいる場合
チームメンバーがSlack、Jira、または別のブラウザタブにalt-tabしている場合

時計は以下の場合に一時停止します：

チームメンバーが別の会話をクリックした場合
会話がスヌーズ、クローズ、または再割り当てされた場合
チームメンバーが非アクティブになり自動的に離席状態に設定された場合

自動離席

チームメンバーが非アクティブで自動的に離席状態に設定された場合、アクティブな会話の時計は一時停止します。自動離席の一時停止は設定で構成可能で、デフォルトでは無効です。必要に応じて設定 > 割り当てで有効にできます。

レポート

調整処理時間は、標準の処理時間メトリクスと共にカスタムレポートで利用可能です。すべての標準レポート機能（フィルタリング、セグメンテーション、CSVエクスポート、チャート、集計）はこれらのメトリクスで動作します。

メトリクス	データセット	説明
調整済み会話処理時間	会話	アイドル期間を除いた、すべてのチームメンバーが会話の処理に費やした合計時間。会話がクローズされた後に利用可能。
調整済みチームメンバー処理時間	チームメンバー会話処理	特定のチームメンバーが会話に費やした時間で、アイドル期間を除く。勤務時間内バリアントもサポート。

API

Conversation APIの調整処理時間

カスタム統合を構築する場合やプログラムで処理時間データを取得する必要がある場合、GET /conversations/:idエンドポイントはstatisticsオブジェクト内にadjusted_handling_timeを含みます。

{
  "statistics": {
    "handling_time": 2310,
    "adjusted_handling_time": 1800
  }
}

値は秒単位です。アイドル時間がない場合、adjusted_handling_timeはhandling_timeと等しくなります。このフィールドは会話がクローズされた後にのみ入力されます。

処理イベントエンドポイント

GET /conversations/:id/handling_eventsは会話の一時停止および再開イベントの完全なリストを返します。このエンドポイントは、リアルタイムで処理アクティビティを監視したり、カスタム処理時間計算を実行したり、調整済みメトリクスを超えた分析を構築したりする場合に便利です。会話のライフタイム中いつでも呼び出せます — クローズ後だけでなく。

各イベントにはチームメンバー、イベントタイプ（pausedまたはresumed）、タイムスタンプ、および一時停止イベントの場合は理由が含まれます。

{
  "handling_events": [
    {
      "teammate": { "id": 123, "name": "..", "email": ".." },
      "type": "paused",
      "timestamp": "2024-01-15T09:00:00Z",
      "reason": "snoozed"
    },
    {
      "teammate": { "id": 123, "name": "..", "email": ".." },
      "type": "resumed",
      "timestamp": "2024-01-15T09:12:00Z"
    }
  ]
}

一時停止理由：

switch — チームメンバーが別の会話に移動した
close — 会話がクローズされた
snooze — 会話がスヌーズされた
reassign — 会話が別のチームメンバーに再割り当てされた
auto_away — チームメンバーが非アクティブで自動的に離席状態に設定された

トラブルシューティング

調整処理時間はブラウザから追跡されます。ほとんどの場合正確ですが、まれにブラウザの予期せぬシャットダウン、ノートパソコンのメモリ消去、インターネット接続の喪失などのシナリオでイベントが失われることがあります。その場合、メトリクスは自動的に従来の処理時間にフォールバックし、値がなくなることはありません。

ワークスペースのオプトイン日以前に作成された会話には処理イベントがありません。正確なメトリクスを期待する前に新しい会話でイベントを収集させてください。

ヒント：信頼性の高いイベント追跡にはChromeやFirefoxなどの最新ブラウザを使用してください。

よくある質問

Average Adjusted Handling Timeはticketsに対応していますか？

調整処理時間は会話と顧客ticketsに対応しています。バックオフィスtickets、トラッカーtickets、サイド会話には対応していません。

バックオフィスticketに書き込むと顧客ticketの時計は一時停止しますか？

バックオフィスticketに書き込んでも顧客ticketの時計は一時停止しません。別の顧客会話に切り替えた場合のみ一時停止がトリガーされます。

同じ会話が複数のタブで開かれている場合は？

調整処理時間は、同じ会話が複数のタブやデバイスで開かれていても二重カウントされません。重複する再開および一時停止イベントは自動的に統合されます。

Average Adjusted Handling Timeは通常の処理時間と同じようにレポートで使えますか？

調整処理時間は、フィルタリング、セグメンテーション、エクスポート、チャート、集計など、通常の処理時間と同じレポート操作をサポートします。

処理イベントは会話タイムラインに表示されますか？

処理イベントは会話タイムラインには表示されません。処理イベントはAPIのhandling eventsエンドポイントでのみアクセス可能です。

平均調整処理時間の使い方

仕組み