L'IA pour le support client des jeux vidéo : quoi automatiser après chaque patch

Pourquoi le support joueurs explose-t-il après chaque patch ?

Parce qu'un patch change ce que voient des milliers de joueurs le même jour, et que chaque changement crée une nouvelle question à laquelle votre centre d'aide n'a pas encore répondu. Une nouvelle version casse le parcours de connexion sur une plateforme, un objet disparaît d'un inventaire, la fiche de la boutique affiche l'ancien prix, et le même ticket arrive 400 fois avant midi.

Je construis les intégrations d'eesel, et durant les années où eesel fait tourner de l'IA sur des files de support réelles, le schéma est toujours le même : la première heure après une sortie ne contient pas de questions difficiles, c'est une seule question posée de nombreuses fois avec des mots légèrement différents. C'est le genre de travail qu'une IA bien ancrée fait bien et qu'un agent fatigué fait mal, car au ticket 60 il retape la même solution de contournement.

Avant d'écrire ceci, j'ai posé à ChatGPT la question qu'enverrait un responsable du support joueurs : nous sommes submergés de tickets sur des achats perdus, des bannissements de compte, des bugs, des remboursements et des problèmes de connexion, et cela explose après chaque patch ; l'IA peut-elle en gérer une partie et que faut-il laisser à un humain ? Il a lu les pages jeux vidéo de fournisseurs de helpdesk comme Helpshift, Zendesk et Ada, ainsi qu'un guide AWS pour les développeurs de jeux. La réponse était sensée : l'IA gère l'information et les processus, les humains gèrent le jugement, les exceptions et la responsabilité. Aucune de ces pages n'a regardé les règles de remboursement des boutiques dont dépend la réponse, ni montré à quoi ressemble une base de connaissances versionnée par patch. C'est ce vide que je comble ici.

Les joueurs ressentent le coût d'une erreur d'une façon bien précise. Un commentateur d'un fil Hacker News sur les bannissements automatisés l'a dit sans détour :

"Algorithmic customer support “decisions” should always be appealable to a human audience."

buildbuildbuild, Hacker News

Cette phrase est la règle de conception du reste de ce guide : automatisez les réponses, jamais les verdicts.

Quels tickets de joueurs l'IA peut-elle traiter, rédiger ou laisser à un humain ?

Triez chaque ticket avec une seule question : la réponse est-elle un fait qu'on peut retrouver, un brouillon que quelqu'un devrait vérifier, ou un jugement sur une personne ? Les faits que l'IA peut lire dans vos documents, elle y répond. Tout ce qui demande une commande, un compte ou un journal reçoit un brouillon qu'un humain envoie. Les verdicts, la sécurité et les exceptions d'argent restent humains.

Voici la répartition pour les cinq tickets que partage toute file de joueurs :

La colonne de droite n'est pas là parce que l'IA écrit mal. Elle est là parce que ce sont les messages où une mauvaise réponse coûte son compte à un joueur ou de l'argent à vous. Mes guides sur l'IA pour la récupération de compte et l'IA pour le support lié à la fraude couvrent plus en détail le volet vérification.

Autre distinction à faire tôt : qui est le joueur. Un parent qui écrit à propos de l'achat de son enfant, un streamer avec un bannissement et un joueur avec une sauvegarde corrompue sont tous des « tickets », mais ils ne portent pas le même risque. Si un message mentionne un mineur, une menace ou de l'automutilation, il saute le tableau de tri et va à une personne formée. Plus de détails plus bas.

Essayez-le sur les cinq types :

Pourquoi la version du jeu décide-t-elle de la réponse ?

Parce que « la boutique est cassée » ne veut pas dire la même chose sur le build 2.4.0 et sur le 2.4.1, et qu'une IA qui ne connaît pas le build citera la mauvaise solution de contournement. La version, la plateforme et la boutique sont les trois champs qui transforment un message vague en ticket routable.

Voici le minimum que je mettrais sur chaque ticket de joueur avant qu'une IA n'y touche :

Les joueurs tapent rarement ces informations. C'est pourquoi le bouton d'aide dans le jeu compte : il peut joindre automatiquement le build, la plateforme et l'ID du joueur, et l'IA trie alors sur des faits plutôt que sur des suppositions. Un SDK d'aide conçu pour les jeux, comme celui que propose Helpshift, peut les joindre nativement, et dans d'autres helpdesks vous pouvez transmettre les mêmes champs comme champs personnalisés du ticket. Un évaluateur de Helpshift sur G2 a décrit honnêtement le coût pour y arriver :

"There's a lot of manual work that has to happen to set up all the automation tags, custom fields, and everything."

Helpshift reviewer, G2

C'est une limite honnête à prévoir : les champs sont le travail, quel que soit l'outil. Une bonne configuration de tri automatique lit ces champs pour router, et mon guide des outils d'IA pour le tri des tickets compare les options.

À quoi ressemble une base de connaissances versionnée par patch ?

Elle ressemble à des notes de version que votre IA peut lire, avec le numéro de version et la date attachés à chaque entrée. Les studios les publient déjà. Dota 2, par exemple, tient une page pour chaque mise à jour de gameplay avec un sélecteur de version, de sorte que 7.41f est un autre document que 7.41e.

Reprenez cette habitude dans votre centre d'aide. Chaque problème connu reçoit quatre lignes : le symptôme avec les mots du joueur, les builds concernés, la solution de contournement et le build qui le corrige. L'IA répond alors à « mon achat n'est pas apparu après la mise à jour » avec la note du build du joueur, et dit « c'est corrigé dans la 2.4.2 » seulement si le joueur n'y est pas encore. Si le build n'est pas connu, elle doit poser la question, pas supposer. Des notes écrites ainsi fonctionnent avec un RAG simple, et elles évitent qu'une IA cite la solution de contournement du mois dernier, un risque que j'explique dans éviter les hallucinations de l'IA.

Comment survivre au pic de tickets après un patch ?

Regrouper d'abord, répondre une fois, mettre à jour une fois. Quand la version sort, l'IA regroupe les tickets entrants par version du jeu et par symptôme, si bien que 400 messages deviennent quatre problèmes. Vous écrivez une note de problème connu par problème, l'IA répond à partir d'elle, et quand le correctif sort, vous modifiez cette unique note.

Les étapes que je suivrais le jour de la sortie :

1. Avant le patch : informez l'équipe et l'IA de ce qui a changé. Collez les notes de patch dans la base de connaissances, avec une étiquette de version.
2. Première heure : surveillez les tickets entrants pour repérer de nouveaux groupes. Mon guide de la déduplication de tickets par IA montre comment relier les doublons à un seul incident.
3. Écrivez la note de problème connu : symptôme, builds, solution de contournement, build du correctif. Un humain l'approuve.
4. Laissez l'IA répondre à partir d'elle, et continuez d'envoyer à un humain tout ce qui sort de la note. Informez aussi les joueurs de la situation sur votre page de statut, pour que moins d'entre eux écrivent.
5. Quand le correctif sort : mettez la note à jour, et l'IA cesse de citer la solution de contournement. Pour les pannes graves, le plan plus large se trouve dans l'IA pour la communication lors d'incidents majeurs.

Les fournisseurs qui vendent aux studios mettent en avant des résultats ici, et il faut les lire avec la prudence habituelle, car ils sont rapportés par le fournisseur lui-même. La page de tarifs de Helpshift présente des études de cas comme celle de Subway Surfers de SYBO, qui atteint un taux d'automatisation de 77 % et un CSAT de 4,3 en moins de trois mois, et celle de Zynga, qui traite 185 % de tickets en plus. Ce sont les chiffres d'un fournisseur sur sa propre plateforme, et je les considère comme la preuve que les files de jeux vidéo s'automatisent bien, pas comme un chiffre que votre studio atteindra.

Les tickets de bugs méritent leur propre voie, car « ça a planté » est le début d'une conversation avec la QA, pas une réponse de support. Je traite ce transfert dans l'IA pour le tri des rapports de bugs et l'IA pour le tri des bugs. La règle est simple : l'IA recueille la plateforme, le build et les étapes, et un humain décide si c'est nouveau.

Qui est propriétaire d'un remboursement, vous ou la boutique ?

En général la boutique. Quand un joueur achète via Apple, Google Play, Steam, PlayStation ou Xbox, la boutique a encaissé l'argent et ses règles régissent le remboursement. Votre équipe de support explique où s'adresser et répare ce qui était réellement cassé.

J'ai lu la page de politique de chaque boutique pour cela. Les règles diffèrent davantage que ne l'admettent la plupart des macros de support :

Deux détails changent la façon de configurer une IA. Sur Google Play, les remboursements après 48 heures relèvent de vous, ce qui veut dire que ces tickets ont besoin d'une règle écrite et d'un humain pour l'appliquer. Et sur Steam, la possibilité pour un joueur de se faire rembourser un achat intégré dépend d'un réglage que vous contrôlez en tant que développeur, votre réponse doit donc y correspondre.

Le rôle de l'IA est donc une réponse d'aiguillage : « Vous avez acheté ceci sur PlayStation, qui gère les remboursements d'achats numériques dans les 14 jours si le jeu n'a pas commencé à se télécharger ; voici comment le demander. » Elle ne doit jamais promettre un remboursement que la boutique n'a pas accordé. Si la boutique a refusé et que le joueur pense toujours que c'est votre faute, le brouillon va à un humain. La même logique s'applique aux rétrofacturations et aux litiges de paiement, et mon guide général de l'IA pour les demandes de remboursement donne la formulation.

Les achats perdus sont les cousins des remboursements. Les App Review Guidelines d'Apple demandent aux développeurs de prévoir un mécanisme de restauration pour les achats intégrés restaurables et précisent que la monnaie de jeu achetée ne peut pas expirer. La première réponse à « mon achat a disparu » est donc une étape de restauration, et une IA peut la donner à chaque fois.

Pourquoi les recours contre un bannissement et les piratages de compte restent-ils à un humain ?

Parce que les deux sont des jugements sur un être humain, avec des preuves que vous ne pouvez pas vérifier entièrement dans un chat. Un bannissement est un verdict. Une déclaration de piratage, ce sont deux personnes qui affirment chacune que le compte est le leur. Une IA peut aider à rassembler les faits sans pour autant être celle qui décide.

Valve est franc sur le premier point. Le support Steam indique que les bannissements VAC sont permanents, ne peuvent pas faire l'objet d'un recours et ne sont pas levés par le support Steam ; un bannissement jugé erroné est levé automatiquement. C'est une politique qu'un studio peut adopter, mais elle montre ce que doit être une réponse sur un bannissement : un énoncé clair de ce que dit la politique, rédigé par quelqu'un qui en répond. Un bot qui se montre sûr de lui sur un bannissement est un risque, et le fil Hacker News cité plus haut, sur les bannissements automatisés par un anti-triche, regorge de joueurs décrivant des recours qui n'ont mené nulle part.

La récupération de compte est le point sur lequel les fournisseurs divergent. Helpshift soutient dans son article sur la récupération de compte que des agents IA peuvent résoudre de bout en bout la plupart des demandes de récupération et d'achat en pesant les reçus d'achat, l'historique des appareils et les comptes liés, et qu'un humain intervient à mesure que le risque augmente. Je pense que c'est une conception raisonnable quand les preuves sont solides. Ma règle est plus stricte : l'IA peut recueillir et vérifier les preuves, et un humain approuve toute étape qui donne un compte à quelqu'un d'autre. Un « oui » à tort remet les achats d'un joueur à un inconnu, et un « non » à tort coûte quelques heures. Cette asymétrie est tout l'argument. Plus de détails sur le volet preuves dans l'IA pour le support de récupération de compte.

Ce que l'IA peut faire sur ces deux voies, c'est la préparation :

• Rassembler le motif du bannissement, la date et l'historique du compte dans un court résumé.
• Lister ce que le joueur a déjà essayé et ce que la récupération standard a donné.
• Rédiger une réponse calme et exacte qui énonce la politique et la prochaine étape.
• Étiqueter le ticket et définir la bonne file, avec une note d'escalade qu'un réviseur peut exploiter en une seule lecture.

C'est la même forme que celle décrite dans mon guide de l'IA pour le support de niveau 2 : l'IA est l'enquêteur qui fait gagner dix minutes au réviseur, pas le juge.

J'ai entendu l'objection presque mot pour mot lors d'appels commerciaux eesel. Un responsable CX d'une marque DTC de compléments alimentaires sur Gorgias et Shopify, avec environ 7 000 tickets par mois, nous a dit que l'IA ne répondrait jamais à tout, et que ce dont il avait besoin, c'était d'une IA qui ne traite que les tickets dont elle est sûre et laisse les autres de côté. Les files de jeux vidéo ont besoin du même interrupteur, et un score de confiance plus une liste de types de tickets que l'IA ne doit jamais toucher est le moyen de le construire.

Et les menaces, le harcèlement et la sécurité des joueurs ?

Ils vont directement à une personne formée, sans réponse de l'IA entre-temps. Un joueur qui écrit sur l'automutilation, une menace contre un autre joueur ou du harcèlement de la part d'un coéquipier ne pose pas une question de support. Une mauvaise réponse automatique cause alors un dommage qu'aucun remboursement ne peut réparer.

Fixez trois règles avant le lancement. Première règle, une courte liste d'expressions et de catégories déclencheuses qui routent vers un humain d'emblée (menaces, automutilation, protection de l'enfance, divulgation de données personnelles). Deuxième règle, une consigne selon laquelle l'IA n'envoie aucune réponse sur ces tickets, seulement un signalement interne. Troisième règle, un responsable d'astreinte en dehors des heures de bureau, car les jeux tournent les week-ends et la nuit. Mes guides sur l'IA pour la couverture du support le week-end et l'IA pour les réclamations clients aident ici, tout comme une revue avec intervention humaine de ce que l'IA a signalé.

La confidentialité compte aussi : les tickets de joueurs contiennent des e-mails, des identifiants d'appareil et parfois l'âge. Si vos joueurs sont dans l'UE ou au Royaume-Uni, faites passer les demandes de données par le processus décrit dans mon guide de l'IA pour les demandes RGPD, et examinez le fournisseur au regard de votre liste de contrôle de sécurité.

Combien coûte l'IA pour le support des jeux ?

Cela va d'une plateforme pour studios sur devis uniquement à un prix mensuel publié, et les unités ne sont pas les mêmes, alors comparez par ticket. Voici ce que j'ai pu lire sur les pages de chaque fournisseur :

Pour un acheteur précis, disons un studio avec 2 000 tickets et chats par mois : le forfait de 2 000 crédits d'eesel coûte 849 $, soit environ 0,42 $ pièce. Sur Zendesk, si l'IA résolvait entièrement les 2 000 au tarif avec engagement, vous paieriez 3 000 $ pour les seules résolutions, et cela avant les licences d'agents, donc la vraie comparaison dépend de votre taux de résolution. Voyez mon détail des tarifs de l'IA de Zendesk et le calcul du coût d'un agent IA par rapport à un agent humain.

Une limite honnête de mon côté : eesel ne se branche pas sur Helpshift ni sur un SDK intégré au jeu. Si toute votre file vit là, regardez les alternatives à Helpshift et l'avis sur l'IA de Helpshift avant de décider. Si vous utilisez Zendesk, Freshdesk, HubSpot ou Gorgias, il fonctionne dans le helpdesk que vous avez déjà, comme dans mes guides de l'IA pour Zendesk et l'IA pour Freshdesk.

Comment mettre cela en place en une semaine ?

Commencez par une plateforme et un type de ticket, avec l'IA qui rédige dans des notes internes et ne répond seule à rien les premiers jours. Activez ensuite les réponses que vos tests prouvent sûres.

1. Jour 1 : connectez le helpdesk et la base de connaissances. Ajoutez les notes de patch avec versions et dates.
2. Jour 2 : rédigez le tableau des cinq tickets ci-dessus sous forme de règles écrites, y compris la liste des tickets auxquels l'IA ne doit jamais répondre.
3. Jour 3 : rejouez les tickets de votre dernier patch comme test. Mon guide des tests par simulation montre comment ; c'est ainsi qu'eesel vérifie chaque déploiement sur des tickets historiques avant sa mise en service.
4. Jours 4 à 5 : l'IA rédige, vos agents envoient. Lisez les brouillons et corrigez les notes.
5. Semaine 2 : laissez l'IA répondre directement aux tickets « restaurer », « problème connu » et « quelle boutique », et gardez tout le reste en brouillon.

Trois clients d'eesel illustrent les briques, aucun n'étant un studio de jeux, lisez-les donc comme des schémas :

• MentorShow, un abonnement d'apprentissage en ligne, fait lire à eesel chaque nouveau ticket HubSpot, rédiger une analyse et un brouillon dans la langue du membre, et signaler à un humain les remboursements, les vérifications de facturation et les changements de compte. En un mois, il a rédigé 432 réponses sur environ 1 200 conversations et tickets. C'est la voie de vos brouillons sur les achats perdus et les connexions.
• ClutchLoop, une marque d'accessoires de téléphone, envoie les retours et les remboursements vers son portail de retours et répond directement aux questions sur les produits. En un mois, elle a répondu directement à 180 des 230 tickets Gorgias, soit environ sept sur dix. C'est votre schéma « la boutique est propriétaire du remboursement ».
• SamCart, qui vend des logiciels pour produits numériques, fait tourner un agent eesel sur les tickets Freshdesk et un autre sur le chat du site web, chacun répondant depuis le même centre d'aide et s'arrêtant quand un humain prend le relais. C'est votre séparation entre e-mail et chat dans le jeu.

Si vous gérez aussi un volet communautaire, mon guide de l'automatisation du support communautaire par IA et l'article sur la recherche dans le centre d'aide couvrent les endroits où les joueurs posent leurs questions avant d'ouvrir un ticket. Et si votre équipe est petite et que la charge du jour de patch se résume surtout à des pics, les guides de la dotation en personnel du support et de la réduction du temps de traitement montrent où passent les heures. Pour les tickets destinés aux développeurs qui débordent sur le support, voyez l'IA pour le support aux développeurs.

Essayer eesel pour le support des joueurs

Si vos tickets vivent dans Zendesk, Freshdesk, HubSpot ou Gorgias, le coéquipier IA de helpdesk d'eesel rejoint cette file comme un nouvel embauché qui a lu vos notes de patch. Il répond aux questions sur les problèmes connus et les restaurations à partir de notes versionnées, rédige les réponses sur les bugs et les connexions avec la plateforme et le build renseignés, et passe les bannissements, les piratages et les signalements de sécurité à votre équipe. Vous pouvez le tester sur les tickets de la semaine dernière avant qu'il ne réponde à un seul joueur : essayez eesel gratuitement ou réservez une démo.