Support reply times Print

  • 237

We have various methods of communication here at GGServers, and our customer complaints tend to revolve around one recurring issue:  The length of response time for open tickets.

 

Looking into these complaints took some time, but we did so in an effort to figure out why tickets were taking so long to be responded to.  These included problems reported over Facebook, over the forums, and over private messages.

 

After all that, we came upon a few reasons that ticket responses are delayed.  This article will cover these most common situations that cause delays in ticket responses.

 

 

Case 1: Replying to your ticket asking for an update

 

The primary cause in delay appears to be when customers reply to their own tickets asking for an update.   Below is a brief explanation of how this occurs.  This is the most common situation that causes delays in replies to your tickets.  This case will profile how we respond to support tickets.

 

In our ticket system, we have a column that looks like this:

 

LastReply.png

 

What this column does, is sort the tickets by the last time they were replied to.  We all set this column to show the tickets with the longest time since the last reply at the top of the list like this:

 

Tickets.png

 

(Ticket times listed here are from past tickets and do not reflect actual current times)

We always work from the top of the list with each of us handling tickets that are in our respective departments.  As you can imagine, some things can only be handled by certain members of staff.

 

We continue to work down the list as quickly as possible in this pattern.

 

This information is key to the original point: Why you should NOT reply to your own ticket asking for an update.

 

Once a reply is made  that "Last Reply" timer is reset to 0, and the ticket is moved to the bottom of the list.  That causes further delay in getting your ticket addressed.  The cycle can then repeat itself to the point where we may never see your ticket, and you think we are ignoring it when it simply never makes it to the top of the list.

 

Case 2: Plugin and Modpack Installation Support

 

Oh boy, does this one get backed up at times.  Why?  Plugin and Modpack Installation is time consuming, because IT IS HARD.  It’s as simple as that.  Many users submit requests to this department because they either:

 

A: Do not have the knowledge in how to setup a server for their desired mods.

B: Do not want to do it themselves.

C: Have some trouble with one or two minor issues.

 

In all of these cases, plugin and modpack installation are troublesome to do and we only have a few staff members trained to tackle these.  This is due to the demands in undertaking this task:

 

A: The Staff Member has to have a good internet connection to upload all of the files needed

B: The Staff Member has to be able to read past the fact it says error to figure out WHY the error is occurring.

C: The Staff Member has to able to figure out how to fix the error that is occurring

 

Those 3 things go for both Plugins and Modpacks.  They are difficult.   Other issues that cause delays in the tickets are because of a lack in information given by the customer themselves.  Here is an example of many tickets we deal with on a daily basis:

 

Original Customer Ticket: I want FTB on my server!

Staff Reply: Which Modpack off of FTB would you like?

Customer Reply: I want the Direwolf20 pack!

Staff Reply: Which version of the modpack would you like?

Customer Reply: 1.0.24 please

Staff Reply: I noticed that you have files on your server, do you need any of them or are we OK to delete what is there?

 

 

The ticket can go back and forth like this because we have to ask for each piece of information that we need to perform a satisfactory modpack installation.  Add to this fact that we are a company with staff and customers all over the world.  This can also mean that the likelihood of getting an instant reply from either party is pretty slim.  We all have lives outside of our Minecraft Servers (for the customers) and outside of providing support (for the staff).  So when there are 3-4 hours in between each reply, that adds up.  What could have been solved in under an hour suddenly took over a day.

 

Sure, the technician could have taken the first message and uploaded their favorite pack and version.  Technically, the ticket issue  would be resolved because FTB is on the server, but we don't want to do that for obvious reasons.  The next reply would be, "YOU DID THE WRONG ONE!" and it would just degenerate from there.  The customer is mad because it wasn't what they wanted, we are mad because they didn't tell us the information we need to do our job correctly, and you can see how it becomes a mess.

 

Sometimes, for things off of the ATLauncher, there are optional mods available, and we have to ask which of those the customer may want so that we can get that correct as well.  This can delay the whole process because we try to do the job the first time correctly, and we have to ask questions, then wait for the answers.

 

How can you, as a customer, help to streamline this process?

 

Provide us as much information as you can in your ticket when you submit it.  Going back to our earlier example of the customer wanting FTB to be uploaded to his server, if he were to instead phrase his ticket as below, the installation process can be completed quickly:

 

Customer Original Ticket: "I would like to have the DireWolf20 Pack off of the FTB Launcher.  Version 1.0.24 would be great.  We were playing with vanilla while we waited, you can delete everything there when you do this, we don't care about the world, but could you please save the Ops and Whitelist files?"

 

If every first post for the Modpack department were like that, tickets would take very little time.   That post gives us the launcher, the modpack/version, and gives us the information we need to keep/delete on the server.  The next reply to that ticket would be, "Hello, your server is up and running as requested! Can you please verify from your end?” and the customer would be able to play his desired server.

 

Case 3: Dedicated IP Activation

 

Having a dedicated IP activated is a higher level process that only select members of staff can perform.  It involves taking your server, comparing its stats to find a new panel that has available Dedicated IPs AND enough space for the amount of RAM you have, then moving and activating the server on that new panel.  This is because not all of our panels have more than 1 Dedicated IP Address available at the time and we may have to move the server to a panel with an available Dedicated IP slot.

 

Primary causes of delays:

 

1: Just plain ran out.  We do try to keep ahead of our customers, however Dedicated IP Addresses can sell out fast and sometimes it takes us a bit to notice.   Once we notice, we have to examine our options.  What panels in the region have space that could handle the additional load of having the dedicated IP addresses? How long will it take to get more? How many can we get?

 

2: Waiting for customers to download backups.  We can not transfer files from one panel to another when we move a server.  We have to wait for the customer to backup their data so we can move them.

 

3: Workload.  Sometimes we just get so many it takes us longer to get to them all.  Once we see the customer's reply that they have backed up their server files, we can proceed.  It takes about 10-15 minutes to search our panels for an IP and then proceed to do the move.

 

The good thing about dedicated IPs: You only have to suffer the wait once.  After that, the problem is solved unless you don't pay your bill and your service gets suspended.  We do not hold IPs for customers who don't pay.  Now, that is not to say as soon as you get suspended your IP is always given away immediately.  As was stated before: sometimes we get a bit of a lull and people don't request, so it might not get taken away from you right away, but it still might happen if you wait too long to pay for your service.

 

Case 4: Opening multiple tickets.

 

Another common situation that can happen: Customer opens a second ticket because they think it will make things go quickly.

 

WRONG.  All this does is tie up a support person trying to help you with an issue that might already be handled in your original ticket.  This in turn slows down the process in general because it’s not just 1 or 2 people who do this: it’s a pretty good chunk of people who will do this and cause more problems for everyone.  If this is a Modpack and Plugin ticket, it can even cause harm to the mods installation with two technicians trying to install the mods at the same time.

 

 

In Closing

 

We hope this article has helped you to understand why delays can happen and how we work to avoid them.  We don't ignore tickets; they all must be completed, but we have to work though all of them.  We all try to do our best to offer quick and accurate support to you, our customers.





Was this answer helpful?

« Back