Quand un ticket de support est aussi une transaction
Les questions des marchands concernent presque toujours une transaction, un paiement ou une facture précise. Dans un helpdesk généraliste externe au panneau de paiement, un ticket démarre comme une conversation vierge, et l'agent doit copier les références de transaction, les identifiants marchand et les dates entre deux systèmes avant même de pouvoir examiner la demande.
Ouvrir un ticket là où se trouve déjà l'enregistrement
Un marchand peut au contraire ouvrir un ticket directement depuis la transaction, la facture ou le wallet qu'il consulte, afin que la référence suive la conversation au lieu d'y être collée. L'opérateur qui traite le ticket a sous les yeux l'enregistrement réel, pas une capture d'écran ni un identifiant recopié.
Une seule file, les mêmes permissions
Les gestionnaires de tenant traitent la file de support directement dans leur propre panneau, sous le même contrôle d'accès basé sur les rôles qui régit le reste de leurs droits. Le personnel de support n'a pas besoin de droits élargis pour simplement répondre à une question, et il n'y a ni double connexion, ni configuration SSO distincte, ni second emplacement de stockage des données personnelles des marchands.
Un stockage partagé plutôt qu'un second système de fichiers
Les pièces jointes telles que les reçus et justificatifs utilisent le même stockage documentaire et les mêmes routes de téléchargement que les preuves de litige. Rien n'a besoin d'être dupliqué dans un second système, et rien ne se perd entre une pièce jointe et l'enregistrement qu'elle est censée appuyer.
Ce que cela change au quotidien
Comme les tickets sont rattachés au tenant et mis en file directement dans la plateforme, le reporting sur les délais de réponse est une propriété native de la plateforme plutôt qu'une reconstitution après coup à partir de deux systèmes. Et comme les tickets s'ouvrent depuis leur contexte, une catégorie d'erreur disparaît : la mauvaise référence de transaction copiée dans la mauvaise conversation.
Une couche optionnelle, et la place des litiges
Au-dessus de la boîte de réception support, un module distinct peut trier les tickets entrants et préparer des réponses suggérées fondées sur le même contexte de transaction et de marchand que celui déjà visible par l'opérateur — l'opérateur reste seul à modifier et envoyer, rien n'est transmis automatiquement au marchand. Cette couche s'articule avec le workflow de litiges propre à la plateforme, où un marchand peut ouvrir un litige sur un paiement ou un versement avec un motif et jusqu'à cinq pièces justificatives, et où un gestionnaire le résout avec des soldes annulés puis réimputés automatiquement — gardant ainsi la conversation de support et le litige qui peut en découler au même endroit.
