すべてのレポートテンプレートがすべてのプランで利用できるわけではありません：

はい、すべての顧客がレポートを作成できます。ただし、プランにカスタムレポートが含まれていない場合、チャートライブラリからチャートを追加することのみ可能で（独自のカスタムチャートは作成できません）。

カスタムチャートはチャートビルダーで作成または編集されたものです。チャートライブラリから追加したチャートはプリビルトチャートです。プリビルトチャートを編集して変更を保存すると、それはカスタムチャートになります。カスタムレポートを含むプランから含まれないプランにダウングレードすると、作成したカスタムチャートはアクセスできなくなります。

フィルターの適用などレポートへの変更は、編集モードで保存しない限り保存されません。表示モードでの変更はブラウザをリロードするとクリアされます。

カスタムレポートでは、編集モードで行ったすべての変更（チャートのグリッド上の移動を含む）は保存をクリックしたときのみ保存されます。キャンセルをクリックすると、すべて最後に保存された状態に戻ります。

つまり、チャートの位置を変更してからチャートエディターを開いてキャンセルすると、グリッドの移動は他の未保存の変更とともに破棄されます。これは想定された動作です。

各チャートタイプにはグリッド単位（幅×高さ）で測定される最小サイズがあります。最小サイズは以下の通りです：

Intercomの旧プリビルトレポートには、新しいレポートテンプレートで再現不可能なバージョンの指標やフィルターを使用したチャートが含まれていました。またはカスタムレポートで再現可能な結果を表示していました。新しいレポートテンプレートはカスタムレポートと同じ指標、フィルター、チャートタイプを使用しているため、すべてのチャートはカスタムレポートで再現可能です。

集計とは、個々の会話からの異なる値をすべて組み合わせて単一の数値として表示する方法です。

例えば、すべての会話の各返信の異なる応答時間を取り、それらを集計して「中央値」の応答時間を表示することです。

チャートの集計を中央値から平均に変更する方法は3つあります：

チャートの集計を最大値/最小値に変更するには、AdvancedまたはExpertプランでカスタムレポートへのアクセスが必要です。この集計はチャートを直接編集する顧客のみ利用可能です。

Bot Inboxは、Finまたはボットが会話を処理し、チームメイトにルーティングする前のキューです。Bot Inbox Timeは現在、メトリックレベルで選択されます。チャートテンプレートライブラリからBot Inboxの時間に影響を受けるチャートを選択すると、ボットに割り当てられた時間を含むか、ボットがチームに引き継いだ後かのメトリックの別バージョンが表示されます。

Intercomでは、ハンドオフ時のFirst Response Time（FRT）をカスタマイズして測定できます。人間のやり取りにのみ焦点を当てるには、bot inbox時間を除外したFRTメトリックを選択してください。例えば：

「First Response Time without Bot Inbox Time」を選択すると、ボットとのやり取り終了直後の人間のチームメイトの応答を監視できます。

はい、ただし将来の会話に限ります。会社名に基づいて会話を除外したい場合は、その会社内のチームメイトのプロフィールにユーザータグを追加することで間接的に行えます。タグが追加されると、タグ付けされたユーザーによるすべての新しい会話がレポートから除外されます。

タグに基づいて過去の会話をレポートから遡って除外することは現在できません。各会話は作成時のユーザーの状態のスナップショットを取得するため、後からタグを追加しても過去の会話は更新または除外されず、新しい会話のみが対象となります。

Intercomのレポートは、個別の連絡先やユーザーごとに会話数をセグメントまたはグループ化することをサポートしていません。レポートは会話単位で構成されており、各顧客が開始した会話数を示す標準のメトリックや内訳オプションはありません。

会社またはアカウントごとの会話量を確認するには：カスタムレポートチャートでCompany (conversation)属性を内訳として使用します。これにより、各会話に関連付けられた会社ごとに会話がグループ化され、サポートされている最も近いグループ化レベルとなります。

個別の連絡先ごとに内訳を表示するには：レポーティングUIでは直接提供されません。個別の連絡先ごとの内訳は、Datasetエクスポートを使用して外部で会話レベルのデータを分析してください。

いいえ。レポートをワークスペース間で複製またはコピーすることはできません。レポートは作成されたワークスペースに限定され、他のワークスペースに転送または複製できません。

複数のワークスペースで同様のレポートが必要な場合は、それぞれのワークスペースで手動で再作成する必要があります。

はい、会話がない場合、合計集計は0を返します。

これは、ドーナツチャートが表示している属性のすべての「スライス」を示すことで関係を正確に比較できるようにするためです。表示している属性の横にある「上位値を表示」を変更してスライス数を増やすことができます。

いいえ、現在「その他」グループ表示をサポートしているのはドーナツチャートのみです。

エリアチャートを作成し、積み上げトグルを「オン」に設定することで作成できます。

「New conversations」メトリックでは、会話の最初のメッセージのスナップショットを取得してレポートのデータを作成します。タグが会話開始後にユーザープロフィールに追加された場合、その会話はレポートに含まれ続けます。

集計行は選択されたメトリックの集約レベルで再計算されたロールアップであり、テーブル内の行の合計や平均ではありません。この方法により、全体のパフォーマンスに対して最も正確で関連性の高い洞察が得られます。

例えば、「Closed conversations」メトリックは閉じられたユニークな会話の数を表します。集計行は指定された期間内に閉じられたユニークな会話の合計数を表示します。もし下の行の値を合計すると、単一の会話が複数のチームメイトによって閉じられることがあるため、カウントが多くなることがあります。

Intercomのレポートでは、各会話は一度だけカウントされます。例えば、複数日の返信がある会話が週単位でセグメントされると、その会話は結果に一度だけ表示されます。しかし日単位でセグメントすると、その会話は各日に表示されます。これが時間や日を選択したときに数値が増える理由です。

カスタムレポートは会話またはticketsのメトリックの内訳を表示するためのものであり、UserまたはLead情報のみを表示するレポートは作成できません。

会話またはTicketsがレポートやチャートに含まれている場合、ワークスペースプランのオプションによっては、レポートからそれらの会話やticketsに関連するUsersおよびLeadsを詳細に表示できる場合があります。

UserおよびLeadのプロフィール情報や属性専用のレポートを作成するには、Reportingセクションの「Data export」機能を使用し、Intercom外の独自のレポートツールでレポートを作成する必要があります。

いいえ。Email domainはIntercomのデフォルトの連絡先属性で連絡先プロフィールに表示されますが、カスタムレポートのフィルターや内訳オプションとしては利用できません。レポートフィルターピッカーで検索しても結果は表示されません。

カスタムレポートは会話およびticketsを中心に構成されており、ユーザーや連絡先レコード単位ではありません。顧客プロフィールに表示されるすべての属性がレポートフィルターとして利用できるわけではなく、チャネル、チーム、タグ、トピック、ユーザータグなど特定の会話レベル属性のみがサポートされています。

回避策：対象のドメインの連絡先にユーザータグを適用し、レポートでUser tagフィルターを使用してください。レポートは会話作成時のユーザーデータをスナップショットするため、タグは会話開始前に適用する必要があります。

Intercomの組み込みアプリバージョン属性（ios_app_version_stringやandroid_app_versionなど）は、ユーザープロフィールには表示されますが、カスタムレポートのフィルターや内訳オプションとしては利用できません。

アプリバージョンで会話をセグメントする必要がある場合、カスタム属性でアプリバージョンを追跡し、それをレポートのフィルターとして使用するのが最も近い回避策です。

レポートのフィルターやメトリックに表示されないカスタム会話またはticket属性はアーカイブされている可能性があります。アーカイブされた属性はレポートのフィルターや内訳オプションとして利用できません。

欠落した属性を復元するには：

復元すると、その属性はレポートのフィルターやメトリックに再表示されます。

これは、状態が変わらずに2年以上オープンのままの会話があるためです。Reportingでは過去2年分のデータのみを取り込むため、「Open」状態が2年以上前に始まった会話はデータセットに含まれません。

Intercomのレポートデータは、基となる会話や連絡先データが変更されると遡って変わることがあります。一般的な原因は、会話が完全に削除された（履歴カウントから除外される）、連絡先や会社の属性が更新された（ほとんどの属性は会話作成時に固定されます—「Which report fields update live, and which freeze at conversation creation?」参照）、または会話が統合された（統合された会話はデータセットに残りますが統合済みとしてマークされます）などです。数値が予期せず変わった場合は、該当期間にこれらの操作が行われたか確認してください。

2025年のデータはすでにReportingにバックフィルされていますが、大量のデータのため2024年以前のバックフィル完了にはもう少し時間がかかります。

これは「Self-assign by replying」設定が有効で、返信時に会話がまだあなたに割り当てられていない場合に発生することがあります。

会話が未割り当て、または別のteammateに割り当てられていて、Self assign by replyingが「Assign it to me」に設定されている場合、最初の返信は会話内にメッセージを送信し、同時に会話をあなたに割り当てます。これらの操作は同時に行われるため、返信が割り当て後に行われたと認識されず、「Teammate assignment to first response」メトリックでキャプチャされません。

これを避けるには、最初の返信を送る前に会話を自分に割り当てるか、Settings > Inbox > Assignmentsで設定を「Keep it unassigned or assigned to the team inbox」に変更してください。

チームinboxに入った会話は自動的に個々のteammateに割り当てられず、teammateが取り上げるか管理者が手動で割り当てるまでチームキューに残ります。これにより「Teammate assignment to first response」などのレポート指標に影響が出ます。タイマーは割り当て時点から開始され、inboxに入った時点からではありません。手動割り当ては自動割り当てルールを上書きしますが、ワークスペースの優先設定には従います。

比率やパーセンテージのメトリックでは、チャート上のⓘアイコンにカーソルを合わせると「How it’s calculated」の行が表示されます。式は分数で表示され、例えばCSAT % Happyは「happy ratings ÷ total ratings」となります。カウントや期間のメトリックには式のツールチップは表示されず、比率やパーセンテージのメトリックのみ表示されます。

式は計算の形を示しており、正確な算術ではありません。パーセンテージの×100などの乗数は意図的に省略されています。例えばCSAT % Happyは「happy ratings ÷ total ratings」と表示され、「happy ratings ÷ total ratings × 100」ではありません。これは正常な動作です。

レポートヘッダーの「Updated X min ago」表示は、レポート内で最も同期が遅いデータセットを反映しています。異なる同期速度のデータセットを組み合わせた場合、最新の同期時間ではなく最も古い同期時間が表示されます。これはデータが遅延または破損しているわけではなく、異なる同期速度のデータセットを混在させた場合の正常な動作です。

Intercom Reportsは異なるレベルで適用されるフィルターを使用しており、レポートレベルとチャートレベルのフィルターの違いを理解することが重要です。

解決策：

一貫した数値を確保するには、適用されているフィルターを揃えてください。以下のいずれかを行えます：

レポートは会話作成時のユーザーおよび会社属性のスナップショットを使用するため、その後の属性更新は遡って反映されません。

一般的なシナリオ：

チャートのドリルインビューに「Currency」列を追加すると、属性スナップショットが作成後に更新されないため、古いまたは不完全な情報が表示されることがあります。

解決策：

属性更新のタイミングを再確認し、会話ベースのレポートは作成時の属性状態のみを含むことを理解してください。

リアルタイムダッシュボードは約1分ごとに更新されますが、フォアグラウンドのブラウザタブで使用中のみです。Time Activeの合計の違いは主に以下が原因です：

FCR（First Contact Resolution）やその他のメトリックは、ダッシュボードビューと編集モードで異なる場合があります。これはダッシュボードレベルで追加のフィルターやセグメントが適用されているためで、編集時の個別チャートビューには引き継がれません。

解決策：

フィルターの適用場所とデータの含有・除外への影響を理解してください。ダッシュボードレベルとチャートレベルの両方の設定を参照して整合させましょう。

チーム単位で適用されるフィルターと特定のteammate単位で適用されるフィルターは異なるデータセットをもたらします：

「Active」と「Away」メトリックをteammate別に組み合わせるなど、一部のチャート設定ではデータが欠落することがあります。これはメトリックの計算やグループ化の構造的な違いによるものです。

解決策：

「Active」と「Away」メトリックを個別に追跡するために別々のチャートを作成し、不要な組み合わせを避けてください。

Intercomレポートを最適化するには:

これは、レポートレベルのフィルターがチャートのデータセットでサポートされていない属性を参照している場合に発生します。フィルターはレポート内のすべてのチャートに適用されますが、チャートがその属性を含まないデータセットを使用している場合、結果が返されず理由が説明されます。修正するには、レポートレベルのフィルターを削除または変更するか、適用される個々のチャートに移動してください。

これは、チャートが上位Nを表示（例：上位7を表示）に設定されている場合の予期される動作です。この設定では、指定期間内で最も多いN件のみが表示されます。その期間の上位Nに入らないエントリーは、実際に活動があっても表示セットに含まれないため、0またはnullとして表示されます。

すべてのエントリーを表示するには、チャート設定の上位表示の値を増やしてください。例えば、上位7から上位10に変更するか、全員を含めるためにさらに高く設定します。この設定はチャートを編集し、表示方法オプションを調整することで見つけられます。

会話の統合は「返信した会話」数を減らしません。

会話を別の会話に統合しても、統合された会話は削除されず、レポートデータセットに残り、統合済みとしてマークされます。その会話に対するチームメイトの返信もカウントされ続けます。統合だけでは指標は減りません。

数が減った場合は、統合ではなく完全削除が原因です。会話が完全に削除されると、その会話と返信記録はレポートデータセットから削除され、該当期間のカウントが減少します。

Intercomのレポートでは、「返信した会話」と「送信した返信」はチームメイトの活動の異なる側面を測定します。以下の表は各指標がどのようにインタラクションをカウントするかを比較しています。

例：チームメイトが2つの会話で4回返信した場合:

返信した会話はチームメイトが対応した異なる顧客問題の数を測るのに使い、送信した返信は返信量や労力を測るのに使います。

ほとんどの連絡先や会社の属性およびタグは会話作成時にスナップショットされ、その後更新されません。後で変更した値は古い会話には反映されません。ただし、連絡先の名前、メール、仮名、およびワークスペースで有効になっている場合はCompany (conversation)属性（会話に直接設定された単一の会社）はライブで読み込まれます。会話開始後に取得した信号をレポート可能にしたい場合は、連絡先や会社ではなく会話自体（会話属性やタグ）に適用してください。

レポートは会話作成時点で会社属性やタグを固定します。これは統合や同期で埋められたカスタム会社属性も含みます。例えばSalesforce同期が会話開始後数時間で会社フィールドを埋めても、その会話のレポート行は作成時の空の値を保持します。値設定後に作成された新しい会話は表示されます。会話の期間中に変わる値を報告したい場合は、会話に保存してください。

ここでのカウントは、チームメイトがその後に会話に関与（返信、割り当て、メモ追加、再オープンと再クローズ）した場合に変わることがあります。「チームメイトが参加しなかった」などのフィルターは、閉じた時点ではなく、レポート実行時点の会話参加履歴に基づいてチェックされます。閉じた時点で本当に返信なしだった会話も後でそのバケットから外れることがあり、古いバックログが処理されるにつれて日ごとのカウントが減少し続ける理由です。また、ワークスペースの報告タイムゾーン（設定）と表示タイムゾーンの不一致も、会話の活動がどの日に割り当てられるかをずらす可能性があります。

「クローズまでの時間」はチームメイトがクローズした会話のみを測定します。Fin、ボット、またはWorkflowsによって解決された会話はチームメイトのクローズがないため、この指標には含まれません（ゼロとして表示されるのではなく、単にカウントされません）。

会話の多くが自動化でクローズされている場合、「クローズまでの時間」のカウントは総クローズ数よりかなり少なくなります。すべてのクローズを測るには自動化を含むクローズまでの時間を使い、最後にクローズした人で人間と自動の割合を分けてください。

Intercomにはライブ統計用のディスプレイユニットを直接設定する方法はありません。ただし、外部画面共有を使い、リアルタイムダッシュボードや概要レポートなどのレポートページを表示して、エージェントのパフォーマンスと全体のパフォーマンスを毎日紹介できます。

チームメイトが積極的に返信しているか確認するには、次のいずれかを行います。

はい！すべてのカスタマー向けTicketsは会話に直接紐づいているため、会話データは自動的にレポートに含まれます。

各レポートチャートにはチャートドリルイン機能があり、データを詳しく調べてレポートで表示される指標の背後にある要因を理解できます。

会話データを詳しく確認する必要がある場合、会話内容やデータをダウンロードおよびエクスポートする方法はいくつかあります。

会話アクションとは、会話内で行われる特定の操作を指します。これには割り当て、返信、会話の終了などのタスクが含まれます。例えば、Chart Drill-Inを「送信された返信」指標に使用すると、選択した期間内にチームメンバーが顧客に送信した返信が表示されます。アクションIDをクリックすると、送信された特定のメッセージをプレビューできます。

CSV（カンマ区切り値）エクスポートでは、ユーザーが複数の会社に所属している場合、すべての会社の値が1つのセルにカンマで区切ってエクスポートされます。

New conversations指標とConversationsデータセットのエクスポートには、顧客が返信しなかったアウトバウンドメッセージを含むすべての会話が含まれます。他の指標（初回応答時間、解決率、CSATなど）は少なくとも1回の顧客メッセージが必要で、返信なしの会話はカウントされません。

Intercomは応答時間を測定するさまざまな指標を提供します。このセクションでは、主な2つの初回応答時間（FRT）指標、営業時間の影響、使用する指標のカスタマイズ方法を説明します。これらの指標には平均初回応答時間や中央値初回応答時間などがあります。

営業時間：Intercomは応答時間を計算する際にチームの定義した営業時間を尊重します。

固定表示時間：場合によっては、応答時間が丸められたり一貫した形式で表示されたりすることがあります。例えば：

営業時間外の時間を除外せずに応答時間を追跡して、より広い視点を得るには：

Intercomでは、応答時間の計算からbotを除外して人間のやり取りを強調できます。

「Teammate assignment to first response」指標は、会話の割り当てから割り当てられたチームメンバーの最初の応答までの経過時間を追跡します。「Snoozed」や「Closed」などのステータス中の時間も含まれ、会話中に複数回割り当てがあった場合は変動があります。

中央値初回応答時間は、データ更新の遅延や日終わりの処理により夜間にわずかに変動することがあります。新しい会話が営業時間外に処理されると指標が再計算され、誤りではなく微調整が行われます。

チームのinbox間でticketを移動したり、ステータスを「Submitted」から「In Progress」に変更しても、初回応答時間はリセットされません。SLA設定により一時停止されない限り、最初のチームメンバーの返信が記録されるまでタイマーは継続します。

FRTは、Team currently assignedフィルターを使用すると、現在会話に割り当てられているチームに帰属します。初回返信を実際に送信したチームに指標を帰属させるには、Team assigned at the time of first responseフィルターを使用する必要があります。

FRT指標は、営業時間中の稼働時間のみを反映し、チームが「不在」の間に経過した時間は合計から除外されます。例えば、「2日」の応答時間は、カレンダー時間より長くても48時間の稼働時間を意味します。

bot関連の遅延を除外するには、「Teammate assignment to first response」指標を使用して、チームメンバーが対応を開始した後の経過時間のみを測定します。もう1つの方法は、「FRT—bot inbox excluded」指標を使って人間のパフォーマンスに集中することです。

FRTの計算は、スレッドが再開されたときに会話の元の開始時間に結びついたままです。古いスレッドを再開すると元のタイムスタンプが引き継がれるため、FRTが大幅に膨らみます。新しい問い合わせには新しいスレッドを開始し、レポートの正確性を保つべきです。

割り当て後の速度を測定する最適な指標はTeammate assignment to first responseです。これは顧客が一般キューで待機した時間やボットとのやり取りを無視します。