Skip to main content

    Filter by idea status

    Filter by product

    1344 Ideas

    nicole.hulst
    nicole.hulstKnown Participant

    Multiple Triage Models and integration of Triage with Agents from Agent Studio1. New

    We were having high hopes and expectations for Triage 2.0 to help us in reducing manual routing efforts to an absolute minimum. What we have found that Triage works exceptionally well in highly specialized cases where we have a high ticket volume. But this is not scalable. We can either have really good Triage for one Service or really crappy Triage for all our Services. What we obviously want is good to really good Triage for all Services to actually reduce our workload instead of just shifting it to second or third level support. The good results of the specialized models need to be scalable for enterprise wide useTo solve this issue what we require is the possibility to define multiple Models or Indices that run for different groups of Tickets. Ideally we could even have multiple Triage Runs on the same tickets. I envision something like: General Triage runs through all incoming tickets and identifies based on the description the right Service and routes to the respective Service Offering Depending on the Service Offering selected a new model is triggered for Triage for that specific Service and potentially take into consideration more fields than just description to route to the accurate second level group. Meaning we would have multiple models for the different services all specialized in the specifics of each service On a second Triage run also outside information should be taken into consideration such as work instructions for SD Agents that already contain explanations on routing accurately etc. Lastly if Triage cannot identify any further routing but the Ticket still needs automated actions we want to be able to trigger AI Agents to work on the ticket, but that trigger should come from Triage so there is no interference.  

    nicole.hulst
    nicole.hulstKnown Participant

    Multiple Triage Models and integration of Triage with Agents from Agent Studio1. New

    We were having high hopes and expectations for Triage 2.0 to help us in reducing manual routing efforts to an absolute minimum. What we have found that Triage works exceptionally well in highly specialized cases where we have a high ticket volume. But this is not scalable. We can either have really good Triage for one Service or really crappy Triage for all our Services. What we obviously want is good to really good Triage for all Services to actually reduce our workload instead of just shifting it to second or third level support. The good results of the specialized models need to be scalable for enterprise wide useTo solve this issue what we require is the possibility to define multiple Models or Indices that run for different groups of Tickets. Ideally we could even have multiple Triage Runs on the same tickets. I envision something like: General Triage runs through all incoming tickets and identifies based on the description the right Service and routes to the respective Service Offering Depending on the Service Offering selected a new model is triggered for Triage for that specific Service and potentially take into consideration more fields than just description to route to the accurate second level group. Meaning we would have multiple models for the different services all specialized in the specifics of each service On a second Triage run also outside information should be taken into consideration such as work instructions for SD Agents that already contain explanations on routing accurately etc. Lastly if Triage cannot identify any further routing but the Ticket still needs automated actions we want to be able to trigger AI Agents to work on the ticket, but that trigger should come from Triage so there is no interference.  

    LAWRM064New Participant

    Expired Link Handling for Employee Communications1. New

    Problem StatementEmployee Communications campaign links (both in-text URLs and button links) currently expire after 14 days. When employees attempt to access an expired link, the experience is unclear and can lead to confusion, failed journeys, support requests, and reduced engagement with important communications.Proposed SolutionIntroduce a configurable expired-link experience that detects when a campaign link has expired and presents users with a clear, user-friendly message instead of a generic error or failed landing page.Key FeaturesCustomizable expired-link messaging Clear explanation that the communication link has expired Option to redirect users to: The latest version of the communication A help/support resource Admin-configurable expiration messaging and destination URLs Reporting on expired-link clicks to identify engagement after expirationBusiness ValueImproves employee experience and reduces confusion Decreases support tickets related to inaccessible communication links Preserves engagement with important communications after campaign expiration Provides administrators with greater flexibility and visibility into post-campaign activityUse Case An employee clicks a campaign link more than 14 days after receiving a communication. Instead of encountering a broken or inaccessible experience, they receive a friendly message explaining that the link has expired and are guided to the most current content or support resource.Priority Rationale Organizations using Employee Communications rely on campaign links to distribute important information. As adoption scales, a more graceful and intuitive expired-link experience becomes increasingly important to maintain trust, usability, and communication effectiveness.