Table of Contents
Advanced Ticketing Features
Updated
by Mitchell Paul-Soumis
Read Time: 4 mins
In the Ticketing: Overview article we covered the basic features and usage of the Ticketing page in Sonar. In this article, more advanced features will be showcased, including where to find them, what they look like to an administrator or to users, and how best to leverage these features to simplify your actions in the ticketing interface.
Mass Editing Tickets
The process of editing individual tickets was covered in the Ticketing: Overview article, however, it can also be taken a step further. Mass editing tickets allows you to select a group of tickets and make changes that will occur on each of them. In order to initiate a Mass Edit of your tickets, simply check the box next to each ticket you wish to edit:
With each box that gets checked, the ticket name will be added to a banner at the bottom of the page:
Once you've selected all the tickets you want to edit, click on the edit button located at the end of the banner:
If you've read through the Inventory List View: Overview article, the "Edit" modal that shows up will appear to be very familiar.
This Edit Tickets modal has a number of fields:
- The Entity selector allows you to modify the Account or Network Site the ticket is assigned to.
- The Status selector allows you to modify the status of all the tickets you've selected for mass modification. You can choose between:
- Closed
- Open
- Pending (External)
- Pending (Internal)
- The Priority selector allows you to modify the priority of all selected tickets. You can select from:
- Critical
- High
- Low
- Medium
- The Due Date selector allows you to set a specific date that all selected tickets are due by.
- This section will list all tickets that will be edited by these changes. Once the "Edit Tickets" modal is open, you can no longer remove or add tickets.
Unlike Using Parent Tickets, mass editing tickets doesn't allow you to add comments or details concerning why changes are being made. The changes are simply made, and will only appear in the logs of each ticket.
Prevent Tickets from Reopening after X days
In previous sections and articles surrounding the Ticketing feature of Sonar, manually managing tickets has always been the only way of controlling their behavior. Whether on an individual basis or in bulk, replies, assignments, and closing the ticket all needed to be initiated by a user. Sonar does provide a small measure of automation in managing the path for tickets that have been closed and receive a new reply.
The default behavior will be to reopen the ticket and have the new reply appended to the existing message history. This will occur indefinitely, as long as the original subject line remains in place. By following the below directions, you can configure this behavior to place a limit on how these reopened tickets should be handled:
- Go to Settings
- Expand the Ticketing section
- Click on General
This will allow you to modify the number of days a closed ticket needs to stay closed before a new reply will not re-open the ticket.
With this setting configured, new emails received in existing ticket chains will create new tickets, rather than appending the new reply to an existing ticket and reopening it.
When This is Useful
Controlling how and when tickets can be reopened by a customer is useful in managing unrelated issues. There are always certain customers who will continue to default back into using the email they've previously received. This can mean tickets being reopened months later simply because it was the most convenient way for the customer to reach your team, even when the new cause for contact is unrelated to the original one.
By forcing new tickets to be opened after a certain number of days, you enable each conversation to be on-topic and simplify the process of troubleshooting or resolving the issue at hand, as the ticket is free of any cumbersome history.
Currently Viewing
In best practice, the user assigned to a ticket is the party who will be responsible for seeing that ticket through to completion, or the next point of escalation. However, circumstances may arise that would prompt another user to interact with the same ticket. In these scenarios, another user may be in the process of detailing vital information via a new comment at the same moment that the assigned user is typing a reply to the customer with now inaccurate information.
The Currently Viewing feature allows you to see if another user is viewing the same ticket as you, by displaying the user's avatar at the top-right corner of your instance - hovering over the avatar will display the user's full name. If the user is actively typing a comment or reply, another icon will also be visible and is used to indicate that a response is being written by another user. With indicators like these, you can help to eliminate duplicate efforts and contacting customers with outdated information.
