Build better products with our product team.
Overview Currently, the platform’s analytics focus on user-initiated interactions with our Moveworks bot. However, as customer bots evolve to be more proactive—sending notifications and updates without direct user prompts—we lack visibility into the reach and effectiveness of these communications. To better understand the impact of bot-initiated messages, we propose the addition of analytics for proactive communications. This would provide insights into what types of messages are being sent, how frequently, and how users are engaging with them. Proposal: Implement Analytics for Bot-Initiated Messaging We request a new analytics capability to track and analyze any communication that originates from the bot, including but not limited to:• System-generated notifications (e.g., password reset alerts)• Employee communications tool messages• Creator Studio-initiated messages• Concierge or plugin-based notifications (e.g., ITSM status updates, comments)• External integration notifications (e.g., ITSM approval workflows) Key Metrics & Capabilities Requested:1. Message Volume Tracking – How many bot-initiated messages are being sent over time?2. Message Source Breakdown – Categorization by system, integration, or trigger type.3. Recipient Insights – Who is receiving these messages? Are certain groups more (or less) engaged than others?4. Engagement Metrics – How do users interact with bot-initiated messages? (e.g., click rates, dismissals, response rates)5. Impact Measurement – Correlation between notifications and user actions (e.g., did a status change notification lead to a follow-up inquiry?). Benefits:• Visibility – Understand the scale and scope of bot-initiated communications.• Optimization – Identify which messages are effective and refine strategies accordingly.• User Experience Improvement – Reduce notification fatigue by analyzing engagement trends.• Data-Driven Decision Making – Leverage insights to enhance proactive support efforts. By implementing analytics for proactive bot messaging, we can ensure that these communications are both meaningful and effective, ultimately improving the best possible user experience and the value of the Moveworks bot.
Our engineering teams are in large approval groups, we just went live with our bot ‘Penny’ and early feedback suggests that while the proactive notifications are helpful, approval notifications can become spammy in nature. I want our users to be able to “snooze” these notifications for specific time intervals
Since Move Works is a shared instance, when implementing use cases for HR and ITSM groups, it is critical to separate underlying components (connectors, actions, plugins etc) with some kind of permission so that developers or admins have access only to their respective workspaces.This is important functionality so that non-HR users who would normally not have access to HR data are not able to execute plugins/http actions etc. or have visibility to logs/data that is tied to HR instances and potentially expose sensitive data.
We need the ability to context (or session) lock. We are migrating from a home grown solution to the moveworks platform. One nice feature we have lost is all of our custom AI bots as with the old solution we were able to use specific utterances to then enter a “chat mode” with that other bot until the user exit out (by typing in exit) or the session timed out. This way we did not have to build a bunch of different Bot Front ends, they could all come into one place. We have not found a way to do this with the moveworks platform at this time. Yes you can fire off a one shot prompt to a different bot or LLM. But any follow up questions will not have the context/history. Thoughts?
It would be very useful to include a list of users who did NOT interact with a campaign in the download reports. We’ve started to use campaigns to gather information from employees, where we consider a response mandatory. Employees who don’t interact with the campaign need more direct followup through other channels.Currently comms details only show delivery status and positive interactions, so campaign leaders have to manually infer those usernames from the difference between the total audience and the users who interacted.It seems obvious that this data should be included in campaign details, since it’s highly relevant and actionable.
In conversations related with IT Support, upon engaging in the Live Chat with an Agent, it is typical that Remote Desktop tools are used. Typically these tools require a code to be shared by the Agent with the Caller, in order to establish the remote connection. On some occasions, we’ve observed that these Codes sent by the agent are being translated on-the-fly, which then do not work and do not allow the session to be established. Requesting a product enhancement so the AI Assistant can recognize the context as being a support call and corresponding Codes for the remote session being shared, thus not translating these.Referrence to Case Number: 00031445
Peloton requests that Moveworks partner with Atlassian Jira to enable JSM Forms to be fillable in-bot. Jira has 2 types of forms. JSM Forms (dynamics forms) is the version that is currently not supported to be fillable because Jira Cloud Forms does not yet have APIs which will allow Moveworks to fill a form in the bot and submit it to create a new ticket. NOTE: This is specific for Jira cloud instances Gateway recommendation is not an acceptable alternative. Having the native integration is the desired outcome.
Currently, users are able to search based on Name, Email, Department, and Manager Name. However, enabling Role search would bring more flexibility and help users find colleagues based on their specific roles
We are approaching 100 different Plugins, Actions, Paths, etc., within our environment. As you can imagine, this is leading to a cluttered interface!It would be advantageous to find a solution for organizing these elements.One possible approach could be to implement folders for categorization by Domain and other criteria. An even more effective solution would be to integrate custom variables or categories within the plugins themselves, enabling us to sort and filter by Domain, Plugin type, and other attributes.Perhaps the Community could help brainstorm the best solution? I believe that without intervention, this situation will soon become unmanageable, and we will need a strategy to maintain a more organized environment.
When can we expect multimodal support for QuickGPT? Images, videos and graphical visualization support? Is this part of upcoming roadmap
It would be great to see if a thumbs up or a thumbs down was applied to the interaction in the raw interactions.
Our Dev team is recommending a new parameter to help with aggregation and reduce the number of calls to the API - The moveworks API currently supports some odata query parameters but is missing one that would make the data metrics collection process more efficient which is the $count query option. Usually, this is used with a filter to aggregate and return a number of items that matches the filter requirement. This option would allow us to only need to call the API once.
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.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK