Skip to main content

    Filter by idea status

    Filter by product

    1293 Ideas

    Triage 2.0 Analytics Improvement1. New

    TLDR: would like to see Triage logs posted in Analytics in real time, not 24hrs after, as well as a data section that clarifies “how many tickets were triaged by the model” vs “how many tickets that match the query have been filed”.hi all, we recently enabled Triage 2.0 (3 days ago) and we were excited to see the feature working and get more information as we’ve been planning this launch for quite some time. after launch, we found that one of our query params was incorrect and had to adjust that but we were unable to do that until a full day after launch because logs for Triage in Analytics have a 24hr delay...we then had to wait another 24hrs to see if our change to the query worked. this honestly is a big pain point at launch, and i can see it continuing to be a pain point as we work with our support agents to discover answers when they ask why some tickets were triaged and others weren’t, or during our own research as to how the model is progressing in active training. additionally, i can’t see a way in the analytics module to get a holistic view of how many tickets Triage is handling versus total number of tickets filed (that match the Triage query). we launched with a 90% coverage/~68% precision range and one of leadership’s key questions is: is it actually holding up to that range after we launch? obviously these aren’t questions that can be answered on launch day, but having access to real time data and being able to deliver key information within the first few weeks of launch would exponentially increase trust instilled.i found this discussion from a year ago, and i imagine some of the data that is shown in the current dashboard is different than what Priya was seeing at that time, but couldn’t find many other mentions of Triage logs in the community. please link me if i’ve missed something! 

    priya.kornalius
    priya.kornaliusKnown Participant

    Customizing Okta Password Reset Verbiage for Better Clarity1. New

    We're currently using the “Account Access” skill for handling password reset requests. When users ask the bot to reset their Okta password, the bot follows this flow:Creates a support ticket Generates a password reset link Automatically closes the ticket without adding any comments to the ticketIn the chat, users receive a message like:“The password change process has been completed and the related ticket (Ticket ID) is now closed. If you have any further questions or need additional help, please let me know!”This message has caused confusion among our end users, especially if they haven't yet clicked the reset link or encounter issues with it. Some users have raised concerns about the ticket being closed prematurely, believing their issue remains unresolved.To help improve clarity, we’d like the ability to customize this verbiage from the MW admin page.Here’s our suggested version:“I've generated the password reset link. Please click the link to reset your Okta password. Since my action is complete, I’m proceeding to resolve this ticket (Ticket ID). Feel free to reopen the same ticket for further assistance on your request.”The above response should reflect in the ticket comments before the bot changes the status to “Resolved”.This small change could go a long way in setting the right expectations and reducing user confusion.Would love to hear if this is on the roadmap or if others are facing a similar challenge.

    aravirajEmployee

    Personal instructions / profile1. New

    Idea: Allow the end user to provide custom instructions to the bot (i.e. make short answers, be funny, etc.), whatever they want, or describe its persona. The key point is that those instructions are systematically and automatically added to every single interaction with the bot so that it supports user preferences.  Sharing a few examples. below. ***IT EngineerI am an IT engineer using macOS. Assume I have technical knowledge and prefer precise, detailed answers. Prioritize command-line instructions, configuration-level fixes, and relevant logs or diagnostics. I use Docker, SSH, terminal, and common scripting languages. Avoid oversimplified answers. Non-Technical EmployeeI’m a business user with limited technical knowledge. I use Windows and mainly work with Office 365, Teams, and SharePoint. Please explain things simply, avoid jargon, and provide step-by-step instructions with screenshots or links when possible. VIP or Executive (e.g., CEO)I’m an executive user. Prioritize fast resolution and minimal friction. Avoid technical explanations unless necessary. When offering options, suggest the fastest and most reliable one. Flag requests that may need special handling or elevated support. Creative Role (e.g., Designer)I’m a designer using macOS with Adobe Creative Cloud. I’m comfortable with Mac but not with terminal commands. Focus on UI/UX troubleshooting, file handling, and app compatibility. Avoid CLI instructions unless GUI options are unavailable. Data Scientist / AnalystI’m a data scientist using Python, Jupyter, and Docker on Windows with WSL2. Assume familiarity with technical tools and code. I prefer efficient, direct answers with config examples or commands. Provide links to technical docs when available.

    Jared
    JaredInspiring

    Proposal for Improving External Knowledge Feature Flexibility and Article Management1. New

     I would like to propose an enhancement to the External Knowledge (EK) feature, specifically concerning the management and exclusion of articles from the entities offered within our support bot framework.Current Challenge:The integration of external articles from entities such as Asana, Slack, 1Password, among others, is invaluable. However, we face challenges in maintaining a curated selection of content due to the platform's approach to entity article inclusions, which automatically includes all articles from selected entities. This often leads to the inclusion of irrelevant content, overwhelming users with articles not applicable to most (e.g., articles relating to changing global permissions or features not available to most users).Furthermore, we have encountered an exclusion limit that restricts the percentage of articles we can exclude. This limitation does not consider the relevance of entities to our operational environment, resulting in the inclusion of content from tools not utilized by our company. We estimate that only about 50-60% of the articles for each entity would add value to the majority of our employee base.Proposed Solution:To address these issues, we propose the following enhancements:Enhanced Exclusion Flexibility: Modify (or remove!) the exclusion limit to allow a greater degree of control over which articles and entities are included or excluded, based on their relevance. This could include a nuanced approach to exclusions that doesn't penalize organizations for fully excluding irrelevant entities. Persistent Curation: Ensure that manually curated selections of included articles for specific entities are maintained and do not automatically revert to including all available content. Relevance-Based Inclusion Criteria: Introduce a feature that allows organizations to set criteria for relevance, automatically filtering out articles and entities that do not meet these predefined standards. This could include sub-categorizing features (e.g., Admin features) to enable swift exclusion of all admin-feature-related articles.Value Proposition:Implementing these changes would significantly enhance the usability and effectiveness of the EK feature for our company and potentially other clients. By providing more relevant, curated content, we aim to improve the efficiency of information retrieval for our users, reduce information overload, and increase overall satisfaction with our support bot.