Rédigez un modèle de support que votre équipe peut utiliser correctement

Choisissez le travail du modèle avant de choisir son libellé

Commencez par l'événement qui déclenche la réponse et la progression que le client devrait réaliser après l'avoir lu. Un accusé de réception confirme la réception ; une demande d’informations débloque une enquête ; une mise à jour du statut explique ce qui est connu ; une clôture enregistre le résultat. Combiner les quatre tâches dans une réponse universelle peut créer des paragraphes non pertinents et des promesses accidentelles.

Notez le canal, l'audience, les faits connus, les informations que l'agent doit obtenir et l'équipe autorisée à faire des exceptions. Ajoutez l’extrait de politique approuvé si la réponse en dépend. Les conseils de style de Microsoft distinguent une voix cohérente d'un ton adapté à la situation du client. Utilisez cette distinction pour varier la chaleur sans changer la règle.

Créez une fiche de modèle, pas seulement un bloc de texte

Pour un service logiciel fictif, imaginez qu'un client signale qu'un fichier exporté ne s'ouvrira pas. L'équipe a besoin du format d'exportation, de l’heure approximative de la tentative et d'une description de l'erreur. La politique illustrative ne nécessite pas de mots de passe ni d’ensembles de données client complets. Un modèle utile demande les détails de diagnostic manquants et explique pourquoi ils sont nécessaires.

La fiche ci-dessous ci-dessous est une spécification pour votre propre bibliothèque de support. Il s'agit de champs suggérés et non d'une affirmation selon laquelle Colay contient un gestionnaire de modèles de support technique.

Demandez un premier brouillon utilisable et un cas d'exception

Dans Colay, comparez les brouillons des agents sélectionnés en utilisant le même brief. L'un peut écrire une meilleure ouverture tandis qu'un autre détecte une condition manquante. Jugez-les par rapport à la carte plutôt que de traiter le paragraphe le plus raffiné comme un modèle opérationnel complet. Un petit nombre de variantes utiles suffit pour commencer.

Créez une fiche de modèle d'assistance pour [événement et objectif client]. Canal et tonalité : [détails]. Faits et politique approuvés : [source]. Informations obligatoires : [champs]. Ne demandez pas : [données sensibles ou inutiles]. Renvoyez un nom de modèle court, les conditions d'utilisation, les variables requises, le brouillon destiné au client, les notes internes et les conditions de remontée d'informations. Conservez les notes internes en dehors du message client. Fournissez un brouillon concis et un autre plus explicatif avec les mêmes engagements. Ajoutez un cas fictif où le modèle s'adapte et un autre où il ne doit pas être utilisé. Marquez les règles manquantes comme des questions ; n'inventez pas une promesse de délai de réponse ou une décision de remboursement.

Tester le modèle à ses limites

Pour l'exemple d'exportation, un incident de service déjà confirmé doit conduire à la mise à jour de l'incident approuvée plutôt qu'à un autre questionnaire de diagnostic. Cette limite fait partie de la valeur du modèle. Cela aide une équipe à éviter de traiter un brouillon réutilisable comme une instruction pour ignorer le contexte.

1. Remplissez chaque variable avec des valeurs fictives et lisez le résultat en tant que client. Corrigez les phrases qui ne fonctionnent que lorsqu'un espace réservé reste abstrait.
2. Essayez un cas où le client a déjà fourni la moitié des informations demandées. Supprimez les demandes répétées et les alternatives non pertinentes.
3. Essayez un cas en dehors des conditions autorisées. Confirmez que la carte indique à l'agent de choisir une autre réponse ou de faire remonter le problème.
4. Demandez au responsable du support approprié d'approuver le libellé et les règles, puis enregistrez le modèle dans votre système existant avec un responsable et une date de révision.

Maintenir une petite bibliothèque de réponses distinctes

Nommez les modèles en fonction de leur tâche, par exemple demande de détails d'exportation manquants, plutôt que d'étiquettes vagues telles que réponse amicale deux. Conservez la formulation faisant autorité au même endroit et archivez les versions remplacées via votre processus normal. Si plusieurs modèles ne diffèrent que par un message d'accueil, envisagez un modèle avec une note claire sur le ton.

Examinez les commentaires réels et les modifications apportées à plusieurs reprises par les agents. Un paragraphe fréquemment supprimé peut appartenir à un bloc facultatif ; une exception répétée peut nécessiter son propre modèle. Utilisez à nouveau Colay lorsque vous avez un brief de révision concret. L'objectif est une rédaction moins répétitive avec des décisions plus claires, et non une bibliothèque qui se développe plus rapidement que l'équipe ne peut la maintenir.

Questions, réponses