Customer Service
09/15/2008 | Devlog | | Discuss
When Pirates of the Burning Sea launched back on January 22nd 2008, and in the various beta programs leading up to that, it fell to Misha to create a Customer Service Department from scratch. Along with putting together the team itself she had to design the various processes and procedures that were necessary for the team to be effective. That entailed configuring the tools to use, hiring in house CSRs, partnering with East Coast and European external GM companies, as well as the design, and communication, of the processes and procedures. It was a huge unenviable task, but she got it done with flying colors in a time of total mayhem. Fast forward a bit to this past July when she transferred over to the producer position and I took over the Customer Service department. Well, since that time I’ve been getting up to speed on the processes, and now it’s time to do what I do best, which is to tweak what we do to make it more timely and more fruitful, similar to what I did with the Test Team.
The Flying Lab Software Customer Service Department consists of multiple people, who all specialize in supporting certain areas of the game such as hardware and networking issues, Epic Battles and the Contention System, Missions, and even one who works tickets for pretty much everything else. We also work with the above mentioned 3rd party companies that provide our GM support, one is in America while the other is in Europe. Add to this the FLS Community Team lead by Aether, which includes our forum moderators, and that’s quite a few people to coordinate. This is why we need pretty strong and clear processes, coordinating a large group of people all working on a different aspects of the same project, across many time zones, is challenging.
Most of the tweaks I plan to make to the Customer Service processes should be invisible to our customers, with the exception of providing more timely customer service. I am well aware of the many tickets that, perhaps initially receive a quick response acknowledging the issue, but then sit around for weeks for someone to get to them; that is about to change. There are 12 Incidence Types in our system, a few examples are:
- ‘Stuck / Unable to move’
- ‘Harassment’
- ‘Technical Issue’
- ‘General Bug’
Moving forward each Incidence Type is going to have one person, or a group of people, responsible for that type of ticket. Once someone starts working a ticket, they own it, and either they work the ticket to resolution or they directly hand it to someone else, and now that person owns it. Ownership is the name of the game!
Before we can really get going on these process changes we need to scrub clean the current customer ticket database. This will entail making sure that all the current tickets are assigned to the proper people as well as locating all the tickets that have been hiding in the corners too long. Let’s face it, some ticket types get priority over others; ‘I’m stuck in game and can’t move’ always get processed before ‘I think you should add this to the game’. Initially this will create a bit of additional overhead, and likely some internal confusion. However, I will manage the change every step of the way and see that it gets done. Once we feel the ticket database is in a clean state, moving forward should make all our lives a little easier, and it will remove a lot of ambiguity in the system.
While I have your attention, I would like to discuss reimbursements a bit. On 6/25/2008 Misha wrote a reimbursement Dev Log, however I want to list some specifics here to make sure we are all on the same page. We get a lot of reimbursement requests, and while we really dislike telling people ‘No’ there are certain things we will reimburse for and certain things we will not.
- If one of our server goes down, resulting in you losing an in game item, we will reimburse. However, it’s not always easy from the client side to tell if a server really went down or if there are internet connectivity issues.
- If your files are corrupted from a recent download, we will reimburse, but you will need to follow our instructions to fix the problem as we will only reimburse for this once.
- If your computer or ISP is experiencing network issues, we will not reimburse. This is a sticky subject because it’s tough to prove to someone that the network issue is on their end when their Internet Explorer still works. Here is a quick explanation from our CSR who handles hardware and networking tickets:
Our game relies on TCP packets for the UI, and UDP packets for in-game movement and controls. If even one little TCP packet is dropped from the client end, the server has to resend those packets, sometimes causing a long enough lag for the game to disconnect, even though you may remain connected on other programs. The operating system and programs like Internet Explorer rely mostly on light TCP traffic, and can handle packets being resent; sometimes the user might notice a page take an extra second or two to load, but it’s not too noticeable. UDP, however, doesn’t get resent like TCP does if you lose a UDP message, it’s gone. UDP is therefore good for situations like motion or video, where it’d be useless to re-send data, because by the time it got there you should be displaying the next frame. The only disconnect our servers would do on our side is if the connection looks like it’s already closed (because of bad networks on the client end or in between).
- If we made a change to an in game item we will not change out your current one for a different one. An example would be a mission reward item where you could choose item A or item B, you choose item A, we change item A a bit; and now you want item B instead. MMOs are constantly being tweaked and balanced, we must give our game designers the flexibility they need in this area, and it would become a Customer Service nightmare to reset everyone every time Isildur or Taelorn decide to modify an item. This issue continues to be a head ache for both customers as well as CSRs, but it’s simply a result of the MMO genre.
One small way in which you can help us is, for customer tickets related to missions, is to put the name of the mission you are having problems with in the title of the ticket. This will allow the FLS CSRs to find their own tickets, without someone having to read them all first, and speed up response time.
That’s that for now; a new day is dawning in the Customer Service Department at Flying Lab software.
Nutch09/15/2008 | Devlog | | Discuss
![]()

