/draft-response

Si vous voyez des placeholders non familiers ou avez besoin de vérifier quels outils sont connectés, consultez CONNECTORS.md.

Rédigez une réponse professionnelle, destinée au client, adaptée à la situation, la relation client et le contexte de communication.

Utilisation

/draft-response <contexte sur la question, le problème ou la demande du client>

Exemples :

• /draft-response Acme Corp demande quand la nouvelle fonctionnalité de tableau de bord sera livrée
• /draft-response Escalade client — leur intégration est down depuis 2 jours
• /draft-response Répondre à une demande de fonctionnalité que nous ne construirons pas
• /draft-response Le client a rencontré une erreur de facturation et veut une résolution ASAP

Workflow

1. Comprendre le contexte

Analysez l'entrée utilisateur pour déterminer :

• Client : À qui s'adresse la communication ? Consultez le contexte du compte si disponible.
• Type de situation : Question, problème, escalade, annonce, négociation, mauvaise nouvelle, bonne nouvelle, suivi
• Urgence : Est-ce urgent ? Depuis combien de temps le client attend-il ?
• Canal : Email, ticket support, chat ou autre (ajustez le degré de formalité en conséquence)
• Stade de la relation : Nouveau client, établi, frustré/escaladé
• Niveau des parties prenantes : Utilisateur final, manager, cadre exécutif, technique, métier

2. Rechercher le contexte

Rassemblez les informations pertinentes auprès des sources disponibles :

~~email :

• Correspondance antérieure avec ce client sur ce sujet
• Tous les engagements ou délais précédemment partagés
• Ton et style du thread existant

~~chat :

• Discussions internes sur ce client ou ce sujet
• Tous les conseils des équipes produit, engineering ou leadership
• Situations similaires et comment elles ont été gérées

~~CRM (si connecté) :

• Détails du compte et niveau de plan
• Informations de contact et principales parties prenantes
• Escalades antérieures ou problèmes sensibles

~~plateforme support (si connectée) :

• Tickets associés et leur résolution
• Problèmes connus ou contournements
• Statut SLA et engagements de temps de réponse

~~base de connaissances :

• Documentation officielle ou articles d'aide à référencer
• Informations de feuille de route produit (si partageables)
• Documentation des politiques ou processus

3. Générer le brouillon

Produisez une réponse adaptée à la situation :

## Brouillon de réponse

**À :** [Nom du contact client]
**Objet :** [Sujet/thème]
**Canal :** [Email / Ticket / Chat]
**Ton :** [Empathique / Professionnel / Technique / Enthousiaste / Franc]

---

[Texte du brouillon de réponse]

---

### Notes pour vous (interne — ne pas envoyer)
- **Pourquoi cette approche :** [Justification des choix de ton et de contenu]
- **Éléments à vérifier :** [Faits ou engagements à confirmer avant envoi]
- **Facteurs de risque :** [Tout ce qui est sensible dans cette réponse]
- **Suivi nécessaire :** [Actions à prendre après envoi]
- **Note d'escalade :** [Si cela doit d'abord être examiné par quelqu'un d'autre]

4. Effectuer des vérifications qualité

Avant de présenter le brouillon, vérifiez :

• [ ] Le ton correspond à la situation et à la relation
• [ ] Aucun engagement au-delà de ce qui est autorisé
• [ ] Aucun détail de feuille de route produit qui ne doit pas être partagé à l'externe
• [ ] Références exactes aux conversations antérieures
• [ ] Prochaines étapes claires et propriété bien définie
• [ ] Approprié pour le niveau des parties prenantes (pas trop technique pour les cadres, pas trop vague pour les ingénieurs)
• [ ] La longueur est appropriée pour le canal (plus court pour le chat, plus complet pour l'email)

5. Proposer des itérations

Après avoir présenté le brouillon :

• « Voulez-vous que j'ajuste le ton ? (plus formel, plus décontracté, plus empathique, plus direct) »
• « Dois-je ajouter ou supprimer des points spécifiques ? »
• « Voulez-vous que je fasse cela plus court/plus long ? »
• « Dois-je rédiger une version pour une autre partie prenante ? »
• « Voulez-vous que je rédige aussi la note d'escalade interne ? »
• « Dois-je préparer un message de suivi à envoyer après [X jours] en cas d'absence de réponse ? »

Meilleures pratiques de communication client

Principes fondamentaux

1. Commencez par l'empathie : Reconnaissez la situation du client avant de passer aux solutions
2. Soyez direct : Allez droit au but — les clients sont occupés. Les informations clés d'abord.
3. Soyez honnête : N'overpromettez jamais, ne trompez jamais, ne cachez jamais les mauvaises nouvelles derrière du jargon
4. Soyez spécifique : Utilisez des détails concrets, des délais et des noms — évitez le langage vague
5. Prenez la responsabilité : Assumez la responsabilité quand approprié. « Nous » plutôt que « le système » ou « le processus »
6. Fermez la boucle : Chaque réponse doit avoir une prochaine étape claire ou un appel à l'action
7. Adaptez-vous à leur énergie : S'ils sont frustrés, soyez d'abord empathique. S'ils sont enthousiastes, soyez enthousiaste.

Structure de réponse

Pour la plupart des communications client, suivez cette structure :

1. Reconnaissance / Contexte (1-2 phrases)
   - Reconnaissez ce qu'ils ont dit, demandé ou vivent
   - Montrez que vous comprenez leur situation

2. Message principal (1-3 paragraphes)
   - Livrez l'information principale, la réponse ou la mise à jour
   - Soyez spécifique et concret
   - Incluez les détails pertinents dont ils ont besoin

3. Prochaines étapes (1-3 puces)
   - Ce que VOUS ferez et d'ici quand
   - Ce qu'ILS doivent faire (le cas échéant)
   - Quand ils auront de vos nouvelles

4. Conclusion (1 phrase)
   - Signature chaleureuse mais professionnelle
   - Renforcez que vous êtes disponible si nécessaire

Directives de longueur

• Chat/IM : 1-4 phrases. Allez droit au but.
• Réponse à ticket support : 1-3 courts paragraphes. Structuré et scannable.
• Email : Maximum 3-5 paragraphes. Respectez leur boîte aux lettres.
• Réponse d'escalade : Aussi long que nécessaire pour être complet, mais bien structuré avec des en-têtes.
• Communication exécutive : Plus court c'est mieux. Maximum 2-3 paragraphes. Basé sur les données.

Directives de ton et style

Spectre de ton

Ajustements de ton par stade de relation

Nouveau client (0-3 mois) :

• Plus formel et professionnel
• Contexte et explication supplémentaires (ne supposez pas la connaissance)
• Proposez proactivement aide et ressources
• Créez la confiance par la fiabilité et la réactivité

Client établi (3+ mois) :

• Chaleureuse et collaborative
• Vous pouvez référencer l'historique partagé et les conversations antérieures
• Communication plus directe et efficace
• Montrez la sensibilisation à leurs objectifs et priorités

Client frustré ou escaladé :

• Empathie et reconnaissance supplémentaires
• Urgence dans les temps de réponse
• Plans d'action concrets avec engagements spécifiques
• Boucles de rétroaction plus courtes

Règles de style de rédaction

À FAIRE :

• Utilisez la voix active (« Nous enquêterons » plutôt que « Ceci sera enquêté »)
• Utilisez « je » pour les engagements personnels et « nous » pour les engagements d'équipe
• Nommez les personnes spécifiques lors de l'attribution d'actions (« Sarah de notre équipe engineering va... »)
• Utilisez la terminologie du client, pas votre jargon interne
• Incluez des dates et heures spécifiques, pas des termes relatifs (« d'ici vendredi 24 janvier » et non « dans quelques jours »)
• Divisez les réponses longues avec des en-têtes ou des puces

À NE PAS FAIRE :

• Utilisez le jargon d'entreprise ou les termes à la mode (« synergy », « leverage », « paradigm shift »)
• Rejetez la responsabilité à d'autres équipes, systèmes ou processus
• Utilisez la voix passive pour éviter la responsabilité (« Des erreurs ont été commises »)
• Incluez des mises en garde ou des hésitations inutiles qui sapent la confiance
• CC des personnes inutilement — incluez seulement celles qui doivent être dans la conversation
• Utilisez excessivement les points d'exclamation (un maximum par email, le cas échéant)

Approches pour situations spécifiques

Répondre à une question produit :

• Commencez par la réponse directe
• Fournissez des liens de documentation pertinents
• Proposez de les connecter à la bonne ressource si nécessaire
• Si vous ne connaissez pas la réponse : dites-le honnêtement, engagez-vous à trouver, donnez un délai

Répondre à un problème ou bug :

• Reconnaissez l'impact sur leur travail
• Indiquez ce que vous savez sur le problème et son statut
• Fournissez un contournement si disponible
• Définissez les attentes du délai de résolution
• Engagez-vous à fournir des mises à jour à intervalles réguliers

Gérer une escalade :

• Reconnaissez la gravité et leur frustration
• Assumez la propriété (pas de déflexion ou d'excuses)
• Fournissez un plan d'action clair avec délai
• Identifiez la personne responsable de la résolution
• Proposez une réunion ou un appel si approprié pour la gravité

Livrer les mauvaises nouvelles (coucher de soleil de fonctionnalité, retard, impossibilité à corriger) :

• Soyez direct — ne cachez pas la nouvelle
• Expliquez le raisonnement honnêtement
• Reconnaissez l'impact spécifiquement sur eux
• Offrez des alternatives ou des atténuations
• Fournissez un chemin clair à suivre

Partager de bonnes nouvelles (lancement de fonctionnalité, jalon, reconnaissance) :

• Commencez par le résultat positif
• Connectez-le à leurs objectifs ou cas d'usage spécifiques
• Suggérez les prochaines étapes pour capitaliser sur la bonne nouvelle
• Exprimez un véritable enthousiasme

Refuser une demande (demande de fonctionnalité, remise, exception) :

• Reconnaissez la demande et son raisonnement
• Soyez honnête sur la décision
• Expliquez le pourquoi sans être rebutant
• Offrez des alternatives quand possible
• Laissez la porte ouverte pour une future conversation

Modèles de réponse pour scénarios courants

Reconnaître un rapport de bug

Bonjour [Nom],

Merci d'avoir signalé ceci — je comprends comment [impact spécifique] serait
frustrante pour votre équipe.

J'ai confirmé le problème et l'ai escaladé à notre équipe engineering en tant que
[niveau de priorité]. Voici ce que nous savons jusqu'à présent :
- [Ce qui se passe]
- [Ce qui le cause, si connu]
- [Contournement, si disponible]

Je vous ferai un point d'ici [date/heure spécifique] avec un délai de résolution.
Entre-temps, [détails du contournement si applicable].

Faites-moi savoir si vous avez des questions ou si cela vous impacte d'autres façons
que je devrais connaître.

Cordialement,
[Votre nom]

Reconnaître un problème de facturation ou de compte

Bonjour [Nom],

Merci de m'avoir contacté à ce sujet — je comprends que les problèmes de facturation
nécessitent une attention rapide, et je veux m'assurer que cela soit résolu rapidement.

J'ai examiné votre compte et voici ce que je constate :
- [Ce qui s'est passé — explication factuelle claire]
- [Impact sur leur compte — frais, accès, etc.]

Voici ce que je fais pour corriger cela :
- [Action 1 — avec délai]
- [Action 2 — si applicable]

[Si la résolution est immédiate : « Ceci a été corrigé et vous devriez voir le changement
reflété dans [délai]. »]
[Si nécessite une enquête : « J'escalade ceci à notre équipe facturation et je vous ferai
un point d'ici [date spécifique]. »]

Je suis désolé pour le désagrément. Faites-moi savoir si vous avez des questions sur
votre compte.

Cordialement,
[Votre nom]

Répondre à une demande de fonctionnalité que vous ne construirez pas

Bonjour [Nom],

Merci d'avoir partagé cette demande — je comprends pourquoi [capacité] serait
utile pour [leur cas d'usage].

J'en ai parlé avec notre équipe produit, et ce n'est pas quelque chose que nous
prévoyons de construire à court terme. La raison principale est [explication honnête
et respectueuse — par exemple, cela sert un cas d'usage étroit, c'est en conflit avec
notre direction architecturale, etc.].

Cela dit, je veux m'assurer que vous pouvez atteindre votre objectif. Voici quelques
alternatives :
- [Approche alternative 1]
- [Approche alternative 2]
- [Intégration ou contournement si applicable]

J'ai aussi documenté votre demande dans notre système de feedback, et si notre
direction change, je vous le ferai savoir.

L'une de ces alternatives fonctionnerait-elle pour votre équipe ? Je suis heureux de
creuser plus profondément dans l'une d'elles.

Cordialement,
[Votre nom]

Communication de panne ou d'incident

Bonjour [Nom],

Je voulais vous contacter directement pour vous informer d'un problème affectant
[service/fonctionnalité] dont je sais que votre équipe dépend.

**Ce qui s'est passé :** [Explication claire, non technique]
**Impact :** [Comment cela vous affecte spécifiquement]
**Statut :** [Statut actuel — enquête / identifié / correction / résolu]
**ETA pour résolution :** [Heure spécifique si connue, ou « nous ferons un point toutes les X heures »]

[Si applicable : « Entre-temps, vous pouvez [contournement]. »]

Je suive ceci personnellement et vous ferai un point dès que nous aurons une résolution.
Vous pouvez aussi consulter [URL de la page de statut] pour les mises à jour en temps réel.

Je suis désolé pour la disruption du travail de votre équipe. Nous prenons cela au sérieux
et [ce que vous faites pour prévenir la réitération si connu].

[Votre nom]

Suivi après silence

Bonjour [Nom],

Je voulais prendre des nouvelles — j'ai envoyé [ce que vous avez envoyé] le [date] et
voulais m'assurer que ça n'ait pas été perdu.

[Bref rappel de ce dont vous avez besoin d'eux ou de ce que vous offrez]

Si maintenant n'est pas un bon moment, pas de problème — faites-moi juste savoir quand
ce serait mieux, et je suis heureux de nous reconnecter à ce moment.

Cordialement,
[Votre nom]

Conseils de suivi et d'escalade

Cadence de suivi

Quand escalader

Escaladez à votre manager quand :

• Le client menace d'annuler ou de réduire significativement
• Le client demande une exception à une politique que vous ne pouvez pas autoriser
• Un problème est resté non résolu plus longtemps que le SLA le permet
• Le client demande un contact direct avec le leadership
• Vous avez commis une erreur nécessitant l'implication des cadres supérieurs pour résoudre

Escaladez à produit/engineering quand :

• Le bug est critique et bloque l'activité du client
• Le manque de fonctionnalité entraîne une perte compétitive
• Le client a des exigences techniques uniques au-delà du support standard
• Les problèmes d'intégration nécessitent une enquête engineering

Format d'escalade :

ESCALADE : [Nom du client] — [Résumé en une ligne]

Urgence : [Critique / Élevée / Moyenne]
Impact client : [Ce qui est cassé pour eux]
Historique : [Contexte bref — 2-3 phrases]
Ce que j'ai essayé : [Actions entreprises jusqu'à présent]
Ce dont j'ai besoin : [Aide ou décision spécifique nécessaire]
Échéance : [Quand cela doit être résolu d'ici]