初回対応時間レポートの作成方法：完全ガイド
初回返信時間とは、顧客がチケットを送信してから、最初の人間による返信を受け取るまでの待ち時間のことです。初回返信時間レポートは、平均値ではなく中央値と90パーセンタイルで分類し、数週間にわたるその待ち時間を追跡します。2つのタイムスタンプが含まれるチケットのエクスポートデータから作成でき、1つのプロンプトまたは3つの数式だけで完了します。
測定自体はシンプルです。しかし、レポート作成において、チームは知らず知らずのうちに誤った判断に導かれてしまうことがあります。なぜなら、デフォルトの統計値やデフォルトのパーセンタイル関数は、最も長く待たされた顧客の存在を隠してしまうからです。
初回返信時間とは何か、そしてその計算方法
初回返信時間（FRT）とは、チケットが到着してから担当者が顧客に最初の返信を行うまでの経過時間です。数式は見た目通り非常にシンプルです。
初回返信時間 ＝ 最初の人間による返信のタイムスタンプ − チケット作成のタイムスタンプ
この1行の数式をチーム全体が実際に合意できるものにするには、2つの決定を下す必要があります。
自動応答メールはカウントに含めるべきか？ 含めるべきではありません。「メッセージを受信しました」という自動返信は、質問に対する回答ではないからです。これをカウントに含めると、見栄えの良いチャートができあがりますが、顧客の不満は解消されません。これは通常、意図的な欺瞞ではなく、単なる勘違いによるものであり、FRTが実態より良く見えてしまう最も一般的な原因です。
夜間も時間をカウントするか？ カレンダー時間（実時間）で測定すると、金曜日の夕方に届いたチケットに月曜日の朝に返信した場合、60時間の遅延となります。一方、営業時間（ビジネス時間）で測定すると、1時間未満になることもあります。どちらも間違いではありません。同僚と異なる基準で数字を引用し合うことが、議論のすれ違いを生む原因になります。
平均FRTの扱いが3つ目の決定事項であり、これは多くのツールが自動的に処理してしまう部分です。返信時間は右に歪んだ分布（右に長い裾を持つ分布）になります。つまり、ほとんどのチケットは迅速に処理されますが、ごく一部のチケットが非常に長く放置されます。そのため、平均値（相加平均）をとると、実際にはほぼ誰も経験していないような長い時間に引っ張られてしまいます。代わりに中央値と90パーセンタイルを報告するようにしましょう。
開始する前に必要なもの
- 会話1件につき1行で構成されたチケットのエクスポートデータ。
- 2つのタイムスタンプ：チケットが到着した日時と、担当者が最初に返信した日時。
- 自動応答や社内メモを除外した「初回返信」の定義。
- 営業時間（ビジネス時間）でレポートを作成する場合は、サポートの対応時間。
- データ件数が少ない週に、それらしいだけの無意味なデータが生成されるのを防ぐための最小ボリュームルール。
何かを作成する前に、最後の3つの項目を決定してください。後からこれらを設定変更すると、チャート上のそれ以前のすべての週のデータが無効になり、定義がブレているトレンドラインは、トレンドラインが全くない状態よりも悪影響を及ぼします。
スプレッドシートでレポートを作成する方法
オプション 1：2つのタイムスタンプを経過時間に変換する
初回返信のタイムスタンプから到着のタイムスタンプを差し引き、結果を「時間」形式にフォーマットします。これが、カレンダー時間における各チケットの生の初回返信時間です。
代わりに営業時間（ビジネス時間）が必要な場合は、通常はNETWORKDAYS.INTL関数から始めます。Microsoftのドキュメントには、この関数が返す値について正確に記載されています。この関数は、どの曜日を週末とするかを示すパラメータを使用して、「2つの日付の間の稼働日の全日数」を返します。週末および祝日引数で指定された日は「稼働日とはみなされません」。
「稼働日の全日数」という表現に注意してください。この関数は時間ではなく「日数」で回答を返すため、同じシフト内での4時間の待ち時間と7時間の待ち時間は、関数上ではまったく同じに見えてしまいます。1日未満の経過時間を算出するには、稼働日数と1日の中の端数時間を組み合わせる仕組みを構築する必要があります。営業時間ベースのレポート作成が、単なる数式ではなく、1つのプロジェクトになってしまうのはこのためです。
オプション 2：中央値と90パーセンタイルを計算する
MEDIAN関数は、一般的な待ち時間を示します。分布の裾（外れ値）については、Excelに2つのパーセンタイル関数が用意されていますが、ここで同じデータから2つの異なる答えが導き出されることになります。
PERCENTILE.EXCは、「0から1の間（0と1を除く）」のk値を受け入れます。ドキュメントによると、「kが1/(n + 1)の倍数でない場合、PERCENTILE.EXCは補間を行ってk番目のパーセンタイルの値を決定します」。一方、PERCENTILE.INCは「0から1の間（0と1を含む）」のkを受け入れ、kが「1/(n - 1)の倍数でない場合」に補間を行います。
分母が異なり、補間方法が異なれば、算出されるp90も異なります。どちらも間違いではありません。これらは2つの異なる慣例であり、これらを説明なしに切り替えて作成されたレポートは、キューの実態ではなく、数式の仕様を反映しているに過ぎなくなります。
除外（EXC）バージョンには、より注意が必要な点があります。ドキュメントには、「指定されたパーセンタイルkに対して補間できない場合、Excelはエラー値 #NUM! を返します」と警告されています。データ件数が少ない週や、1つのキューに数件しかチケットがない場合、p90の計算自体が失敗することがあります。
オプション 3：レポートのレイアウトを整える
チケットを週ごとにグループ化します。中央値とp90を2本の折れ線として並べて配置し、その背景にチケット件数を棒グラフとして追加します。この件数は単なる飾りではありません。わずか11件のチケットによって生じたスパイク（急増）を、読み手が過剰に解釈してしまうのを防ぐための重要な要素です。
次に、使用した時間基準（カレンダー時間か営業時間か）とパーセンタイル算出方法を明記したテキストを1行追加します。この一文があることで、その場にいなかった他の担当者でも、次の四半期に同じレポートを再現できるようになります。
スプレッドシートによる方法で行き詰まるポイント
3つのステップはいずれも難しくありません。しかし、誰かがヘルプデスクのビューを編集するたびに列名が変わってしまうエクスポートデータに対して、これら3つの作業を毎週やり直さなければならないというコストが発生します。
具体的には、以下の3つの摩擦が繰り返し発生します。
返信列が整理されていることは滅多にありません。 自動応答、社内メモ、担当者の返信が同じフィールドに混在することが多いため、最初の行が必ずしも最初の人間による回答とは限りません。これらを分類するには、数式ではなく、エクスポートごとに個別の判断が必要になります。
パーセンタイルは毎回判断を必要とします。 どの関数を使用するか、どの週に十分なデータ量があるか、そしてデータ件数の少ないキューで計算エラーが発生したときに何を表示するかを決める必要があります。
営業時間の管理はメンテナンスの手間がかかります。 サポート対応時間に基づく測定を導入すると、祝日やシフト変更のたびにワークブックの更新作業が発生します。1つでも見落とすと、その週全体のデータがずれてしまいます。
その結果、作成した週だけは正確で、その後は徐々に実態からずれていくレポートになってしまいます。
AIを使用して初回返信時間レポートを作成する方法
ステップ 1：チケットのエクスポートデータをアップロードする
Powerdrill Bloomを開き、ヘルプデスクからエクスポートしたデータをそのままアップロードします。無料プランではExcel、CSV、PDF、および各種ドキュメントのアップロードがサポートされているため、生のデータをそのまま投入できます。
自動応答のものも含め、すべてのタイムスタンプ列を保持しておきます。これらは、どの返信がカウントされたかを証明するため、また、後から再エクスポートすることなく定義を切り替えるために必要となります。
ステップ 2：使用する時間基準と必要な統計値を指定する
数式ではなく、自然言語で測定方法を説明します。どのタイムスタンプで測定を開始し、どの返信で終了するか、週末をカウントに含めるかどうかを指定します。その上で、週ごとの中央値と90パーセンタイルを、チケット件数と併せて算出するよう指示します。
データ件数が少ない週の処理方法についても指定します。チケット件数が最小基準を下回る場合は、パーセンタイルの表示を抑制するように指示してください。これにより、エラーセルが表示されるのを防ぎ、また、わずか4行のデータから算出された「それらしい数字」が表示されるのを避けることができます。
各数値は背景にあるデータ行と紐づいて返されるため、不審なデータがある週については、議論を戦わせる代わりに、そのデータを直接開いて確認することができます。
ステップ 3：レポートを生成してプロンプトを保存する
週単位の軸上に2本の折れ線と1つの棒グラフを表示し、どのパーセンタイル基準が使用されたかを明記したメモを追加するよう指示します。作成したレポートは、画像、スプレッドシート、またはスライドとしてエクスポートできます。
翌週は、新しいエクスポートデータをアップロードして、同じプロンプトを実行するだけです。定義が固定されるため、週ごとの比較に真の意味が生まれます。グラフ作成の手順については、make graphs from Excelのページで詳しく解説しています。
初回返信時間レポートに含めるべき要素
| 要素 | 必要な理由 | ない場合に生じる問題 |
|---|---|---|
| 中央値の折れ線 | 一般的な顧客の待ち時間を示すため | 平均値は外れ値の影に隠れてしまう |
| 90パーセンタイルの折れ線 | 最も対応が遅かった上位10%の顧客体験を示すため | 深刻な遅延（分布の裾）が見えなくなる |
| チケット件数の棒グラフ | すべての変動に文脈（背景）を与えるため | 件数の少ない週のデータがトレンドとして誤読される |
| 明記された時間基準 | カレンダー時間か営業時間かを示すため | 2つのチームが異なる数値を引用し合うことになる |
| 明記されたパーセンタイル基準 | 再現性を確保するため | レポート作成のたびに同じ週の数値が変わってしまう |
| 最小ボリュームルール | データの少ないセグメントにおける誠実性を保つため | エラーが発生するか、架空の精度が表示される |
| チャネル別の内訳 | 遅延が実際にどこで発生しているかを特定するため | 1つの悪いキューが全体の数値を引き下げてしまう |
具体的な計算例
チケット件数が240件のある週を例にとってみましょう。平均初回返信時間は5.1時間、中央値は1.4時間、p90は19.7時間です。
これら3つの数値はすべて正確です。しかし、平均値だけは、実際の誰の体験も表していません。ほとんどの顧客は90分未満しか待っておらず、最も遅かった上位10%の顧客は丸一日の大半を待たされています。平均値だけを提示すると、読み手は「全体的に対応が平凡なキューである」と結論付けてしまいますが、実際には「対応は早いが、一部に深刻な遅延（悪いテール）がある」というのが実態です。深刻な遅延への対策は、全体的に遅いキューへの対策とは異なります。だからこそ、この違いを単一のセルではなく、チャートで視覚化する価値があるのです。
レポートの整合性を保ちながらセグメント化する方法
次に生じる当然の疑問は、「どのチャネルやキューが最も遅いのか」ということです。セグメントごとに分割することは有用ですが、同時にレポートが実態を偽る原因にもなり得ます。
データの誠実性を保つための2つのルールがあります。週ごとのデータ量が最小基準を上回っているセグメントのみに分割すること、そして、読み手が基準（ベースライン）を確認できるように全体の折れ線をチャート上に残しておくことです。週に9件しかチケットがないキューは、週単位ではなく月単位のビューで確認すべきです。
トレンドよりもセグメントごとの分割が重要な場合は、5本の折れ線を重ねるよりも、キューごとの中央値とp90をまとめた小さな表を作成する方が、より多くの有益な情報を提供できます。
初回返信時間を改善する方法
レポートは、具体的なアクションにつながってこそ作成する価値があります。改善のための4つのレバー（手段）が繰り返し登場しますが、レポートを見ればどれが必要かが分かります。
中央値は良いがテール（p90）が悪い場合、通常は対応スピードではなく、カバー範囲（体制）に問題があります。対応時間外に到着したチケットや、専門担当者が1人しかいないキューのチケットは、担当者が戻るまで放置されます。担当者のパフォーマンスを疑う前に、チケットが到着した時間帯を確認してください。
データ量は一定なのに中央値が上昇している場合、通常は、誰もテンプレートを持っていない新しいタイプのチケットがキューに流入していることを意味します。チャネル別の内訳を確認すれば、その原因が明らかになります。
データ量と中央値がともに上昇している場合は、人員配置の問題であり、件数を示す棒グラフがその強力な根拠になります。
誰も信用していない、変化のないレポートは、定義の問題です。時間基準とパーセンタイル算出方法をレポートの上部に明記すれば、不毛な議論は収まります。
これと並行して確認すべきデータ量やステータスのビューについては、support ticket reportおよびCSAT reportに関するガイドを参照してください。また、同じキューにおける問い合わせ削減（デフレクション）の側面については、customer service chatbotのページで解説しています。
適切な目標設定とは
チームは、データの分布を把握する前に初回返信時間の目標を設定してしまいがちです。その結果、目標が無意味なものになるか、あるいは達成不可能なものになってしまいます。
1つではなく2つの数値を設定し、その両方を公開しましょう。中央値の目標は通常の顧客体験を表し、p90の目標は許容できる最悪の顧客体験を表します。中央値が1.4時間でp90が19.7時間のチームは、テール（遅延）に問題を抱えています。単一の「2時間」という目標を設定しているだけでは、この問題はまったく表面化しません。
そして、目標と併せて時間基準を明記してください。営業時間における「2時間」と、カレンダー時間における「2時間」は、まったく異なる約束事です。サポートチームと経営陣は、それぞれ自分たちの都合の良いように解釈してしまうでしょう。
よくある間違い
平均値を報告すること。 これは、右に歪んだ分布においてほぼ確実に誤解を招く統計値であり、多くのスプレッドシートツールのデフォルト設定になっています。
自動応答を初回返信としてカウントすること。 これは、見栄えは素晴らしいものの、誰の実際の体験とも一致しないチャートを作成する最も手っ取り早い方法です。
四半期の途中でパーセンタイル関数を切り替えること。 誰かが数式を編集したのと同じ週にp90が改善された場合、あなたが測定したのは「数式の編集結果」に過ぎません。
カレンダー時間と営業時間を混同すること。 カレンダー時間における週末は48時間の遅延（失敗）になりますが、営業時間においてはゼロになることもあります。どちらか一方を選択し、明記してください。
見栄えをすっきりさせるためにデータ件数の系列を削除すること。 棒グラフがあるからこそ、本当のパフォーマンス低下と、単に問い合わせが少なかった週とを区別することができます。
分布を示さずに目標達成のみを報告すること。 単に「2時間を達成しました」という数値だけでは、9時間待たされた顧客の存在について読み手には何も伝わりません。
結論
初回返信時間レポートは、顧客が実際に体感する数少ないサポート指標の1つであるため、適切に作成する価値があります。2本の折れ線、1つの棒グラフ、明記された時間基準、そして明記されたパーセンタイル基準を備えたレポートは、単一の平均値のみを表示するどのようなダッシュボードよりも優れています。
毎週レポートを再作成する手間がネックになっている場合は、定義を保存済みのプロンプトに移行し、新しいエクスポートデータから再生成するようにしましょう。先月のチケットエクスポートデータを使用してTry Powerdrill Bloomをお試しいただき、中央値とテール（遅延）が同じ軸上でどのように表示されるかを確認してください。
よくある質問
カスタマーサービスにおける初回返信時間とは何ですか？
顧客のチケットが到着してから、人間の担当者が最初に返信するまでの経過時間のことです。自動応答は顧客の質問に回答していないため、通常は除外されます。
初回返信時間の計算式を教えてください。
最初の人間による返信のタイムスタンプから、チケット作成のタイムスタンプを差し引きます。営業時間ベースで算出する場合は、NETWORKDAYS.INTL関数（稼働日の全日数を返し、週末や祝日を定義可能）から開始し、1日の端数時間を加算します。
初回返信時間レポートでは平均値と中央値のどちらを使用すべきですか？
中央値を使用し、その横に90パーセンタイルを並べるべきです。返信時間は右に歪んだ分布になるため、ごく少数の非常に対応が遅いチケットによって平均値が引き上げられ、実際の多くの顧客が経験していない数値になってしまうためです。
PERCENTILE.EXCとPERCENTILE.INCの違いは何ですか？
これらは異なる補間ルールを使用します。PERCENTILE.EXCは、kが1/(n + 1)の倍数でない場合に補間を行い、0より大きく1未満のkのみを受け入れます。PERCENTILE.INCは1/(n - 1)を使用し、0と1そのものも受け入れます。
p90の計算で #NUM! エラーが返されるのはなぜですか？
PERCENTILE.EXCは、配列が空の場合、またはkが0から1の範囲外（または境界値）にある場合にそのエラーを返します。また、指定されたパーセンタイルに対して補間ができない場合にもこのエラーを返しますが、これはデータ件数が少ない週に発生しがちです。