Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    452 Ideas

    Ed MorrellNew Participant

    Preserve and restore conversation ownership after Fin AI Agent involvementSubmitted

    When a human agent takes ownership of a case, particularly for complex, multi-step issues like repair bookings or courier collections, and Fin subsequently handles part of that conversation (e.g. answering a status update, running a procedure), there is currently no native way to automatically return the conversation to the original owning agent once Fin's involvement ends or escalates. Our agents handle cases that span multiple touchpoints. An agent may book a scooter collection or repair, making them the case owner with full context. If the customer later contacts us again, Fin may handle the interaction but when Fin escalates or the conversation needs human attention again, it lands in an unassigned team queue. The original agent loses the case unless they find it or it gets manually reassigned to them. The only current workarounds I can think of:Agent name tags + a workflow branch per agent (brittle, requires maintenance as the team changes) Creating a new custom attribute (however, we've exhausted our attribute allowance on reporting-critical fields)None of these are clean solutions, they all require ongoing manual maintenance or sacrifice something else.The ask: A native "Case Owner" concept at the conversation level, separate from the current assignee, that: Can be set by an agent when they take ownership of a case Is preserved throughout Fin's involvement in the conversation Automatically reassigns the conversation back to the case owner when Fin escalates, hands off, or the conversation leaves the bot inbox Alternatively, a workflow trigger condition of "previous human assignee" that can be used to route conversations back to whoever held the conversation before Fin took over. As teams adopt Fin more deeply particularly on email channels where conversations reopen and span days or weeks, case continuity becomes critical. Fin is excellent at triaging and answering, but the handoff back to a human needs to be intelligent, not just "drop it in the team queue." This feature would allow teams to confidently expand Fin's scope without sacrificing the accountability and context that comes with named case ownership. This would affect any teams using Fin on email or async channels with multi-touchpoint cases, repairs, logistics, complaints, or anything requiring follow-up over time. ThanksEd

    Thales LopesNew Participant

    Improvement Suggestion — Adding Sector as a Criterion for Audience RulesSubmitted

    I’d like to report a potential improvement regarding the Audience configuration.Recently, we expanded the operation to other products. Given this scenario, managing the materials now requires more robust audience rules to prevent content related to other products from being incorrectly used in ERP support interactions, and vice versa.After reviewing the current Audience configuration, I noticed that it is not yet possible to use the Sector attributes we created for chat classification as a rule criterion. These attributes are currently essential for correctly routing each interaction to the appropriate Fin configuration and, consequently, to the support team responsible for the respective product.If we could use Sector as a condition in Audience rules, we would be able to segment customers and materials more precisely according to each product. In addition, this configuration would make future maintenance and adjustments much easier, as we could focus corrections and improvements on each sector's specific prompt, without having to revise broader audience rules.Given this need, we would like to request the addition of Sector as an available criterion when creating Audience rules. We believe this improvement would help ensure more accurate material segmentation, prevent inappropriate content from being used across different products, and make it easier to manage and continuously improve Fin.

    Judy CorreiaNew Participant

    Recommendation Audit or CategorisationSubmitted

    Currently Fin Recommendations (content gaps, data gaps and action gaps) only have two options - reject or mark as done/approve. Rejecting removes the recommentation and stops Fin from suggesting it again in the future. In our case this is limiting as a recommendation (in particular or data and action gaps) may not be technically possible today, but as technology changes the recommendation may make sense at some future time. It would be amazing if recommendations had a option for a “soft rejection” where it may be rejected now but we’d like Fin to make the recommendation again (if warranted) at some future time, someting like “remind me again in X months”It would also be great if: there were an audit trail, where we could see what recommendations were accepted and rejected. In addition to an audit, being able to specify reason for rejection, this would help with identifying the recommendations that may not make sense today but could in the future. Currently to overcome this limitation in auditability and tracking we need to keep a running list of recommendations in a spreadsheet, noting the recommendation, when it was suggested and the reason for rejection and review it regularly to see what might be feasbile today that perhpas wasn’t a few months ago. This adds extra overhead to our process and means having to bounce between applications vs having one source of truth within Fin. 

    Matej Bosnjak
    Matej BosnjakConnector

    Feature Request: Folder / Collection Structure for Intercom Audiences (Segments)Submitted

    Hi everyone!  SummaryWe are building a structured segmentation system covering 8 countries × 6 license tiers × up to 7 roles per tier, plus driver, EMS, and product-specific sub-segments. This will result in 150–200+ audience segments in Intercom.At this scale, the flat list view of the Segments section becomes unmanageable. We are requesting a folder or collection structure for audience segments to enable organised navigation and team usability.Problem Intercom Segments currently exist in a single flat list with no grouping or hierarchy. With 150–200+ segments, finding the right audience requires scrolling or searching every time. There is no way to visually distinguish between segment types (e.g. country-based CPO segments vs. driver segments vs. product segments). This makes it difficult for support agents, Fin AI configuration owners, and CS managers to confidently navigate, audit, or update the correct segment. Onboarding new team members to the segmentation system becomes significantly harder without clear visual structure. Requested FeatureIntroduce folders or collections for the Segments section, allowing users to: Create named folders (e.g. 🇩🇪 Germany, 🇧🇪 Belgium, Business, Pro, Enterprise) Assign segments to folders — either at creation or via drag-and-drop / bulk assignment Expand / collapse folders in the sidebar or segment list view Nest segments logically without changing their underlying rules or behaviour Example StructureCopy📁 Germany (DEU) ├── DEU — Pro — Fleet Admin ├── DEU — Pro — Fleet Manager ├── DEU — Business — Finance Manager └── ...📁 Belgium (BEL) ├── BEL — Pro — Fleet Admin └── ...📁 Drivers ├── CC@home — Driver — Manual ├── CC@home — Driver — Automatic └── Reg. driver — no platform access📁 EMS ├── EMS — Dynamic (System Users) └── EMS — Static (Drivers)📁 Legacy (Wind-down) ├── All — Basic └── All — CompactImpact Area Current With Folders Segment navigation Scroll through 150+ flat entries Expand relevant folder, find segment instantly Fin AI configuration Error-prone — easy to select wrong segment Clear grouping reduces misconfiguration risk Team onboarding Requires tribal knowledge Self-explanatory structure Segment auditing Manual scan of full list Folder-level review Priority / Urgency We are actively building this segmentation system now and will reach 150+ segments within the next quarter. Without folder support, we may need to delay segment creation or work around the limitation with inconsistent naming conventions alone. This feature would benefit any Intercom customer operating at scale across multiple regions, products, or customer types. Workaround Currently UsedStrict naming conventions ({COUNTRY} — {Plan} — {Role}) allow alphabetical sorting to group segments loosely by country. However, this does not solve the navigation problem for cross-cutting segment types (drivers, EMS, product-specific) and is not intuitive for new team members.Additional Notes We would also welcome a search/filter bar within the Segments list as a lighter alternative or complement. A tagging system for segments (similar to Intercom tags on conversations) could achieve a similar result and may be simpler to implement.