Reviewflowz répond à vos avis App Store. Zendesk reçoit les exceptions.

Une note brute n'est pas un avis App Store. L'API d'Apple ne renvoie que les entrées avec du texte, donc tout ce qui vous arrive contient quelque chose d'écrit, et la plupart de ce quelque chose dit « appli sympa » ou trois mots sur la dernière mise à jour. Une personne qui lit ça est une personne qui ne lit pas l'avis une étoile.

Une liste ordonnée de règles décide de ce qui se publie tout seul. Définissez une règle par note, par présence de texte, par profil ou par plateforme. La première règle qui correspond l'emporte, vingt maximum, et une règle par défaut en bas retient tout ce que rien d'autre n'a attrapé.

L'agent n'invente pas un ton. Pour chaque avis, il récupère cinq à dix de vos propres réponses passées, filtrées selon la tranche de note et la langue, et en imite une comme ancre stylistique. Les réponses postées dans App Store Connect avant que vous ayez un compte font partie de ce vivier.

Chaque réponse qu'il publie seul atterrit dans la vue Non lus de votre file, taguée avec l'agent et la règle qui l'a envoyée. Un pouce levé la classe. Un pouce baissé indique ce qui n'allait pas.

Les avis App Store ne sont pas les seuls à avoir besoin d'une personne. Les avis Google sur vos sites, les avis Trustpilot sur votre site web et les avis Google Play sur la version Android veulent tous la même chose, de la même équipe, dans le même ton.

Ils ouvrent le même type de ticket : les mêmes tags Reviewflowz, la même priorité fixée selon la note, le même demandeur. Un agent les traite avec les macros et les vues déjà construites, et rien sur le ticket ne lui demande d'apprendre un second outil.

Une réponse publique sur le ticket repart vers la source. Google, l'App Store, Google Play et Trustpilot acceptent une réponse directement depuis Reviewflowz une fois la connexion configurée. Google Play limite une réponse à 350 caractères, donc les brouillons visent 320 et tout ce qui dépasse est condensé avant l'envoi.

Là où une plateforme n'a pas d'API de réponse, le ticket porte un lien qui ouvre plutôt l'avis sur le site, et le corps précise laquelle. Un flux d'assistance ne crée aussi par défaut un ticket que pour les avis contenant du texte, donc les notes brutes cinq étoiles sur une fiche Google n'atteignent jamais la file.

Apple classe chaque avis sous la vitrine où le client a acheté l'appli, et la plupart du temps dans la langue de cette vitrine. Reviewflowz garde le territoire sur l'avis, pour qu'un flux puisse ouvrir des tickets pour les vitrines dont une équipe s'occupe et laisser les autres tranquilles.

Choisissez une langue sur le flux et le corps du ticket reste dans la langue d'origine, avec la traduction ajoutée en note privée intitulée « Translated review ». Seuls les agents la voient. Elle n'atteint jamais le client, et ne se publie jamais sur l'App Store.

Le brouillon s'écrit dans la langue de l'auteur, à partir des réponses déjà publiées dans cette langue, parce que la langue est l'un des filtres selon lesquels les réponses passées sont récupérées. Même si vous n'avez jamais répondu en japonais, il rédige quand même, à partir de ce qu'il a.

Chaque ticket porte la langue de l'avis comme tag : reviewflowz_ja, reviewflowz_pt, reviewflowz_de. Un déclencheur Zendesk sur ce tag envoie chaque langue aux agents qui la lisent.

Les avis App Store n'arrivent pas de façon régulière. Ils se concentrent dans les heures qui suivent une sortie et les jours qui suivent une mise en avant, et une version cassée se manifeste par une série d'avis une étoile sur quelques territoires avant que votre outil de suivi des crashs ne le confirme.

Reviewflowz interroge App Store Connect à peu près toutes les deux heures et envoie à deux et trente-deux minutes après l'heure. Les règles de réponse et les flux d'assistance s'exécutent sur le même cycle, donc les quatre et cinq étoiles sont traités et le ticket est ouvert dans le même passage.

Ça veut dire que le ticket est ouvert pendant que les ingénieurs sont encore à leur poste plutôt que dans le résumé du lendemain matin. Apple met jusqu'à 24 heures pour afficher une réponse de développeur, donc ce délai démarre à la réponse, pas au moment où quelqu'un a fini par penser à aller vérifier.

Un avis modifié s'ajoute au même ticket sous forme de fil : une note privée intitulée « Updated review », le tag reviewflowz_updated, et le ticket rouvre s'il avait été résolu. Un ticket par avis, tenu à jour, quel que soit le nombre de fois où l'auteur change d'avis.