Moveworks continuously polls your information technology service management (ITSM) system for new unassigned tickets that it can resolve. When a user files a ticket through the self-service portal or via email, the bot can intercept these tickets and reach out in-chat with a solution the bot is confident can solve their issue. It also leaves a comment on the ticket describing its proposed solution.

If the bot is able to fully resolve the user’s issue, users can give acknowledgement in-chat by responding to the bot. Then, it will mark the ticket as resolved. If the bot’s solution does not solve the user's issue, they have the option to rephrase their issue and add a clarifying comment to the ticket.

When does Moveworks intercept a ticket?

Not all tickets are eligible for ticket interception. Filters have been built into this feature to parse out tickets that do not meet the following criteria:

Requestor has access to the Moveworks bot
- This ensures that the bot will only reach out to users who have access to Moveworks and are eligible for assistance from the bot.
Is open/new
- This filters out tickets that are not in a NEW state at the time of initial polling. A ticket has to be freshly filed and untouched by any agent to be eligible for Ticket Interception. The bot does not reach out on tickets that were already worked on by an agent — this is done to minimize confusion and noise.
Not created by an agent
- This allows the bot to filter out tickets created by an agent on behalf of the user, which means that an agent already looked at the issue and provided the first level of assistance. This also filters out any tickets created by an agent to log work they did (i.e. moving cables from one room to another) that did not directly help an end-user.
Not created by the bot
- This filters out tickets that were created by the bot via reach outs. The bot does not take action on tickets created by itself because it has already resolved or had the chance to resolve them.

Beyond these default filters, other filters can be configured within the bot to prevent it from intercepting certain tickets types.

How Ticket Interception works

The Moveworks bot will only reach out about tickets it thinks it can resolve. When a user does not find the reach out helpful, the ticket remains in the queue so an agent can address it later.

Poll

The Moveworks bot polls your IT Service Management (ITSM) system for new tickets on a regular basis (typically every 30 seconds) through API requests. By doing so, the bot typically sees all new tickets before a service desk agent does.

Intercept

Once the bot detects a new ticket, it gets processed through Moveworks’ natural language understanding (NLU) system, where the ticket’s intent and key terms are extracted. The analyzed ticket is then sent to the Moveworks Conversation Engine so different skills can put forth potential solutions. The bot will then present the user with the solution it thinks best solves the user’s issue. The following skills can participate in ticket interception:

Answers: Provides relevant answers taken from your organization’s knowledge base articles or FAQs to help the user with their issue
Software Access: Assists the user with provisioning and/or installing a software application they requested
Groups Access: Assists the user with creating distribution lists and adding members to distribution lists
Account Access: Assist users who are locked out of their accounts by helping the user self-service a MFA reset
Forms: Provides relevant forms that users can fill out to provide agents with the required information to fulfill the user’s request

Notify

After the bot processes the tickets, If one or more of the skills listed above provides a solution to the user’s issue, the bot will notify the user of the solution(s):

The bot leaves a comment on the ticket describing the solution(s) it has to offer.
If your ITSM system is configured to send emails to users when comments are added to their tickets, this should result in an email sent to the user with the same information.

Note: It typically takes around 1.5 to 4 minutes for a bot to go through the process of polling, analyzing, and notifying the user of a solution.

Resolve

When the user receives the bot’s solution(s), they can proceed in a few ways.

If a solution involves automated actions, such as an email group addition or software provisioning, the user can select the button provided by the bot and follow the prompt to confirm and complete their request. The workflow operates in the same way it would have if the user’s request originated from a chat message to the bot. Note: The bot will never proactively take action without the user’s explicit acknowledgement.
If the user is provided with knowledge answers, they can view the provided snippets or select the provided links to view the entire text.
If the user receives a form to fill out, they can submit the form (either through the service portal or the chat interface, if enabled). Once the form is submitted, the bot will close the original ticket and create a new one that it will link to in the comments of the original to avoid agent confusion.

The exact resolution can vary depending on the skill and the channel from which the user takes action (i.e. from chat or the ticket comment). If the solution the user receives doesn’t solve their issue, the user can rephrase their problem or ask for more help from the Service Desk.

Audit Trail

When the Moveworks bot intercepts a ticket, it adds a comment to the ticket that identifies the solution it has for the user. Then, it adds another comment to the ticket saying it has reached out to the user in-chat. Internal note comments are also added — these summarize how the bot helped the user, and include other relevant pieces of information. Depending on the user response, more comments will be made by the bot to log interactions between itself and the user. And if the user chooses to get assistance from a service desk instead, the bot will leave an internal note to agents to help them resolve the user’s issue.

Ticket Interception Skill Deep Dive

Answers

The Software Access and Groups Access skills work the same way they would if the user were to activate them via a message in-chat. If the user were to file a ticket asking for access to a piece of software, the Moveworks bot would be able to intercept those tickets and offer a solution that would get them access. But the only Account Access skill that’s available through Ticket Interception is MFA Reset. Currently, tickets with Unlock Account and Password Reset issues cannot be intercepted and resolved by the Moveworks bot. This is because the bot will already have proactively reached out to the user if it noticed the user is locked out of their account or if their password is expiring.

Configuration options

Ticket Filters

In addition to the default ticket filters (white boxes in the diagram above), Moveworks lets you include on additional ticket filters so you can more precisely scope tickets that:

Are eligible for Ticket Interception
Are eligible for ticket notifications
Can be intercepted by Moveworks Resolution, Concierge, and Triage skills

Universal Polling Ticket Filter

This is the top-most filter — meaning any tickets that do not pass the criteria are completely removed from Moveworks. These tickets are not logged, machine learning (ML) analysis is not performed on these tickets, and they are not used in analytics. In short, Moveworks will not process these tickets for any ticket-route skills, which includes but is not limited to: Concierge, Answers, Access Software, Access Account, etc.

Resolution Ticket Filter

This filter can be configured to determine what is and is not within the bot’s resolution scope. Tickets that pass this filter are used in the “denominator” when calculating the bot resolution percentage.

Resolution Action Filter

This filter can be configured to determine whether or not the bot should reach out with Resolution skills to help resolve a ticket.

For example, this filter can be configured to:

Limit the scope to only generic incidents and requests
Exclude certain contact types (phone, walk-up, etc.) or special circumstances (such as eliminating any generic tickets that get auto-assigned to specialized groups upon creation).

Concierge Filter

This filter is used to determine when the Moveworks bot should refrain from sending notifications to users about ticket lifecycle updates: like “waiting for user”, “comment was added”, “ticket was resolved or cancelled”. You could also, for example, use this filter to withhold notifications about ticket updates from a certain location (e.g: Do not notify users based out of Germany, or do not notify VIPs).

Answers Ticket Filter

This filter identifies tickets that the Answers skill can address. See our Moveworks Answers documentation for more information on this feature.

Triage Ticket Filter

This filter identifies tickets the Triage skill can address. See our Moveworks Triage documentation for more information on this feature.

FAQ

Q: When does a skill know it achieved resolution?

A: The bot considers a ticket resolved when the user closes the ticket via bot, email, or the self-service portal. But if the bot reached out with the Answers skill, the ticket is considered resolved only after the message is sent.

Q: Can different ticket filters be configured for different domains (i.e. HR, Legal, Finance)?

A: The bot can be configured to filter different domains, beyond just IT. Please reach out to our Customer Success team to learn more about configuring filters for different domains.

Q: What’s the difference between the Resolution filter and Resolution action filter?

A: The Resolution filter identifies all the tickets that are in the Moveworks’ bot resolution scope. It excludes tickets that the bot is unable to resolve, such as system generated tickets, tickets that are not for internal support, and tickets that are outside of the domains supported by the bot. In contrast, the Resolution action filter identifies tickets that are within the scope so the bot can intercept and reach out in-chat with potential solutions. This typically includes: tickets generated from emails, generic requests, and tickets opened from the portal.