1. The Problem:
Currently, when an inbound email contains an attachment that Intercom rejects (due to size limits, unsupported file types, etc.), the system leaves a generic note in the conversation stream: "Attachments were dropped from this message." Because there is no context regarding what was dropped, support agents are forced to reply to the user and ask them to clarify what file they were trying to send. This creates unnecessary back-and-forth, delays resolution times, and creates a frustrating experience for both the agent and the customer.
2. Proposed Solution:
Update the "Attachments were dropped" event log to include the basic metadata of the dropped file.
Example of current state:
📎 Attachments were dropped from this message
Example of desired state:
📎 Attachments were dropped from this message:
Feature_Request_Bribe_v2.pdf (6.7 MB)
Definitely_Not_A_Virus_Jared.zip (4.2 MB)
Please_Build_This_Jared.png (2.2 MB)
image001.png (45 KB)
3. Why this matters (Business Impact):
Context: Agents instantly know if the dropped file was a crucial document (like a PDF checklist) or just a harmless email signature image.
Efficiency: Eliminates the need to ask the customer "What did you attach?"
Customer Experience: Customers don't feel like their files disappeared into a black hole without explanation.
4. Technical Feasibility:
Since Intercom's backend already receives the Multipart MIME message and parses the headers (Content-Disposition, Content-Type, etc.) to evaluate whether to keep or drop the payload, this metadata is already being temporarily held in memory. Writing these specific header values to the conversation event log before purging the file data should be a highly feasible, low-lift addition that provides massive value to support teams.