Best Practices for Tickets– Left Sidebar

Continuing on with the Zendesk train here, Reclaim is developing the best way to handle tickets as they come in. Up until now, we’ve had a little system going but it definitely needed a bit of improvement. I thought it would be handy to write out how we use the left sidebar of our ticket viewer in Zendesk. So while this post is really used for employees at Reclaim, anyone can really take bits and pieces to this process their own. I’ll start with an overview of what our window looks like when we’re interacting with a user then move into specifics about how these help us respond to each user as quickly and efficiently as possible.
This is what our main ticket viewer looks like from the administrator end. You can see on the left hand side there’s a tool bar dedicated to ticket fields. This helps us organize each ticket so they do not get lost. The middle section is where we see the users response and are able to write our own. The right sidebar is where the user’s data is held. We can see things like open tickets and their account information.

Left Toolbar

This is what the typical left sidebar looks like when managing a ticket. You can see the ‘brand’ of the ticket, meaning all responses are coming from Reclaim Hosting. When a ticket is created for Rockaway Hosting, we’ll see the Rockaway logo. This is one of the first things I look at when interacting with a ticket, it tells me where I need to login to access the client information. From there, you can see who is assigned to (currently working on) the ticket and if there is any one CC’d to the thread. The next few sections you’ll see are mainly used for internal tracking and reporting. The tags section is used to tell us a bit about the ticket content. We can use these to run reports on specific tags to see how many tickets we get on each tag. After the tags, the next section you’ll see is the the ‘Type’ section. This is used to designate a the type of ticket we received. There are 4 ticket types that Zendesk created by default. They are Question, Incident, Problem, and Task.
Each ticket type is used for a different purpose and helps us organize our tickets even more.
  • Question: This type is used for someone who’s asking a question about an invoice, a domain registration or transfer, or how to get started with their account. This is the default type we’ll use.
  • Incident: This is used when we identify that there is a problem that affects more than one of our users. Once the problem is designated, you’ll change the ticket type to Incident and link it to the parent problem.
  • Problem: The problem type is the parent to an incident type ticket and is used when there is a problem with our product. Let’s say the server is offline and we’re getting a ton of tickets. You’ll create one ticket describing the problem to become the ‘parent’ problem then you’ll be able to link other incident tickets to that parent.
  • Task: Use the task type when you need to assign a date to a ticket. You can use this when you’re waiting for a domain to be released to the public after the redemption phase, or you want to follow up with a potential sales lead. After assigning the task type, you’ll see a due date field appear. Select the date you’d like and you can add it directly to your calendar.
Next to the ‘Type’ section is the ‘Priority’ section. We use this as a status to prioritize our responses to tickets.
  • Low: This status is used when the user doesn’t necessarily need a response right away.
  • Normal: Normal is probably going to be the most used status. Assign this priority to any ticket that comes through that isn’t a pressing issue. If you get a ticket with a question or a small incident ‘normal’ is a perfect priority.
  • High: Used for all tickets that need more attention over other tickets. So we can use these if a server goes down or we need to take a look at a site as soon as we can.
  • Urgent: This is the highest priority and used when the ticket needs to be looked at immediately.
The last ticket field in the left sidebar is the ticket Topic. The topic field is a custom field Reclaim Hosting created to help us designate the broad category of the ticket. So, we can designate the topic as Billing, WHM, WHMCS, Domain management and, DNS to name a few.
When editing the ticket before we send out our initial response, we go through each section and add tags, select the type, priority and, topic. These ticket fields are only viewable by the ticket agent (us at Reclaim) and we usually edit them as the ticket progresses. This is just a little glimpse at Reclaim Hosting’s back end of Zendesk– there’s definitely a lot of customization and our view might be a little different compared to another company.

Automations in Zendesk

If you’ve worked with me on a ticket in the last couple of weeks, you may have noticed a new email come into your inbox from Reclaim Hosting support. It might look something like this: 

I’ve been experimenting with a feature of Zendesk that automates some of the processes that Reclaim would normally complete manually, in particular, following up with the client. 

Now don’t get me wrong, following up with the client is very important and we will definitely continue to do this where we can manually. With that said, it does take up time throughout the day and we were looking for ways to improve our agent’s experience while keeping in touch with the client. 

I recently took part one of Zendesk’s training for Support Administrators where they touched on automations. Reclaim already has a few automations set up where we send out a survey after closing out the ticket and closes out the ticket completely after a few days. I was inspired to see where we could use some more automations within Reclaim’s support infrastructure. 

Tim came across an automation method called the Bump Bump Solve where users are notified with automatic follow ups 3 days after there is no response from the Client. The article talks about following up twice before the ticket is solved. The entire process looks like this:

While this method follows up with the client twice, I decided that Reclaim doesn’t necessarily need to follow up twice so, I modified the method to only follow up once before solving the ticket. 

I first tested this out with only tickets assigned to me, this way I made sure everything was going well and the users were notified. To make sure the automations were running as scheduled, I set up an additional notification to send an email to myself whenever the first email was sent out. 

We decided to follow up with users 48 hours after no response, rather than the 72 hours mentioned in the article. This is what the first follow up looks like:

After the automation sends out the follow up, it adds the tag #bump1 to the ticket. That tag is vital to run the next automation, which solves the ticket. 

That automation is very similar to the follow up automation, but instead of sending out an email, it marks the ticket solved.

And that’s it! If we don’t hear from a client in 96 hours from their last update, the ticket is closed out. 

We wanted these automations to be a little nudge to the client to remind them they opened a ticket with us, and allows us to clear out our queues so we can focus what is important in the moment, like helping you!