Three ways of providing customer service in gamedev

Efficiency is what pretty much everyone strives to achieve when working in video game development. It doesn’t really matter whether you are a 3D character artist, a game designer, or an accountant. A majority of people, I believe, work in scrum or agile enrivonments, however sprints are not applicable to some positions, like a customer support representative, or a community manager. How to organize their work and how to make them more efficient?

What are these ways?

People tend to have a good time when playing video games and that’s what matters for them the most. However, games, due to their nature, tend to break, or seemingly randomly bug out. This generates some anger and saddnes, but mostly dissapointment and a will to have things made right. That’s where your customer service gets to do their thing. Players need to have the ability to quickly and clearly report their issues. Some games provide:

• an ingame possibility to write external support (f.e. a button, which leads them to a form, which will be responded to via Zendesk),
• other ones only have an external way of writing support (most likely a separate website or an email address),
• and there’s also some which provide support via native communication formats (by this I mean f.e. an ingame chat, or an ingame message system).

Let’s go over all of them and talk about their pros and cons.

Ingame to external support (IES) – pros

1. Decent software – you are able to use software crafted for customer support and to configure it as you please.
2. Efficient placement – it is quite likely that the players will look for a possibility to write support in the ingame menus. Place it there and they won’t need to wander hopelessly through the interface. Also, it’s easy to tell them where they can find, let’s say, a button which will allow them to contact support. More importantly, it’s also easy for the other players to tell them where to look for it, and as we know, players often ask their friends how to do stuff before contacting company’s officials.
3. Ability to easily obtain necessary data from a player – external software often allows you to customize the form which a player is going to fill in order to send a request. You can make some of the options be obligatorily included in their request, like f.e. their email address, their ID number, platform they play the game on and even more complicated and crucial stuff like ingame logs, if they happen to have access to them. The possibility to have crucial data provided by the players will often lead to a precise identification of the issue and a satisfying solution.
4. Easy management and monitoring of your (staff’s) work – let’s be honest – customer support is usually a team effort and a team needs to be effectively managed in order to meet KPIs. A good tool surely will help with management, setting goals (and reviewing them), checking when a crash occured in the game (usually a massive spike of submitted tickets), being able to help an underperforming employee and a ton of other stuff.
5. Game’s not necessary to continue a started conversation – the game sometimes crashes for a long time, but players will often be able to continue their conversation with a support representative via emails and they are pretty reliable.
6. Ability to quickly deal with a big number of cases – let’s say that your game has an awful glitch, which renders the game unplayable from a certain point. And the glitch appeared globally and rapidly. There’s a ton of open tickets waiting to be solved, but this won’t be an issue. Thanks to tags and mass responses you will be able to quickly respond to three quarters of them (the ones with the uplayable glitch issue), while the other quarter can be dealt with by using predefined messages.

Ingame to external support (IES) – cons

1. Game’s necessary to initiate a conversation – let’s say, that one beautiful day, there’s a player, whose game stopped working. He is unable to log into it, rendering him unable to write support. This results in an unhappy customer, who is going to most likely abandon the product. And it’s of course not a good thing. If there was a bug, it’s possible that it will happen to another player and you’ll not know about it.
2. It’s going to cost – software like Zendesk or Livechat, while not being the most expensive examples of SaaS (software as a service), also happen to generate some costs, which could be troublesome for super small studios or single person indie game developers.
3. Immersion’s broken – this is an issue, which could be helped a little bit, but it’s never going to be fully got rid of. A player using the feature will have to leave the game and is going to not impersonate their ingame avatar, but is going to be an average Joe 1, who’s writing a Joe 2, a customer representative. And it’s most likely not going to be a fun experience for at least one of them. Writing support is often boring, bland, time consuming. You can make this a little less chore-like if you talk to the player in a way inspired by the world of the game. Something along the lines of „Welcome, oh Mighty One. It is I, Zoltar, the Archmage specializing in mending issues. What shall I assist you with?” in an RPG would make sense, but it could also render a message incomprehensible for a player, who doesn’t know the language you’re writing him in too well.
4. Responses are often bland and not personal enough – I’ve read a countless number of messages saying that responses sent by the support were not personal enough. I fully understand this. Message templates are a great and extremely efficient tool, but they tend to often look robot-like. However, it’s often impossible to avoid using them, especially while dealing with high volumes of tickets. The issues will be solved, but the playerbase won’t be taking you kindly.

Exclusively external support (EES) – pros

To be frank, EES is quite similar in the way it operates to the IES, so I’ll just copy and paste bullet points which stay the same for both of them.

1. Game’s not needed to start a conversation – players will sometimes not have the ability to turn the game on, so, compared to the first described way, EES will always be up, rendering it invulnerable to game crashes. This also means that players looking for support outside the game will be able to find it.
2. Decent software.
3. Ability to easily obtain necessary data from a player.
4. Easy management and monitoring of your (staff’s) work.
5. Ability to quickly deal with a big number of cases.

EES – cons

1. Tricky placement – having an EES will make it difficult for the players to write you about the issues. You’ll have to figure out how to communicate to them about the existence of the support and this may be quite tricky. Keep in mind that they will often look for the support on your website and social media profiles.
2. Immersion’s broken, but in an even harsher way than in IES.
3. It’s going to cost.
4. Responses are often bland and not personal enough.

Native communication support (NCS) – pros

1. Immersion’s hardly broken – let’s say that you work at an MMORPG and a player writes „GM, GM please help me, I got scammed”. You greet him, ask what’s happened, quickly investigate the case, return stolen goods, punish the scammer, advise the player to be more careful next time, ask him if he needs help with something else and you’re done. Using NCS, this all could be done via ingame chat or direct message system, allowing for an almost seamless experience for the player.
2. High level of personalization – this method kind of forces you to be personal and authentic when you talk to the player. They know when you address them using templates and when you take time to write each message from the scratch and they appreciate such a personal approach.
3. Very quick responses – it’s a natural thing to respond to a person as quickly as possible. This is a principle of communication which we all abide by on an almost instinctive level. Your brain remembers about this principle and will kind of force you to respond immediately – just like when a person writes you a message on Facebook, you will usually respond ASAP. Unless you don’t care, but if you didn’t, you wouldn’t be reading this article, I believe.
4. Ability to quickly deal with low-profile cases – most of the problems that players have tend to be solved within minutes if not seconds and NCS is a great way of dealing with such cases.
5. It will improve your brand’s image – there’s no better way to show your customers that you care about them than to talk to them about their issues and desires directly. They will be more demanding than in the case of IES and EES, but they will appreciate your efforts and will develop a positive attitude towards you, which could lead to a higher customer retention and payments rate (in the world of F2P games).

Native communication support (NCS) – cons

1. Extremely engaging and quite tiring for you (your employees) – try to sit 8 hours or more in front of your computer monitoring an ingame chat, actively looking for players and waiting to be messaged, while also being prepared to respond accordingly in a timely manner. This isn’t really a „fun” experience for a customer support representative.
2. Software is going to be far from perfect – you’ll be using the ingame features, however you need to keep in mind that they should firstly be made with the players in mind. This means that they will most likely not be optimized for troubleshooting. It will also be hard for you to measure KPIs, response times, number of cases and all the other stuff which is, in the end, important. Of course, you can code it into the game, but if you’re not in charge of coding, these features will most likely not be added to the game.
3. It’s easy to be overwhelmed by the players – I’ve had multiple situations in which I was written to by twenty or more players due to a bug, a random crash, or an unpopular decision which had to be taken… And it wasn’t enjoyable.
4. Harder cases will not be solved on the fly – lack of proper tools and the need to be swift will render some cases to be almost impossible to be dealt with. Player will expect you to provide a solution on the go, however you know that you’re going to need f.e. an hour to solve the issue. This is natural, but will nevertheless make the player dissatisfied.

Which way of providing customer support is the best?

There is, of course, no definite answer to this question, because there’s a ton of factors which would affect it. Let’s say that you are able to utilize IES, EES and NCS… Why not use them all?

• IES could be used as a standard way of dealing with most cases,
• EES could be used as an emergency way of contacting you, you can also redirect people to EES from your website or social media easily,
• NCS could be used as a way to improve the player experience and as a tool to redirect people to IES and EES, while it also could „weed” some simpler cases, making your external support platform more clear and easier to use.

In the end it’s all about making your players satisfied and about increasing your revenue (not a controversial statement, gaming companies exist for a reason).