Share product ideas and upvotes with our product team
Currently, participation includes notes and replies. If an agent is involved in a phone call, that is not counted as participation, but should be.
The current teammate profiles (admin profiles) are fairly basic and do allow for an editable text field for a fun quote.The idea we are putting forward is to allow for custom attributes (fields) to be able to be created for teammate profiles, these could be use to list teammates professional certifications for instance.One or two extra fields that could be either lists or multi line text would be a great start.
ProblemFin handles chat well — short turns, fast iteration, low downside if a reply needs a follow-up. Email is a different beast. Threads are longer, context spans days or weeks, and the stakes are higher: customers expect a considered, accurate response, and a wrong reply is much harder to walk back than in a live chat.That makes full autonomy a poor fit for most email conversations. But it doesn't mean Fin can't help. Right now, the gap between "Fin resolves it autonomously" and "agent writes from scratch" is too wide for email — there's nothing in between.ProposalWhen a new email arrives, Fin generates a draft reply using:- The full thread context- Connected knowledge sources (help center, macros, past resolved threads)- Brand voice and tone settings already configured for FinThe draft sits in the conversation ready for an agent to review, edit, or send. A confidence indicator and visible source citations would let agents verify in seconds rather than re-researching the answer.Why this is valuable- Cuts response time without giving up the human-in-the-loop check that email genuinely needs.- Captures Fin's value on conversations that today are 100% manual.- Creates a feedback loop: agent edits become signal for improving future drafts, and eventually for moving simpler email categories toward autonomous resolution.Use caseWe run a marketplace where most supplier-side conversations happen over email. They're rarely fully automatable, but most of what we write is a variation of something we've written before. A Fin draft would save the majority of the writing time per reply while keeping us in control of what actually ships.
Right now, seat removal can only be done in the UI. I’d like an API endpoint (PUT /admins/{id} or similar) that lets us revoke a teammate’s seat programmatically.We want to manage those that do not login or use Intercom for more than 30 days programmatically. We found we can find those via the API, but we can’t remove the seat.We need the API updated.
When an email is forwarded from another department which isn’t using Intercom, their internal email needs to be removed so that clients can’t see it.At present it is possible to select the existing trail in the reply box and delete the entire trail, but this means that the trail is lost for the response being sent and therefore there is no context for the response.A workaround is to then copy and paste the part of the trail you do want, but these can often be very long, and it will also end up putting your email signature right at the end of what you have pasted instead of after the most recent response.We would simply like to be able to highlight and delete the last response like you can in Outlook or Freshdesk in case it is an internal email which we would not want to be included to the client.
As the Manager of the Customer Onboarding team, we heavily rely on sandbox environments for customer enablement. Ideally, I’d be able to have tooltips that I can set to be persistent beyond the initial interaction so users can go back and review them as they’re learning the software platform.
Currently we can use our phonenumber only on Intercom. But Intercom is limited in using this number and sending messages there. It is not even possible to use Intercoms API to send a transactional mail programmatically. It would be nice, if we could send transcactional mails with our own system through the WhatssApp Cloud API and then also connect Intercom to the same WhatsAPp Cloud API.
Currently within the Let Fin Handle boxes there is the option to Follow up with inactive email customers. But we don’t have a way to fine tune which interactions Fin should follow up with. As an example, if a customer has had a conversation with Fin where all the possible options have been exhausted and the customer has stopped replying, we want to give Fin guidance to not reply if there is a specific conversation topic (attribute) that has been detected. We want Fin to be able to send the follow up as needed, but want to be able to give Fin some instruction to NOT follow up based on a topic, or guidance. At the moment it is either on or off.
The Problem:Currently, all custom away reasons are visible to every teammate workspace-wide. This creates unnecessary noise for departments with different workflows.The Request:Add a setting to restrict specific away reasons to certain Team Inboxes or Roles.This will: Reduce Clutter: Agents only see statuses relevant to their role. Improve Accuracy: Prevents teammates from selecting irrelevant statuses by mistake.
As many people have a lot of SLA’s for each workflow and product, could there potentially be a way that we can create some sort of way to add an edit function to go with these as SLA’s are always changing and having to delete them entirely to amend each change can be a nightmare. I feel this would save a lot of time and extra things if it could be possible to do.
Feature Request: Extend URL Security Signing Window (30 to 60 Mins)The ProblemThe current 30-minute security signing window is too short for large API data transfers and complex transcriptions. This leads to transcription loss when the signature expires before the process finishes.The SolutionIncrease the maximum URL security signing window to 60 minutes.Security & Infrastructure FAQGDPR/SOC2: A 60-minute window remains a "short-lived" credential. It does not alter encryption standards or data privacy controls.GCS/S3 Compatibility: Standard cloud providers (like AWS) easily support pre-signed URLs for much longer durations; this is a minor configuration change with zero infrastructure risk.Risk: The URLs remain temporary and on-demand, providing necessary "headroom" for data without increasing the attack surface.The BenefitThis change ensures data integrity for high-volume users and enterprise integrations.Are you also hitting the 30-minute limit? Upvote to let the team know!
The Problem: Currently, setting up Fin Data Connectors is a high-friction process. For every action we want Fin to take, we have to manually: Create a new Connector. Define the endpoint. Manually map and explain each data attribute so Fin understands it. This significantly increases the "Time to Value" for Fin. If I have a complex B2B API with 50 endpoints, it takes days to set up, rather than minutes. ⏳ The Solution: Introduce a "Bulk API Mapping" feature. Instead of manual entry, allow us to provide a URL to our API Documentation (or upload an OpenAPI/Swagger JSON/YAML file) and the Global Authorization headers.How it would work: Doc Ingestion: Fin "reads" the documentation and automatically maps the available endpoints. Semantic Understanding: Since modern API docs are well-designed, Fin can use its native LLM capabilities to understand what each endpoint does without us writing a manual "explanation" for every single one. Global Auth: Set authorization once at the root level rather than per-connector. Selective Enabling: A simple toggle list where we can "Turn On" specific endpoints for Fin to use as Tools. Why this is a game-changer: ⚡️ Drastically Reduce Start Time: We could go from "Zero to Integrated" in minutes, not days. 📈 Scale Automation: It encourages teams to give Fin more "powers" because the cost of adding a new capability is nearly zero. 🛠 Improved Accuracy: Professional API documentation is often clearer than a human's manual summary, leading to fewer hallucinations during tool calls. Let’s move Fin from a "manual data connector" model to a "plug-and-play architect" model! 🇬🇧💪#IntercomFin #ProductFeedback #FeatureRequest
Hi Intercom team,I’d like to request an improvement around how mentions behave across back-office tickets and cross-noted conversations.Currently, when a back-office ticket includes a mention that is also cross-noted into a conversation assigned to me, I end up handling the same item twice: First when I open and respond to the conversation Then again when reviewing my mentions in back-office tickets This creates duplicate work and forces agents to manually reconcile two separate workflows for the same task, which becomes increasingly inefficient at higher ticket volumes.This occurs repeatedly throughout the day when handling cross-noted tickets and adds noticeable overhead to agent workflowsSuggested improvement:Automatically mark a mention as “seen” in the back-office ticket when the linked conversation has already been viewed or responded to by the assigned agent.Ideally, this behavior could be configurable to support different team workflows.Impact: Eliminates duplicate handling of the same task across conversations and tickets Reduces cognitive load when clearing mentions Improves workflow efficiency for teams managing high volumes of cross-noted tickets Happy to provide specific examples or workflows if helpful.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.