Help Desk Software for MOGs

	Author:	“No Bugs” Hare  Follow:
	Job Title:	Sarcastic Architect
	Hobbies:	Thinking Aloud, Arguing with Managers, Annoying HRs, Calling a Spade a Spade, Keeping Tongue in Cheek

[rabbit_ddmog vol=”7″ chap=”Chapter 26(b) from “beta” Volume VII”]

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):¹

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 MOGs², however, situation changes drastically (Table 26.2):³

As we can see –

“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:

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).

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,

There are two Big Reasons™ for it:

• “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 1^st 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 1^st-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.⁵

Overall,

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:

Examples of such synchronous-support-initiated-by-your-side include such things as “there is a complicated problem,⁷ 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.).

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,⁸ 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 –

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

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;⁹ still – spending more time on support usually qualifies as a very good investment, as good support clearly increases customer satisfaction).

“very roughly we’re speaking about 10-15 round-the-clock 1^st-line CSRs per every 100K of your simultaneous players.As a 1^st-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 1^st-line CSRs per every 100K of your simultaneous players.

1^st-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.

E-mail Help Desk: Features

As mentioned above – right tools are clearly The Key™ to make job of your CSRs (especially 1^st-line CSRs) efficient.¹⁰ 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).
• “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.
  • “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.

Implementation: SaaS vs In-House 3^rd-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 3^rd-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-3^rd-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.
• “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) 3^rd-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…

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:

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.