Un workflow d'appel d'assistance vers un ticket ne doit pas dépendre de ce dont l'agent se souvient après que le client a raccroché.
C’est lors de l’appel que le véritable problème apparaît.
Le client explique ce qui s'est cassé. Ils mentionnent le navigateur, le compte, le message d'erreur, la solution de contournement qu'ils ont essayée et le délai qui rend le problème urgent. L'agent pose des questions, teste des hypothèses et promet la prochaine étape.
Puis l'appel se termine.
Si le ticket démarre depuis la mémoire, les détails utiles commencent immédiatement à fuir.
Le résultat est un ticket qui dit :
"Le client a appelé. Problème de connexion. Enquête."
Cela ne suffit pas pour obtenir du soutien.
C'est un fil d'Ariane.
Quand l’assistance téléphonique doit devenir des tickets utilisables
Transformez les appels d'assistance en résultats prêts à recevoir des tickets
Superscribe Phone capture les appels et les transforme en tickets révisés, notes, suivis, tâches et contexte facturable au lieu d'une autre transcription à nettoyer plus tard.
La version courte
Un workflow d'appel d'assistance vers un ticket doit capturer sept éléments :
- le problème exact du client
- l'utilisateur, le compte, l'appareil, le système ou l'environnement concerné
- les étapes déjà essayées
- ce que l'agent a testé lors de l'appel
- l’impact actuel et l’urgence
- le prochain propriétaire et la prochaine action
- que faut-il répondre au client
L’enregistrement ou la transcription de l’appel est un document source.
Le ticket est un contexte de travail.
Cette différence est importante car la prochaine étape d’assistance peut avoir lieu des heures plus tard, par une autre personne, dans un autre système. Si le ticket ne contient pas le contexte d’appel utile, l’équipe doit poser à nouveau les mêmes questions au client.
C’est ainsi que le support semble plus lent qu’il ne l’est réellement.
Pourquoi les tickets d'assistance téléphonique sont rares
Les appels d’assistance sont compliqués, contrairement au chat et aux e-mails.
Le client ne décrit pas toujours le problème dans l'ordre. Ils se souviennent d'un message d'erreur au milieu de l'appel. Ils mentionnent un deuxième utilisateur concerné vers la fin. Ils disent « cela arrive tous les matins », mais précisent seulement plus tard que cela a commencé après une réinitialisation du mot de passe.
Pendant ce temps, l'agent effectue trois tâches :
- à l'écoute du client
- dépannage en direct
- j'essaie de laisser une trace utile pour plus tard
Le troisième emploi est celui qui perd généralement.
Pas parce que les agents sont négligents.
Parce que l’appel a déjà absorbé toute l’attention.
Après l'appel, il peut y avoir un autre élément de file d'attente, un autre client, une autre escalade ou une mise à jour promise. La note du ticket devient une version compressée de la mémoire :
- "L'utilisateur ne peut pas se connecter."
- "Problème d'imprimante."
- "VPN en panne."
- "Le client dit que l'application est lente."
- "Besoin que le développeur vérifie."
Ces notes sont techniquement des tickets.
Ce ne sont pas de bons transferts.
Un ticket a un travail différent d'une transcription
Une transcription préserve ce qui a été dit.
Un ticket explique ce qui doit se passer ensuite.
Des outils tels que Zendesk et Jira Service Management offrent aux équipes des emplacements pour stocker les champs, les commentaires, les statuts, les types de demandes et le contexte interne (Documents pour développeurs Zendesk, Assistance Atlassian).
Le stockage n’est pas le goulot d’étranglement.
Le goulot d’étranglement consiste à transformer l’appel en contenu de ticket approprié avant que les détails ne soient flous.
Un ticket d'assistance utile devrait répondre :
- Qu'est-ce qui est cassé ?
- Qui est concerné ?
- À quel point est-ce grave ?
- Comment quelqu’un peut-il le reproduire ou l’enquêter ?
- Qu'est-ce qui a déjà été essayé ?
- Quelle est la prochaine action ?
- Qu’attend le client ensuite ?
C’est pourquoi les notes d'appel ne sont pas des transcriptions. La transcription peut être complète, mais le ticket doit être utilisable.
Le flux de travail : appel, structurer, réviser, acheminer
Le workflow d'appel à ticket d'assistance le plus propre comporte quatre étapes.
1. Capturez l'appel
L'appel devrait être la source de la vérité.
Pas une note à moitié écrite.
Pas la mémoire de l’agent après le prochain appel.
La capture est importante car de petits détails changent le ticket. Le « problème de connexion » devient très différent lorsque le client déclare que cela ne se produit que sur un ordinateur portable géré, uniquement après SSO, uniquement lorsqu'il est connecté au Wi-Fi de l'hôtel ou uniquement pour les utilisateurs occupant un seul rôle.
Ces détails déterminent s'il s'agit d'un ticket de réinitialisation de mot de passe, d'un problème de fournisseur d'identité, d'un problème de réseau, d'un bug d'autorisation ou d'un moment de formation du client.
Si la source est faible, le ticket démarre faible.
2. Structurer le contexte d'accompagnement
Le texte brut d’un appel est trop lourd pour un ticket.
Le ticket nécessite une version façonnée de l'appel :
- Résumé du problème : la version la plus courte et précise du problème
- Impact client : qui est bloqué et pourquoi c'est important
- Environnement: compte, appareil, navigateur, version, emplacement, intégration ou système
- Symptômes : comportement, erreur, timing ou modèle exact
- Étapes essayées : ce que le client et l'agent ont déjà testé
- Indices de reproduction : qu'est-ce qui fait que ça se reproduise
- Action suivante : propriétaire, action et mise à jour attendue
- Remarque destinée au client : ce que le client devrait entendre ensuite
Il s'agit de la couche qui transforme un appel d'assistance en un ticket sur lequel quelqu'un peut agir.
3. Examinez avant que le ticket ne devienne la mémoire de l'équipe
Ne placez pas les notes brutes générées directement dans une file d’attente de tickets.
Les appels d'assistance incluent souvent des suppositions, des détails de compte sensibles, de la frustration, des diagnostics partiels et des notes internes privées. Le ticket doit préserver un contexte utile sans transformer chaque phrase en histoire officielle.
L'examen fait la différence entre :
- « L'authentification unique est interrompue. »
- "Le client signale un échec de connexion SSO pour deux utilisateurs. Besoin de vérifier les journaux du fournisseur d'identité. "
La première est une conclusion non prouvée.
L'autre est un ticket d'assistance.
4. Acheminez la sortie là où le travail se déroule
Le ticket doit atterrir dans le système où l’équipe travaillera réellement.
S'il s'agit d'un problème de support, créez ou mettez à jour le ticket. S’il nécessite une ingénierie, incluez les étapes de reproduction et l’impact. S'il a besoin du succès du client, préservez les attentes et la mise à jour promise. Si cela crée du temps d’assistance facturable, conservez le motif tant qu’il est encore récent.
C'est le même schéma derrière une forte flux de travail d'appel commercial de suivi. L'appel n'est pas terminé lorsque le client raccroche. Il est terminé lorsque la sortie utile atteint le flux de travail suivant.
Un modèle de ticket d’assistance pratique
Utilisez-le si vous rédigez toujours des tickets manuellement après des appels.
Résumé du problème :
Impact client :
Utilisateur, compte ou système concerné :
Environnement :
Symptômes :
Étapes déjà essayées :
Indices de reproduction :
Action suivante :
- Propriétaire :
- Heure d'échéance ou de mise à jour :
Mise à jour destinée au client :
Contexte interne :
Voici une version remplie.
Résumé du problème :
L'utilisateur ne peut pas effectuer la connexion SSO à partir d'un ordinateur portable géré.
Impact client :
Le responsable financier ne peut pas approuver les factures avant la clôture d'aujourd'hui.
Utilisateur, compte ou système concerné :
Compte Acme. Utilisateur : responsable financier. Appareil : MacBook de la société.
Environnement :
Chromé. Le Wi-Fi de bureau et le point d’accès mobile ont tous deux été testés.
Symptômes :
La connexion redirige vers SSO, puis revient à l'application avec une page vierge. Aucune erreur de mot de passe affichée.
Étapes déjà essayées :
Cache du navigateur vidé. J'ai essayé incognito. Confirmé qu'un autre utilisateur sur le même compte peut se connecter.
Indices de reproduction :
Commencé après que le service informatique du client a modifié les règles du fournisseur d'identité hier.
Action suivante :
- Propriétaire : la prise en charge passe à l'examen des journaux d'identité.
- Heure d'échéance ou de mise à jour : le client s'attend à une mise à jour dans les deux heures.
Mise à jour destinée au client :
Nous vérifions le transfert SSO et vous tiendrons au courant avant 15 heures.
Contexte interne :
Sensible au facteur temps car il bloque l’approbation des factures. Ne pas encore considérer comme une panne d'application confirmée.
Ce ticket donne à la personne suivante un point de départ.
Cela empêche également le client de répéter l’intégralité de l’appel.
Ce qui ne devrait pas figurer dans le ticket
Un bon ticket de support n’est pas un dépotoir.
Laissez de côté :
- de longues sections de transcription qui n'affectent pas l'action suivante
- des suppositions écrites comme des faits
- remplissage émotionnel de l'appel
- détails privés du client qui ne sont pas nécessaires
- blâme interne
- cause première non vérifiée
Le ticket doit être spécifique, mais pas bruyant.
Si la transcription complète de l’appel est nécessaire ultérieurement, conservez-la comme source. Le ticket principal doit contenir la version prête à l'emploi.
Où Superscribe s'intègre
Superscribe Phone est conçu pour les appels qui génèrent du travail.
Pour les équipes d'assistance et les petits opérateurs de services, cela signifie que l'appel peut devenir une note de ticket révisée, une tâche, un suivi, une mise à jour CRM, un contexte d'escalade ou une piste d'assistance facturable.
Il ne s’agit pas de créer une plus jolie transcription.
Il s’agit de raccourcir le chemin entre l’appel téléphonique et le ticket utile.
Lorsque l'appel crée du travail en dehors du système téléphonique, Superscribe Desktop couvre la couche suivante. Vous pouvez dicter le transfert d'ingénierie, la mise à jour client, la note interne ou l'explication de la facture directement dans le champ auquel il appartient.
Les appels créent le contexte. La dictée de bureau capture le suivi.
Ce pont est important pour la même raison les rapports d'incidents automatiques à partir des appels de support matière. Le travail de support n’est aussi efficace que le transfert qu’il laisse derrière lui.
Avant que le prochain appel d'assistance n'écrase celui-ci
Capturez le contexte du ticket alors qu'il est frais
Utilisez Superscribe Phone lorsque les appels d'assistance doivent devenir des tickets examinés, des notes, des suivis et un contexte facturable.
FAQ
Qu’est-ce qu’un workflow d’appel d’assistance vers un ticket ?
Un workflow d'appel d'assistance vers un ticket capture une conversation d'assistance téléphonique, extrait le contexte du problème utile, l'examine et l'achemine vers le système de ticket avec les propriétaires et les étapes suivantes.
Une transcription d’appel est-elle suffisante pour un ticket d’assistance ?
Généralement non. Une transcription préserve la conversation, mais un ticket nécessite un résumé concis du problème, l'impact, l'environnement, l'historique de dépannage, des indices de reproduction et une action suivante.
Que doit inclure un ticket d’assistance suite à un appel téléphonique ?
Il doit inclure le problème, l'utilisateur ou le système concerné, l'impact sur le client, les symptômes, les étapes déjà essayées, les indices de reproduction, le propriétaire, l'action suivante et la mise à jour destinée au client.
Les tickets d’assistance doivent-ils être créés automatiquement à partir des appels ?
Ils peuvent être rédigés automatiquement, mais les tickets importants doivent quand même être examinés avant qu’ils ne deviennent la mémoire de l’équipe. L'examen est l'endroit où vous détectez des diagnostics non vérifiés, des détails sensibles et des promesses peu claires.