How we manage support tickets
Hey there! My name is Cassie and I am a quality assurance tester here at Aysling. Part of my job is to work on support tickets that are submitted. Typically, when I get assigned a support ticket, it is to determine if there is a bug in our system. In this document, I’m going to walk you through how I manage that aspect of my job, and how we have set up our system to make a smooth support ticket workflow.
First, one of our clients (aka you) submits a ticket to our support team for a problem you are experiencing. Our fantastic support team works through all these tickets, helping you out and answering your questions. If the support ticket turns out to be a bug with the system, or if the team just needs a new pair of eyes to look at a ticket to help figure it out, then some of these tickets get reassigned to me.
When I get assigned a support ticket, I receive an email notification with information about the ticket and a link to view it in our Aysling site (we use the same software you do!)
I use the Open Tickets widget on my Dashboard in Aysling to help keep track of the tickets I am assigned. My Dashboard also shows saved searches of open tickets that can be worked on, even if I am not directly assigned to those.
When viewing the ticket, I will read through the initial description of the problem, and then review any comments or conversations made between you and other members of my support team. Depending on how complex the problem is, myself or another member of the support team may ask questions to get some clarification.
Next, I will review any internal comments that have been made between members of our support team. The internal comments may be our team members helping each other trouble shoot and sharing ideas. Or, if a ticket is reassigned to me from another member of the team, they will typically provide me with any information that they have already found out about the issue.
For each comment made on a ticket that I am assigned to, whether on the discussion with the customer, or internally with our support team, I get an email notification with the comment, making sure I am always aware of what is happening on my tickets.
Once I am assigned a ticket, and get some information about it, I try to diagnose the issue. There are a handful of methods that I use to try and figure out what the problem is, including looking into the items you listed as being problematic (specific line items, invoices, project tasks, etc.), reviewing your team’s system configurations and user permissions, checking the database for any discrepancies, and attempting to replicate the problem in my own testing site. Depending on how complicated the issue is, this could take me fifteen minutes, or multiple hours.
For example, if there is an issue with pre-pay discounts, I will look at your team’s system configurations regarding pre-pay discounting. Then, I will look at the orders and invoices that were listed as being problematic and see if I can see anything out of place there. I’ll look at the order and invoice histories, the line items, the discounts or fees, how the invoice was paid, etc. Depending on the issue, I will also check out the user permissions of your team members.
Once I get more information about how your system is set up, and how the orders were created and invoiced, I will try to replicate the problem in my own site, using the same system configurations, permissions, and sequence of events that caused the problems in your system.
If I’m unable to replicate it, then the issue might be because of bad data. In that case, I look at the system database to see if anything is amiss there.
Throughout this process, either myself or another member of our team communicates with you about what we have found out, or if we are still in the process of trying to figure out the issue.
If I’m unable to figure out the issue, then it gets passed onto another team member, with any additional information that I was able to find out. If I was able to figure out the problem, and it is a bug in the system, then I create a JIRA ticket. Our JIRA tickets are how our development team works on bugs or improvements in the system, and how we test them before the changes go into your sites. Once the JIRA ticket is created, we attach a link to your support ticket to it.
In Aysling, on your support ticket, I use our system’s ticket dynamic attributes to note that it was entered in JIRA, and to add the JIRA ticket number. This link allows us to keep track of where the JIRA ticket is in the process of being fixed, tested, and getting put into production.
We have a ticket automation workflow set up, so that when I add the dynamic attribute ‘entered in JIRA’, the ticket automatically gets reassigned to a different team member. This workflow makes it easy to keep track of my tickets, as I am only assigned to tickets when I need to be working on them and figuring out the problems.
The connection between the support ticket and the JIRA ticket also sets another ticket automation workflow in our system into motion. This workflow keeps you notified of where your ticket is in the process, and lets you know when the fix is available. We have a workflow set up with Zapier to update our ticket statuses when a JIRA ticket is updated by our dev team.