Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3482 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.