Help Desk Software for MOGs

 
Author:  Follow: TwitterFacebook
Job Title:Sarcastic Architect
Hobbies:Thinking Aloud, Arguing with Managers, Annoying HRs,
Calling a Spade a Spade, Keeping Tongue in Cheek
 
 
CSRs supporting Game Worlds
#DDMoG, Vol. VII

[[This is Chapter 26(b) from “beta” Volume VII of the upcoming book "Development&Deployment of Multiplayer Online Games", which is currently being beta-tested. Beta-testing is intended to improve the quality of the book, and provides free e-copy of the "release" book to those who help with improving; for further details see "Book Beta Testing". All the content published during Beta Testing, is subject to change before the book is published.

To navigate through the "1st beta" of the book, you may want to use Development&Deployment of MOG: Table of Contents.]]

One thing which is almost-universally neglected in real-world MOGs – while being of paramount importance – is Help Desk Software.

On Importance of Support for MOGs

In a single-player gamedev world, the relative importance of different player-visible aspects is usually seen by management along the following lines (Table 26.1):1

Content (which is King)
More Content
Even More Content
Visual Effects
Rest of 3D Graphics
Gameplay
Sound/Music
That’s it – nothing else matters (=”zero importance level”)
Support (importance is below zero)

As this book is about MOGs, I won’t elaborate on the reasons behind this (IMO pitiful) state of affairs, though will briefly mention that:

  • Prioritizing Content before Gameplay seems to go against players’ wishes even for single-player games (see, for example, discussions on [GameSpot] and [GiantBomb] to get a few examples of player’s opinions)
  • IMNSHO it largely steams from:
    • most of AAA gamedev companies working along the lines of movie production companies, and
    • an average game reviewer being unable to judge anything but shiny graphics.
  • As long as it is about single-player games, it isn’t much of our concern within the context of this book.

For a typical MOGs2, however, situation changes drastically (Table 26.2):3

Gameplay
More Gameplay
Content Graphics (can be very rudimentary4) Payments Support Connectivity
Sound/Music

As we can see –

for MOGs, support becomes one of the very important parts of the picture,
often on par with Content and Graphics.

Hare thumb up:More reliable software and much better support were apparently sufficient to overtake the whole competition and get about 50% market share of the whole niche (making over a billion dollars in revenues per year in the process). This, in turn, makes your Support Team one of the substantial overall teams of your multiplayer game. Once upon a time, I’ve seen myself a very successful multiplayer game, where gameplay was mostly on par with a competition (and graphics was admittedly worse) – and the competitive advantage over the competition stemmed from two things: (a) reliable software (including better handling of connectivity issues), and (b) much better quality of support (which included non-trivial stuff such as security complaints etc. etc.). These two things were apparently sufficient to overtake the whole competition and get about 50% market share of the whole niche (making over a billion dollars in revenues per year in the process). 

One last note aimed to CEOs and financial guys:

DO NOT consider your Support Team an expense.

Rather, your Support Team should be seen as a way to improve overall customer experience (and this, in turn, is Extremely Important™ for competitive MOG niches). As noted above, this approach of “Support Team to improve Experience”), in turn, has been observed to provide a big competitive advantage (as noted above – at least in one case it was one of two key points which have proven to be sufficient to grab 50% of the market share, and to make a billion a year).


1 As we’re speaking about player-visible features – marketing, monetization, and Back-End Tools are intentionally set aside
2 whatever it means
3 as always, YMMV
4 as it was discussed in Vol. II – there are successful MOGs out there with an extremely rudimentary graphics (such as static 2D images).

 

Help Desk Requirements

E-mails vs Tickets vs Live Chat vs Phone

With this in mind, let’s see what we can do to help our Support Team to keep our players happy. First, let’s note that most of the time,

We do NOT want to provide available-to-everybody live chat, or phone support.

There are two Big Reasons™ for it:

  • Wtf hare:the quality of support when using synchronous support methods such as live chat/phone support tends to be significantly worse compared to asynchronous support such as e-mails/ticketsthe quality of support when using synchronous support methods such as live chat (and even worse – with phone support) tends to be significantly worse compared to asynchronous support such as e-mails/tickets. This happens because of several factors:
    • With emails/tickets – your CSRs are working in a not-too-stressful environment of “hey, I have time to think about it (or to chill out) if I need”. With live chat and phone support – CSRs are in a fundamentally different and extremely stressful mode of “I need to answer right away”, and you’ll see very soon that finding knowledgeable people willing to do it in such a stressful environment, is apparently next-to-impossible. Looking at the very same thing from the opposite side – there is a reason why nobody is willing to work in call centers, and this is exactly related to the stress (which is inherently higher for synchronous communications such as chat/phone, than for asynchronous communications such as e-mails).
    • Time “on hold” is a biiiiig source of frustration for the customer for both live chat and phones.
    • Redirects from the 1st level support to upper levels – which are inevitable for any non-trivial request – are Really Ugly™ for live chat/phone (while being 100% invisible for e-mails).
      • Moreover – as upper-level support is not always-available – it often causes the customer to make multiple calls to deal with one single issue (ouch!). To make things even worse – it is extremely frustrating to the the customer to wait “on hold”, then to go via identification questions (with lots of spelling involved) – only to learn that the person-who-can-handle-it is not available, so she needs to call again <double-ouch! />.
    • Over-the-phone identification is extremely time consuming and error-prone; on the other hand, over e-mail it is rather trivial (those who tried to spell Rumpelstiltskin over the phone at least once, will be 100% on my side).
  • Compared to e-mails/tickets, live chat happens to be expensive, and phone support is even worse (that’s even taking into account lackluster salaries – and associated drop in support quality). The difference in efficiency between e-mail-handing CSRs (where a single 1st-level CSR – given right tools – can handle up to 200-300 hundred e-mails per shift), and live chat/phone CSRs (at most 100 and 50 interactions per shift respectively) – is just way too large to be ignored.5

Overall,

It is MUCH better to have a customer’s e-mail answered within 15 minutes with a good advice – than to force the same customer to wait for those 15 minutes on hold, just to get a reply “sorry, the only person who can answer your question, is busy with another customer6

5 Note that my numbers are even-more-favorable-for-e-mails the those found in [Hanke] – but I did observe such numbers first-hand. Plus, as noted above – synchronous methods often cause unnecessary second calls (which will bring overall performance of the live-chat or phone support even further down)
6 actually – spending her valuable time on trying to spell the name Rumpelstiltskin over the phone

 

Exceptions – when Live Chat/Phone are ok

That being said, I’ve seen Live Chat/Phone teams working well and efficiently; however – all of such instances had one very important property:

To be efficient – Live Chat/Phone should be initiated by your side, not by player.

Examples of such synchronous-support-initiated-by-your-side include such things as “there is a complicated problem,7 let’s schedule a phone call to discuss it“ and “hey, you have a problem depositing, let us help you over the phone”. And whenever the call is initiated by your side – most of the negatives of live-chat/phone go away (you can control expenses easily, your CSR is calling well-prepared, there are much less angry customers, etc.).


7 =“we’re about to ban you if you don’t provide a good explanation”

 

E-mails vs Tickets

B2B Business-to-business (B2B or, in some countries, BtoB) refers to a situation where one business makes a commercial transaction with another...B2B is often contrasted against business-to-consumer (B2C).— Wikipedia —After my broadside against synchronous support methods such as phone and live chat – let’s discuss the differences between asynchronous ones – e-mails and tickets. For these two – I am quite convinced that while tickets are perfectly fine for B2B support (such as your-admins-contacting-your-ISP), forcing your B2C customers/players into ticket system is not really realistic.

Actually, if you try to use tickets for your players – there are only two scenarios (which end essentially the same):

  • You DO provide a support e-mail in addition to ticket submission system. Then – you can be 100% sure, that lots of your players will send you e-mails without any ticket references, so you will still need to have a way to map e-mails into tickets very easily.
  • You DON’T provide such an e-mail (i.e. you ONLY support tickets). This is likely to cause too much frustration for your players, even more so if you’ll require your players to login into your support ticket app.
    • We should keep in mind that players are coming to your site to play, not to login-then-watch-in-a-separate-browser-window-for-your-helpdesk-replies-etc. Moreover – as players perceive a vast majority of the support requests to be your problems,8 requiring them to jump through the hoops just to complain about these problems, will pretty much inevitably be seen as “adding insult to injury” by a large portion of your player population. Sure, it will reduce your support load – but doing it at the cost of losing customer satisfaction is very rarely a good deal.

As a result –

While you MAY use “tickets” as an implementation detail – you MUST make sure that your Help Desk software handles incoming e-mails flawlessly and seamlessly.

Moreover, for B2C style of interactions I tend to prefer e-mail-centric systems to ticket-centric ones. While in fact both ticket-centric and e-mail-centric approaches may work, the ticket-based system implies that the customer restricts all the communications within one single ticket to one single topic; with real-world B2C customers, there is no way to ensure this style of communication, which in turn causes quite a bit of confusion. On the other hand, with e-mail-centric systems, the unit we’re dealing with, is ongoing conversation with one single player; this conversation tends to match player expectations much better than tickets which are rather-artificial-from-his-point-of-view.

Number of E-mails to Expect

Let me give you some numbers.

1, 2, 3, 4, 5, …

— undisclosed CEO —

To get an idea about the numbers of CSRs you’ll need – let’s provide a few numbers. For a game with 100K simultaneous players 24×7 – you can expect of the order of 10K e-mails per day (though YMMV greatly, plus keep in mind that the better your support is – the more e-mails you’ll get;9 still – spending more time on support usually qualifies as a very good investment, as good support clearly increases customer satisfaction).

Surprised hare:very roughly we’re speaking about 10-15 round-the-clock 1st-line CSRs per every 100K of your simultaneous players.As a 1st-line CSR (given good tools, at least along the lines discussed below) can handle about 25-35 e-mails per hour – very roughly we’re speaking about 10-15 round-the-clock 1st-line CSRs per every 100K of your simultaneous players.

1st-level CSRs will handle simple well-defined cases such as “I forgot my password” (no matter how prominent your login box shows “Forgot password?” – roughly half of your support e-mails will be about it), and will forward more complicated cases to the upper levels of support. Unfortunately, duties of the upper levels vary way too significantly to provide any estimates; in other words – you’ll need to find it out yourself.


8 regardless of whether it is actually the case
9 or the other way around – the worse support you have, the less people will want to use it for the 2nd time (preferring to abandon playing your game instead).

 

E-mail Help Desk: Features

As mentioned above – right tools are clearly The Key™ to make job of your CSRs (especially 1st-line CSRs) efficient.10 Moreover, the better tools you give them –> the more mundane work you will be able to take off their shoulders –> the more work satisfaction your CSRs will have –> the better people you’ll be able to hire as your CSRs -> the better support you will provide to your players. And this is beyond an obvious observation that the better tools your CSRs have – the better help they will be able to provide from a purely technical point of view.

As a result, you MUST NOT underestimate importance of your Help Desk software. In particular, the following features are IMO The Absolute Must™ for anything which dares to be named Help Desk:

  • From the player’s perspective – your Help Desk system SHOULD operate without the need to login to see the progress. Instead – as discussed above, systems which allow any player to get support using nothing but existing-player’s-e-mail are strongly preferred over those which require player to jump through the hoops of creating a separate HelpDesk account <ouch />.
    • Having web form as an optional way to get support is a completely different story – and is actually desirable (see also below on spam filters).
  • Inquisitive hare:From the CSR's perspective, serious support needs LOTS of stuffFrom the CSR’s perspective, serious support needs LOTS of stuff:
    • Anti-spam filter. While these days it is more-or-less standard feature – keep in mind that it should be tunable, and as a rule of thumb – it should be tuned on “it is MUCH better to let a bit of spam in, rather than to throw away legitimate e-mail”. In other words – make sure that your anti-spam filter is on a cautious side.
      • Your anti-spam filter MUST treat all known e-mail addresses (both those from previous conversations – and from your player accounts in your DB) – as white-listed.
      • Your anti-spam filter MUST store all the e-mails for a long time, and your system MUST automatically retrieve all-the-e-mails-from-spam-folder-which-came-from-email-address-X at the very moment when the CSR associates e-mail X with a player’s account.
      • Also, as no anti-spam filter can be made 100% free from “false positives”, you also MUST have a way to send you messages bypassing anti-spam filter; in practice – a form on your website with recaptcha, usually does the trick as such a supplementary way to contact you (just in case if your anti-spam filter gets overzealous-for-any-reason on this particular player)
    • Automated identification of incoming e-mails and associating them with the player account. In particular:
      • If a player was using this e-mail address either in a previous conversation, or it is listed in the player’s account itself, his e-mail MUST be automatically associated with the account (with no action by CSR required at all).
        • CSR should have an ability to override automated identification – but you should monitor how often it happens (to make sure that you automated identification algorithms are still in shape – and to fix the problems when they arise).
      • If there are two or more such players – all such accounts SHOULD be listed, so CSR can merely select one of them.
      • If the e-mail is coming completely “out of blue” – then it becomes a job of the CSR to associate it with a player’s account (and since this point, according to the rules above – all e-mails from this e-mail address MUST be associated automatically).
      • With this automated identification – the information about the associated player (AND about all the recent e-mails with this player) MUST be available to your CSR in at most one click. Normally – there should be at least two links easily available from the e-mail:
        • A link into Back-End Tools for all the information about this player
        • In addition – usually, a separate link should be available, leading to the list of all the e-mail exchanges with this player (regardless of the e-mail account where these e-mails came from, and regardless of the “tickets”)
        • Moreover – SOME of the information should be shown right there in the e-mail queue; at least – an associated player ID SHOULD be shown, but depending on your game, 2-3 additional parameters from player’s account should be also possible; what exactly to include – depends on typical CSR working patterns.
    • Based on this automated identification – your Help Desk software MUST allow both to prioritize and to color-code your e-mails when they’re shown in your e-mail queue. A more-or-less typical example of such prioritizing/color-coding:
      • Alerts from your monitoring system (as discussed in [[TODO]] section above, most of the time they SHOULD go into your e-mail queue) – highest priority, often shown in RED. Whenever seeing such an alert – CSR team should stop doing anything else and deal with the alert.
      • E-mails from those players which have VIP (“pro players”, “known reviewers/opinion leaders”, “troublemakers” etc.) flag set in their accounts (these flags should be settable by your CSRs manually). Usually e-mails from VIP players should have priority right after alerts, usually shown in GREEN.
      • E-mails from paying players. These are prioritized below VIPs, and are usually shown in default color (white?)
      • E-mails from not-yet-paying players. Priority-wise, these reside at the very bottom of the food chain, and are often shown in GREY.
    • Your Help Desk system MUST allow CSRs to “assign” an incoming e-mail to themselves (so that there are no two CSRs working on the same e-mail); this is also known as “Agent Collision Prevention”
      • If this “assigned” status still stays (without upgrading to some other status) when a shift of the corresponding CSR is over – it MUST be automatically dropped (otherwise you’ll get way too many e-mails which are “hanged-for-several-days-for-no-reason” – for example, if your CSR has forgot about a message – and left for vacation with several e-mails still assigned to him).
    • Your Help Desk system MUST allow to change status of the incoming e-mail. Moreover – some actions MUST allow to change status without unnecessary clicks.
      • For example, when CSR is answering an e-mail – your system SHOULD show “Change Status Of Incoming E-mail To:” field, with “REPLIED, NO FURTHER ACTION REQUIRED” status pre-selected by default. Once again, it is all about saving your CSRs from a bit of mundane work.
    • Judging hare:Your Help Desk system MUST have templates with canned responses well-integrated.Your Help Desk system MUST have templates with canned responses well-integrated. For example – instead of writing an individual response to ubiquitous “I lost my password” e-mail, your CSR MUST be able to select “Lost password” template from a drop-down list – and a draft e-mail should be automatically prepared. In this draft – a substitution of the fields from player’s account MUST be performed (for example, “Dear {$FirstName}” should be substituted with “Dear John,”) – and highlighted (so that CSR can easily double-check whether substitutions make sense).
      • If you really care about your CSRs – you can even go even further, and have heuristics which tries to guess what the e-mail is about – and offers the most-likely-guess in addition to the drop-down list of templates, saving your CSRs two clicks or so if automated guess is correct.
    • Your Help Desk system MAY allow to grab information from other sources such as support forums – and push them into the same Email Queue.
      • IMHO, when applied to public sources such as forums, the value of this feature is greatly exaggerated (in particular – replies in public forums SHOULD NOT be canned, and canned replies is a staple for e-mail processing).
      • On the other hand, integrating point-to-point conversations into your Email Queue (i.e. private messages sent to your social network account) is generally a good idea.
    • Last but not least – your Help Desk system MUST provide statistics on performance of your CSRs (as well as an easy ability to retrieve all the replies of a certain CSR over specified time frame).

If the features above look much-more-difficult-than-you-expected-from-an-e-mail-handling-system – that’s because the whole support process (replying to many thousands e-mails per day) is very far from being trivial.


10 Of course, training is also extremely important, but it is clearly outside of the scope of this book.

 

Implementation: SaaS vs In-House 3rd-party vs DIY

With the requirements laid out, we can start thinking about implementing our Help Desk system.

At least in theory, there are three distinct approaches to your Help Desk software:

  • SaaS Software as a service (SaaS) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted.— Wikipedia — Option 1. Using SaaS system (also known as “hosted” solutions) such as Zendesk or desk.com
    • Such systems are certainly the best choice from the point of view of the IT team (there is nothing to do there <wink />, except for paying money for the system). On the other hand – such systems tend to severely lack on integration options for your Email Queue. In particular:
      • Identification of incoming e-mails (against your DB) is usually lacking; even when it is possible to organize – it is going to be quite an effort involving synchronizing different DBs (yours and SaaS).
      • Prioritization and color coding is rarely (if ever) possible.
      • Any other access to your account DB (such as VIP flags, or data to be used in templates) is at worst impossible, and at best is a Big Headache™.
    • Overall – SaaS Help Desk will work, but unless you provide at least all the integration along the lines discussed above – your SaaS Help Desk will be able to provide neither above-average customer satisfaction, nor reasonable job satisfaction for your CSRs (and both these effects will amplify each other, leading to a downward spiral of overall dissatisfaction for both players and CSRs).
  • Option 2. Using 3rd-party Help Desk software hosted internally (this is also known as “in-house”, “self-hosted”, or “on-premise” Help Desk); examples include HelpSpot, Jitbit, and Kayako (with all three companies offering both SaaS and self-hosted options).
    • I have to admit that I don’t know much about on-premise-but-3rd-party help desks, but my current understanding is that you’ll have somewhat better chances to integrate them with your system properly. Still – make sure to take a closer look and to consider how specific-integrations-scenarios-mentioned-above can be implemented with their system. In this regard, (a) automated identification of incoming e-mails based both on previous e-mails and data in your DB, and (b) ability to integrate information-from-your-DB into their screens, including prefilling-templates from fields in your DB are especially important.
    • Oh, and it has been reported that on-premise systems are often much less expensive than SaaS ones.
  • Option 3. As always, a DIY option provides the best flexibility and – if you spend enough time on it – the best experience for both your CSRs and your players. Moreover, starting from about (very roughly) 100K simultaneous players – the savings on CSR time tend to outweigh IT costs, and as customer satisfaction for a properly-implemented DIY Help Desk tends to be significantly better than alternatives; it means that for larger games DIY Help Desk becomes a pure win.
    • Once, I’ve seen a fully-DIY e-mail handing system with most of the functionality mentioned above (plus LOTS of game-specific bells and whistles too). Not incidentally, their support was commonly regarded as by far the best thing in the industry.
    • Still, for smaller games (those which do not even try to reach 100K simultaneous players) it is hardly wise to spend time on DIY-ing your own Help Desk software.

TL;DR for Help Desk

Let’s summarize our observations about Help Desk software:

  • Support is Really Important™ for MOGs
  • Primary support channel SHOULD be centered around e-mails (or other asynchronous one-to-one communications such as private messages over social media)
    • While replying in public forums should an important part of your efforts – they are too different from one-to-one conversations such as e-mails, so as a rule of thumb they should be handled separately.
  • Hare pointing out:Your Help Desk software SHOULD be highly optimized for the very specific tasks your CSRs are facingYour Help Desk software SHOULD be highly optimized for the very specific tasks your CSRs are facing. While these tasks are very game-dependent, there are a few common tasks which SHOULD be automated for a pretty much any game:
    • Identifying incoming e-mails
      • This includes an ability to open a player profile within your main DB in one single click
    • Prioritizing and color-coding of incoming e-mails
    • Preparing drafts from custom templates (with fields pre-filled from the players account)
  • As for the ways to implement your Help Desk – unfortunately, there is no silver bullet:
    • SaaS solutions (which are dime a dozen these days) are the simplest for IT, but their lack of customization leads to: (a) mundane repetitive work for CSRs, which in turn leads to (b) loss of CSR productivity, and (c) loss of satisfaction both for customers and for CSRs.
    • On-premise (a.k.a. in-house or self-hosted) 3rd-party Help Desk systems are a bit better customization-wise – at the cost of higher IT efforts.
    • The ultimate experience (both for CSRs and your customers) is provided by a completely DIY Help Desk system – but it is hardly worth the trouble for smaller games (very roughly – those below 100K simultaneous players).

[[To Be Continued…

Tired hare:This concludes beta Chapter 26(b) from the upcoming book “Development and Deployment of Multiplayer Online Games (from social games to MMOFPS, with social games in between)”.

Stay tuned for beta Chapter 26(c), where we’ll discuss access control to our Admin Tools]]

Don't like this post? Comment↯ below. You do?! Please share: ...on LinkedIn...on Reddit...on Twitter...on Facebook

Acknowledgement

Cartoons by Sergey GordeevIRL from Gordeev Animation Graphics, Prague.

Join our mailing list:

Comments

  1. says

    That second Hare from the left is just pretending to be holding up a game world. I find that very fitting for CSR.

    I’ll say something about On-premise systems. You have to pay for updates, but if you’re willing to take ownership of the software, you can save huge amounts of money. We use Kayako, although it’s called Kayako “Classic” now. They tried to kill the On-premise product, but there was massive backlash. Kayako “classic” is a bit buggy, but the source is actually very well commented. Kayako is kinda legacy in our case. If we were starting from scratch, we’d find an open source system, although I have no hands on experience with this.

    • "No Bugs" Hare says

      When speaking about open source Help Desk – way too often people tend to imply that Help Desk == Bug Tracking , and these are VERY different. For example, http://blog.capterra.com/the-7-best-free-help-desk-software-tools/ mentions Bugzilla and Mantis as open source Help Desk – gimme a break :-(. And even those systems which are real Help Desk ones (osTicket) – look as way-too-much ticket-centric (and as players won’t fit into tickets – it will become a detriment both for CSRs and players, see above re. “e-mails vs tickets”).

      • says

        Ah, if that’s the state of open source CRS that’s a shame. As I said I don’t have experience with open source alternatives. In theory, you could use these open source projects as a starting point, no? It’d probably be better than trying to use something bloated and enterprise like Kayako as a starting point and hopefully easier than starting with only a framework.

        • "No Bugs" Hare says

          > hopefully easier than starting with only a framework.

          In general – maybe, but if the system is inherently ticket-oriented and we want an e-mail-oriented one (and I argue above that for B2C businesses such as games we DO want e-mail-oriented, or more precisely – conversation-oriented support system) – it is unclear what is simpler: to start from scratch or to wrestle ticket system into submission 🙁 (in particular, SQL requests can become REALLY ugly for a DB which is not optimized for e-mail searches).

Leave a Reply

Your email address will not be published. Required fields are marked *