Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3157 Ideas

    Bailey SchrammNew Participant

    Improvements to CX score calculationSubmitted

    I wanted to provide some feedback on the CX score calculation to the Intercom crew and see how others have noticed a change over recent months. It seems like the CX score is something Intercom is highlighting over the traditional CSAT metric, but internally, we have some hesitancy before we switch to using it as the primary measure of support performance. Prior to November, our average CX Score was 91.7%. Lower than our historic CSAT, but close enough, and it seemed fair given that it assesses all conversations, not just those with survey responses. Somewhere between November/December, this took a sharp drop, and the new average is closer to 65%.After some digging, it seems like the score now considers a conversation where the customer leaves without responding as a score of 3 (or 0%). In theory, I understand that this is being treated like an “abandoned” chat. However, in practice, I don’t think this is indicative of a poor user experience that warrants a 0% rating. In many of these cases, I take it as the customer getting the info they need and promptly leaving the chat, not feeling the need to “close the loop” with an AI chatbot as they might with a human agent. With that, I guess I have a few follow up questions to others & the Intercom team: - Is the CX Score still under development, or is this its final state? (Important for internal benchmarking / performance tracking)- Given that it’s AI-assessed, will there be a way for us to “train” / provide Guidance for how Intercom calculates our personal CX Score (akin to Fin Guidance)?- What was the intention behind the CX Score calculation change late last year / what else changed besides the scenario I laid out above?

    msesmaConnector

    Intercom Android SDK vulnerability not fixedSubmitted

    There is a vulnerability not fixed even in latest Intercom Android SDK 17.4.2:org.msgpack:msgpack-core should be 0.9.11 or greater|    +--- io.intercom.android:intercom-sdk-base:17.4.2|    |    +--- io.ably:ably-android:1.5.0|    |    |    +--- io.ably:network-client-okhttp:1.5.0|    |    |    |    +--- io.ably:network-client-core:1.5.0|    |    |    |    \--- com.squareup.okhttp3:okhttp:4.12.0 (*)|    |    |    +--- org.msgpack:msgpack-core:0.8.11Could you please update io.ably:ably-android to latest 1.6.1 to see if it fixes the vulnerability?Thanks!More Infoorg.msgpack:msgpack-core(Maven)< 0.9.110.9.11SummaryAffected Components: org.msgpack.core.MessageUnpacker.readPayload()org.msgpack.core.MessageUnpacker.unpackValue()org.msgpack.value.ExtensionValue.getData()A denial-of-service vulnerability exists in MessagePack for Java when deserializing .msgpack files containing EXT32 objects with attacker-controlled payload lengths. While MessagePack-Java parses extension headers lazily, it later trusts the declared EXT payload length when materializing the extension data. When ExtensionValue.getData() is invoked, the library attempts to allocate a byte array of the declared length without enforcing any upper bound. A malicious .msgpack file of only a few bytes can therefore trigger unbounded heap allocation, resulting in JVM heap exhaustion, process termination, or service unavailability. This vulnerability is triggered during model loading / deserialization, making it a model format vulnerability suitable for remote exploitation.

    Pilar ApodacaNew Participant

    WhatsApp template restrictions have reduced the value of Intercom for customersSubmitted

    We chose Intercom largely because it allowed us to centralize customer communication in one place, especially through WhatsApp.For us, the value was not just sending outbound messages. The real value was being able to send a message through WhatsApp, have the customer reply in the same thread, and continue the conversation naturally inside the Intercom inbox without forcing the customer into a fragmented experience. That continuity is extremely important to our workflow and to the customer experience.With the recent changes around marketing-classified WhatsApp templates, a big part of that value has been reduced.I understand that some of the underlying limitations may come from Meta. However, from the customer side, what this feels like is that Intercom has passed the operational impact of those limitations directly onto paying customers without providing a truly workable alternative.What makes this even more frustrating is that Intercom’s WhatsApp setup is intentionally closed: the number is managed exclusively inside Intercom, so customers cannot easily adopt a hybrid setup using the same number while preserving inbox continuity. That leaves businesses like ours stuck with an all-or-nothing choice: stay in Intercom and lose important WhatsApp capabilities, or leave Intercom and lose the continuity and inbox experience we originally paid for.This is especially difficult to accept because Intercom is a premium platform. Many of us adopted it specifically for centralized communication, continuity across channels, and AI support inside the inbox. When a change like this significantly reduces flexibility in such an important channel, it becomes much harder to justify the cost.My suggestion is not simply to complain, but to ask Intercom to offer a better path forward. For example: allow more flexibility for customers who still want to use WhatsApp marketing templates at their own risk, provide a more open architecture that preserves inbox continuity, or offer a better hybrid option for teams that depend heavily on WhatsApp. At minimum, I believe changes with this level of operational impact should come with more transparency and stronger alternatives for paying customers.Right now, this feels like customers are carrying the cost of a platform decision they did not choose.