/customer-escalation

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

Packagez un problème de support dans un brief d'escalade structuré pour l'ingénierie, le produit ou la direction. Rassemble le contexte, structure les étapes de reproduction, évalue l'impact métier et identifie le bon destinataire de l'escalade.

Utilisation

/customer-escalation <description du problème> [nom du client ou compte]

Exemples :

• /customer-escalation L'API retourne des erreurs 500 par intermittence pour Acme Corp
• /customer-escalation L'export de données manque des lignes — 3 clients l'ont signalé cette semaine
• /customer-escalation Boucle de connexion SSO affectant tous les clients Enterprise
• /customer-escalation Client menace de partir à cause de la fonctionnalité de journal d'audit manquante

Flux de travail

1. Comprendre le problème

Analysez l'entrée et déterminez :

• Ce qui ne fonctionne pas ou manque : Le problème technique ou produit essentiel
• Qui est affecté : Client(s) spécifique(s), segment ou tous les utilisateurs
• Depuis combien de temps : Quand cela a commencé ? Depuis combien de temps le client attend-il ?
• Ce qui a été essayé : Tout dépannage ou contournement tentés
• Pourquoi escalader maintenant : Qu'est-ce qui justifie une attention au-delà du support normal

Utilisez les critères « Quand escalader vs. gérer au support » ci-dessous pour confirmer que cela justifie une escalade.

2. Rassembler le contexte

Regroupez les informations pertinentes à partir des sources disponibles :

• ~~plateforme de support : Tickets liés, chronologie des communications, dépannage précédent
• ~~CRM (si connecté) : Détails du compte, contacts clés, escalades antérieures
• ~~chat : Discussions internes sur ce problème, signalements similaires d'autres clients
• ~~suivi de projet (si connecté) : Rapports de bogues ou demandes de fonctionnalités liés, statut ingénierie
• ~~base de connaissances : Problèmes connus ou contournements, documentation pertinente

3. Évaluer l'impact métier

En utilisant les dimensions d'impact ci-dessous, quantifiez :

• Portée : Combien de clients/utilisateurs affectés ? En croissance ?
• Profondeur : Bloquant ou gênant ?
• Durée : Depuis combien de temps cela dure-t-il ?
• Revenu : ARR en risque ? Deals en attente affectés ?
• Pression temporelle : Délai limite ?

4. Déterminer la cible d'escalade

En utilisant les niveaux d'escalade ci-dessous, identifiez la bonne cible : L2 Support, Ingénierie, Produit, Sécurité ou Direction.

5. Structurer les étapes de reproduction (pour les bogues)

Si le problème est un bogue, suivez les bonnes pratiques des étapes de reproduction ci-dessous pour documenter les étapes de repro claires avec les détails de l'environnement et les preuves.

6. Générer le brief d'escalade

## ESCALADE : [Résumé en une ligne]

**Sévérité :** [Critique / Élevée / Moyenne]
**Équipe cible :** [Ingénierie / Produit / Sécurité / Direction]
**Signalé par :** [Votre nom/équipe]
**Date :** [Date d'aujourd'hui]

### Impact
- **Clients affectés :** [Qui et combien]
- **Impact sur le flux de travail :** [Ce qu'ils ne peuvent pas faire]
- **Revenu en risque :** [Si applicable]
- **Temps en attente :** [Depuis combien de temps c'est un problème]

### Description du problème
[Description claire et concise du problème — 3-5 phrases]

### Ce qui a été essayé
1. [Étape de dépannage et résultat]
2. [Étape de dépannage et résultat]
3. [Étape de dépannage et résultat]

### Étapes de reproduction
[Si applicable — suivez le format ci-dessous]
1. [Étape]
2. [Étape]
3. [Étape]
Attendu : [X]
Réel : [Y]
Environnement : [Détails]

### Communication client
- **Dernière mise à jour au client :** [Date et ce qui a été communiqué]
- **Attente client :** [Ce qu'ils attendent et à quelle date]
- **Risque d'escalade :** [Escaladeront-ils davantage s'il n'est pas résolu avant X ?]

### Ce qui est nécessaire
- [Demande spécifique — « enquêter sur la cause racine », « prioriser la correction »,
  « prendre une décision produit sur X », « approuver exception pour Y »]
- **Délai :** [Quand cette résolution ou mise à jour est-elle nécessaire]

### Contexte de soutien
- [Tickets liés ou liens]
- [Fils de discussion internes]
- [Documentation ou journaux]

7. Proposer les prochaines étapes

Après avoir généré l'escalade :

• « Voulez-vous que je l'envoie dans un ~~canal de chat pour l'équipe cible ? »
• « Dois-je donner une réponse provisoire au client ? »
• « Voulez-vous que je configure un rappel de suivi ? »
• « Dois-je rédiger une mise à jour destinée au client avec le statut actuel ? »

Quand escalader vs. gérer au support

Gérer au support quand :

• Le problème a une solution documentée ou un contournement connu
• C'est un problème de configuration ou de configuration que vous pouvez résoudre
• Le client a besoin de conseils ou de formation, pas d'une correction
• Le problème est une limitation connue avec une alternative documentée
• Les tickets similaires précédents ont été résolus au niveau du support

Escalader quand :

• Technique : Bogue confirmé nécessitant une correction de code, enquête infrastructure nécessaire, corruption ou perte de données
• Complexité : Problème au-delà de la capacité de diagnostic du support, accès que le support n'a pas, impliquant une implémentation personnalisée
• Impact : Plusieurs clients affectés, système de production en panne, intégrité des données en risque, préoccupation de sécurité
• Métier : Client de haut valeur en risque, violation SLA imminente ou survenue, client demandant une implication exécutive
• Temps : Ticket ouvert au-delà du SLA, client attendant depuis trop longtemps, canaux normaux du support ne progressent pas
• Pattern : Même problème signalé par 3+ clients, problème récurrent censé être corrigé, sévérité croissante au fil du temps

Niveaux d'escalade

L1 → L2 (Escalade support)

De : Support frontline À : Senior support / spécialistes du support technique Quand : Problème nécessitant une enquête plus approfondie, connaissances produit spécialisées ou dépannage avancé À inclure : Résumé du ticket, étapes déjà essayées, contexte client

L2 → Ingénierie

De : Senior support À : Équipe Ingénierie (domaine produit pertinent) Quand : Bogue confirmé, problème infrastructure, change code nécessaire, enquête système requise À inclure : Étapes de reproduction complètes, détails environnement, journaux ou messages d'erreur, impact métier, chronologie client

L2 → Produit

De : Senior support À : Product management Quand : Écart de fonctionnalité causant une douleur client, décision design nécessaire, flux de travail ne correspond pas aux attentes client, besoins clients concurrents nécessitant priorisation À inclure : Cas d'usage client, impact métier, fréquence de la demande, pression concurrentielle (si connue)

Tout → Sécurité

De : Tout niveau de support À : Équipe Sécurité Quand : Exposition de données potentielle, accès non autorisé, rapport de vulnérabilité, préoccupation de conformité À inclure : Ce qui a été observé, qui/quoi est potentiellement affecté, étapes de confinement immédiat prises, évaluation urgence Note : Les escalades sécurité contournent la progression normale des niveaux — escaladez immédiatement peu importe votre niveau

Tout → Direction

De : Tout niveau (généralement L2 ou manager) À : Leadership support, équipe exécutive Quand : Client à haut revenu menaçant de partir, violation SLA sur compte critique, décision interfonctionnelle nécessaire, exception à la politique requise, risque PR ou légal À inclure : Contexte métier complet, revenu en risque, ce qui a été essayé, décision ou action spécifique nécessaire, délai

Évaluation de l'impact métier

Lors de l'escalade, quantifiez l'impact si possible :

Dimensions d'impact

Notation abrégée de sévérité

• Critique : Production en panne, données en risque, violation sécurité, ou plusieurs clients de haut valeur affectés. Nécessite attention immédiate.
• Élevée : Fonctionnalité majeure non fonctionnelle, client clé bloqué, SLA en risque. Nécessite attention le même jour.
• Moyenne : Problème significatif avec contournement, impact métier important mais non urgent. Nécessite attention cette semaine.

Rédaction des étapes de reproduction

Les bonnes étapes de reproduction sont la chose la plus précieuse dans une escalade de bogue. Suivez ces pratiques :

1. Commencez à partir d'un état propre : Décrivez le point de départ (type de compte, configuration, permissions)
2. Soyez spécifique : « Cliquez sur le bouton Export en haut à droite de la page Dashboard » pas « essayez d'exporter »
3. Incluez les valeurs exactes : Utilisez des entrées, dates, IDs spécifiques — pas « entrez certaines données »
4. Notez l'environnement : Navigateur, OS, type de compte, feature flags, niveau plan
5. Capturez la fréquence : Toujours reproductible ? Intermittent ? Seulement sous certaines conditions ?
6. Incluez la preuve : Captures d'écran, messages d'erreur (texte exact), journaux réseau, sortie console
7. Notez ce que vous avez éliminé : « Testé dans Chrome et Firefox — même comportement » « Pas spécifique au compte — reproduit sur compte test »

Cadence de suivi après escalade

N'escaladez pas et n'oubliez pas. Maintenez la propriété de la relation client.

Actions de suivi

• Vérifiez avec l'équipe réceptrice pour connaître la progression
• Mettez à jour le client même s'il n'y a pas de nouvelle information (« Nous enquêtons toujours — voici ce que nous savons jusqu'à présent »)
• Ajustez la sévérité si la situation change (mieux ou pire)
• Documentez toutes les mises à jour dans le ticket pour la piste d'audit
• Fermez la boucle quand c'est résolu : confirmez avec le client, mettez à jour le suivi interne, capturez les apprentissages

Dés-escalade

Toute escalade ne reste pas escaladée. Dés-escaladez quand :

• La cause racine est trouvée et c'est un problème résolvable par le support
• Un contournement est trouvé qui débloque le client
• Le problème se résout de lui-même (mais documentez quand même la cause racine)
• Les nouvelles informations changent l'évaluation de sévérité

Lors d'une dés-escalade :

• Notifiez l'équipe vers laquelle vous avez escaladé
• Mettez à jour le ticket avec la résolution
• Informez le client de la résolution
• Documentez ce qui a été appris pour référence future

Bonnes pratiques d'escalade

1. Quantifiez toujours l'impact — les escalades vagues sont déprioritisées
2. Incluez les étapes de reproduction pour les bogues — c'est ce que l'ingénierie a besoin en priorité
3. Soyez clair sur ce dont vous avez besoin — « enquêter » vs. « corriger » vs. « décider » sont des demandes différentes
4. Fixez et communiquez un délai — l'urgence sans délai est ambiguë
5. Maintenez la propriété de la relation client même après escalade du problème technique
6. Effectuez un suivi proactif — n'attendez pas que l'équipe réceptrice vienne à vous
7. Documentez tout — la piste d'escalade est précieuse pour la détection de patterns et l'amélioration des processus