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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

はい、会話がない場合、合計集計は0として返されます。

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

いいえ、現時点ではドーナツチャートのみが表示中の属性に対して「その他」グループを表示することをサポートしています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

チームinboxに入ったconversationsは自動的に個々の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は異なるレベルで適用されるフィルターを使用しており、レポートレベルとチャートレベルのフィルターの違いを理解することが重要です。

解決策：

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

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

一般的なシナリオ：

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

解決策：

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

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

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

解決策：

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

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

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

解決策：

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

Intercom Reportsを最適化するには：

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

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

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

会話のマージはConversations replied toのカウントを減らしません。

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

カウントが減った場合は、マージではなく永久削除が原因です。会話が永久削除されると、その会話と返信記録は報告データセットから削除され、該当期間のカウントが減少します。

Intercomの報告では、「Conversations replied to」と「Replies sent」はチームメイトの活動の異なる側面を測定します。以下の表は各指標がどのようにインタラクションをカウントするかを比較しています：

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

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

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

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

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

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

会話の多くが自動化でクローズされている場合、「Time to close」のカウントは総クローズ数よりかなり少なくなります。すべてのクローズを測るにはTime to close (including automation)を使い、Last closed byで人間と自動の割合を分けてください。

Intercomにはライブ統計用のDisplay Unitを直接設定する方法はありません。ただし、外部の画面共有を使い、Real-Time DashboardやOverview Reportなどの報告ページを表示して、エージェントのパフォーマンスと全体のパフォーマンスを毎日紹介できます。

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

はい！すべてのカスタマー向け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設定により一時停止されない限り、最初のチームメンバーの返信が記録されるまでタイマーは継続します。

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

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

Teammate assignment to first response指標を使うと、チームメンバーが対応を引き継いだ後の経過時間のみを測定し、bot関連の遅延を除外できます。もう1つの方法は、FRT—bot inbox excluded指標を使い、人間のパフォーマンスに絞ることです。

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

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