Reporting

Hi Community 👋We’re currently doing a large cleanup of our Intercom workspace — workflows, macros, tags, attributes, reports, roles, permissions, etc. — and we’ve run into a major limitation regarding report access for Admins.Even as Workspace Admins, we cannot see, edit, or delete all reports. Access is limited to only those reports explicitly shared with us. This creates challenges when trying to maintain workspace. For example, if we want to remove or archive a tag or attribute, Intercom blocks the action if it’s used in a report we don’t have access to. That forces us to track down the report owner, request full access, and wait for them to respond — which can take days.The situation becomes even more complicated when report owners are on maternity/paternity leave or long-term leave. Support has informed us that they cannot delete these reports on our behalf, leaving us effectively blocked from cleaning up parts of the workspace.We ac

Hi,Could someone help me confirm whether I’m using the Intercom report correctly?For one of our clients, we need to generate a weekly report and track ticket follow-ups. Currently, the report only includes tickets that were created during that specific week. However, if I’m waiting for a customer’s response and the conversation is closed the following week, it doesn’t appear in the report.Is there a way to include these tickets in the follow-up, or am I missing a setting in the report?Any guidance would be greatly appreciated 😊Thank you!

Turns out a “Company” filter doesn’t work in any of the SLA reports. Leaving you with no way to see the team’s performance for any of your clients. Or any other company related info, such as attributes.I’m surprised a basic report is missing and was wondering if anyone has figured out a way to solve this.

I’d like to see questions my teammates asked Copilot that it wasn’t able to find answers for. Why is this not available in reporting? Visibility on unanswered questions seems like a simple way to identify gaps in our knowledge and content.

 Issue DescriptionWe're experiencing signal handler conflicts between Firebase Crashlytics and Intercom SDK in our app. During app initialization, we see multiple warnings in the console:[Crashlytics] The signal SIGABRT has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.[Crashlytics] The signal SIGBUS has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.[Crashlytics] The signal SIGFPE has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.[Crashlytics] The signal SIGILL has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.[Crashlytics] The signal SIGSEGV has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.[Crashlytics] The signal SIGSYS has a non-Cra

Hi everyone,My team is trying to refine our reporting, and we’re running into an issue where our "First Response Time" metrics are being skewed.We are trying to measure the speed of our agents picking up a chat specifically after Fin hands it off.However, we often have scenarios where Fin closes a chat without human interaction. Then, a few days later, we might manually check in on that user or follow up on the closed conversation. Currently, the reporting counts those intervening days as "wait time," which makes our response metrics look inaccurate (showing 2+ day response times for chats that were actually closed).Does anyone have a workaround or a specific filter setup that isolates "Active Fin Hand-offs" vs. "Manual Follow-ups on Closed Chats"? We want to see how fast we are responding to immediate needs, without the data being dragged down by our sporadic follow-ups.Thanks in advance!

Could you share your KPIs and what works best for you when using AI support together with human support? I’ve read a lot of articles, but I’m still not sure what works best in practice. I’d love to hear what you’re using! 😍

We are currently reviewing and updating Custom Ticket and Conversation attributes; however, have hit a roadblock when trying to archive unused attributes with inaccurate / outdated data as multiple custom attributes are linked to private reports that individual users have created over time.Unnecessary gatekeeping has resulted in me having to chase over a dozen individuals to either update or provide me with access to their private reports before I can archive these attributes.This poses a great risk as during the time it takes to reach out and wait for colleagues across a global org to assist, we have old, outdated data live in reports, and my hands are completely tied as I cannot access or update these reports myself.Feedback from the Intercom Support Team: “… to make changes to that attribute, your teammates who own the Custom Reports will need to either update the attribute used in their reports or give you permission to access their reports. O

Hi everyone,We’re currently using Tags as our main way of classifying conversations in Intercom (e.g. product area, issue type, billing, cancellations, etc.). It’s starting to feel a bit messy and hard to report on, so we’re considering moving to a small set of Conversation Attributes instead, and using Tags only for campaigns/one-offs and stuff like that.I’m looking for advice from teams who’ve actually done this: How did you decide which things should be Attributes vs Tags? Which Attributes do you find the most useful for reporting (e.g. issue type, product area, plan tier, outcome, churn reason)? Did you make any fields mandatory before closing a conversation? If so, how many before it became annoying for agents? How did you handle the transition period? Did you backfill old conversations or just start from a certain date? We’re also using Fin and I’d love any tips on that side:

Hey folks! I’m trying to report what share (or at least total counts) of Solved conversations were closed after 1 reply, 2 replies, and ≥3 replies for a given date range. What’s the exact Intercom chart setup to do this?What I’ve tried:Replies to close a conversation with Median/Average/Sum. Workable but without counts option, it is difficult to reach the actual percentage of solved conversations based on the number of replies used. Closed on first contact rate. I believe this measures “one teammate replied,” not “closed in 1 reply.” so, not really something to rely on.Could someone share any finding, insights or experience calculating this? Or suggest the best workaround.Thanks!

Does anyone have a solid work around to export reports, including all the charts, as they appear in Intercom? I'd like to share these with internal stakeholders who don't have access to Intercom.Currently, only function is to download the underline data or screenshot the report 😅 - where is I really just want to send the report to stakeholders.

I know the default survey uses emojis with hover-over text labels, but it seems like our customers might not be understanding the difference between each rating (see attached image). It’s starting to impact our metrics a bit.I’d really like to keep using Intercom’s native CSAT tool for reporting and widgets, but I’m wondering: Is there any way to customize the default emoji options (e.g., swap them out or show the text labels instead)? Or do we know if there’s already a product request or feature idea out there for that? Also related question, is it possible to tweak how CSAT is calculated in our instance? For example, could we have “OK” responses count as positive? A lot of our users are parents or older family members, and based on some past examples, “OK” seems to represent a satisfied response rather than a neutral or negative one.

We’re hoping to gain insight into how other customers are forecasting handle time, particularly when using Intercom data. We've noticed discrepancies in the handle time metrics reported by Intercom that don’t align with the structure of our operations.Typically, I export the raw data and filter out outliers manually. However, we continue to see a significant number of conversations with unusually long handle times that lack a clear explanation. This inconsistency makes it difficult to trust the accuracy of the reports.We’re looking for a better approach—either a clearer understanding of how Intercom calculates handle time behind the scenes, or alternative methods for forecasting handle time more reliably using Intercom data.Thank you in advance for any guidance or shared experiences!

Hello there!I’m looking for a to conduct quality assurance on the back-office ticket submission process and track the responsible parties for each ticket. Is there a way to generate a report that captures that info? Currently, we have a boolean attribute that we can toggle, however, we can’t filter through it by the person who submitted it. Any help is greatly appreciated! 

Hello, We need to calculate total duration for which conversations are snoozed for analytical purposes. I went through the community forum and found this In the above topic, it’s mentioned that their isn't a direct method provided for generating a report specifically for snooze time in conversations.Although we have found out that we can derive snooze durations and it would be helpful if we can get a review from the Intercom community over this method, or if we can get some other attributes or methods (provided by the Intercom API) through which we can calculate snooze durations, this would be extremely useful for us.We are aiming to derive the snooze duration based on the following:Calculate snooze time by tracking conversation state transitions through conversation parts, which provide the most granular state information for each conversation.

I have discoverd instances in conversation_parts where the conversation_part.status is in a snooze state even if the part_type is a comment type. How is this possible, because according to this article (https://www.intercom.com/help/en/articles/6564538-snooze-a-conversation) “If you send a reply message in a 'snoozed' conversation that's assigned to you, it will not automatically 'unsnooze'/reopen the conversation.”“If someone else sends a reply, adds a note, or updates an attribute in a 'snoozed' conversation assigned to you, it will be automatically 'unsnoozed'/reopened.” So How come a conversation remain in an snoozed state even after there is a comment from either admin or customer?A comment part type is defined as: Standard reply from customer or admin to a conversation (

Hi all! Support team leaders, I’d love to know -What metric from reporting in Intercom do you use to inform a goal for your team monthly?Number of tickets closed? Number of tickets assigned? Number of replies sent? Or something else? I’m trying to zone in on how many tickets my support team members are handling individually each week.  Thanks!

I’m returning to Intercom after a long break, and I could use some advice from folks who’ve set up recent workflows.It looks like every customer interaction starts as a Conversation. And if it takes longer to resolve or needs extra structure, it can be turned into a Ticket. That all makes sense.But I’m trying to set things up in a way that keeps reporting clean and consistent.My goals:I want to capture the same core metadata for every interaction (things like feature area, source, etc.) I don’t want to double-count anything when pulling metrics I want to avoid having agents fill in fields twice, or inconsistently across conversations and ticketsMy questions:Do you only use tickets for escalations, or convert everything? Can you safely report on Conversations only, and still get reliable counts and resolution metrics? Are you adding custom fields to Conversations for universal stuff, and usi

https://www.intercom.com/help/en/articles/5652381-conversational-support-report#h_c98526bc52Self Serve, Human & Proactive Support.  I am familiar with conversation ID’s, what are the other identifiers that make up Self Serve, Human & Proactive Support.   What differentiates them in the data?  I can’t seem to find a list of identifiers that would feed into those reports.

I know that you do not currently offer Automated reporting that users can subscribe to other than setting up the dataset exports to send daily.  Do you plan to add subscriptions for REPORTS so that we can receive them to our email?

One of the report metrics is to look at time spent on a ticket, and currently the available units are hours, days, years, but I really need the option of minutes. Can this be added or enabled?

Hey everyone,I’ve been looking into ways to improve user onboarding and updates for a little side project of mine. It’s a desktop launcher bloxstrap and I’m curious if Intercom could be useful in this setup.Couple things I’m wondering:Is it possible to trigger onboarding/help messages inside a desktop app, or is Intercom mainly limited to web and mobile?Would using Intercom’s email campaigns be the better route for sharing updates / new release notes with users?Has anyone here tried hooking Intercom into a custom software download flow?I’m not sure if Intercom is flexible enough for this kind of product, but it seems like it could be a nice way to keep people engaged without building everything from scratch.Appreciate any tips or experiences!

I'm setting a report filter by company tag. I've noticed when a conversation's primary contact (source.author) isn't connected to a company with that tag but another participant is, the conversation isn't populating on the report. How do I ensure this conversation or ticket will populate on the report for participating contacts with that company tag?

Device: Nexus 5XOS Version: Android 13App Version: 2.0.19 (82)Date: August 22, 2025, 15:22:48 GMT+03:00Issue Description:Our Flutter application is experiencing a ForegroundServiceDidNotStartInTimeException on Android 13 devices when using both Firebase Messaging and Intercom. This error specifically occurs when the Firebase Messaging background service (FlutterFirebaseMessagingBackgroundService) is initiated.Android expects a foreground service to call Service.startForeground() within 5 seconds after Context.startForegroundService() is invoked. In our case, this timeout is occurring, leading to an application crash.Key Detail from Logs:Upon reviewing the crash logs, a significant detail observed is the activity on a thread named DefaultDispatcher-worker-3, which is related to the Intercom SDK. This thread shows operations involvi

We would like to request a new data point in the reports section for tickets: "Last Comment”.