Ticket Deflector

Démarrage rapide

Transmettez ou collez un email client — Claude récupère le statut de la commande sur PayPal, recherche le client dans HubSpot, et rédige une réponse à la voix du propriétaire. Si un remboursement est nécessaire, il prépare les détails et attend une approbation explicite avant d'émettre quoi que ce soit.

User: "answer this customer" [forwards email]
→ Extract customer email + issue from thread
→ Pull PayPal transaction status
→ Pull HubSpot contact history
→ Draft reply in owner's voice
→ Owner approves draft → send or stage
→ If refund needed: approval prompt → owner confirms → issue

Workflow

1. Lire le message du client. Accepter un thread Gmail transmis ou du texte collé. Extraire : adresse email du client, nom, ID de commande ou de transaction (le cas échéant), et le problème principal — demande de remboursement, question sur le statut de la commande, ou réclamation générale. S'il y a plusieurs problèmes, les traiter dans l'ordre où ils apparaissent.

2. Récupérer le statut de la commande sur PayPal. Chercher les transactions PayPal par email client ou ID de transaction. Capturer : montant, date, statut, et si un remboursement a déjà été émis. Si PayPal n'est pas connecté, le noter dans le brouillon et continuer. Si aucune transaction ne correspond, le signaler — ne pas deviner une correspondance.

   • Limite de débit PayPal : Si le client a fourni un ID de transaction, l'utiliser — les recherches de simple enregistrement évitent complètement la limitation. Si la recherche se fait par email, utiliser une fenêtre de 7 jours (pas 30 jours). L'endpoint de liste des transactions PayPal limite agressivement les requêtes sur de larges plages de dates ; les tickets consécutifs dans la même session atteindront cette limite si la fenêtre est trop large.
   • Si Intercom est connecté, vérifier les tickets d'assistance ouverts de ce client.
   • Si Square est connecté, vérifier l'historique des transactions Square comme source secondaire.
   • Si plusieurs transactions correspondent, les afficher toutes et demander au propriétaire laquelle s'applique avant de rédiger.

3. Récupérer l'historique du client depuis HubSpot. Chercher les contacts par adresse email. Récupérer : étape du cycle de vie, notes, transactions ouvertes, et activité récente. Si aucun contact n'existe, le noter et proposer d'en créer un après l'envoi de la réponse — ne pas créer pendant le workflow de réponse.

4. Rédiger la réponse. Écrire à la voix du propriétaire. Adapter le ton au type de problème :

   • Demande de remboursement → empathique, clair, axé sur l'action
   • Question sur le statut → factuel, rassurant
   • Réclamation générale → reconnaître, expliquer, proposer une résolution Signaler toute lacune de données directement dans le brouillon avec une note entre crochets (par ex., [Note: Aucune transaction PayPal trouvée — vérifier l'ID de commande avant envoi]) pour que le propriétaire voit la lacune avant d'envoyer. Pour un exemple travaillé, voir reference/examples/respond-refund-request.md. Pour les pièges courants, voir reference/gotchas.md.

5. Barrière d'approbation — le propriétaire examine le brouillon. Présenter le brouillon complet. Ne pas l'envoyer ou le préparer tant que le propriétaire n'a pas approuvé. Le propriétaire peut le modifier librement avant d'approuver.

6. Barrière d'approbation — émission du remboursement. Si un remboursement est justifié, présenter une invite de confirmation dédiée après que le propriétaire a approuvé le brouillon :

   "Émettre un remboursement de $[montant] à [nom du client] ([email]) pour la transaction [ID] ? Répondre O pour procéder."

   Attendre une confirmation explicite. Si la réponse du propriétaire est autre chose qu'un oui clair, arrêter et demander ce qu'il souhaite faire à la place.

7. Envoyer ou préparer la réponse. Après approbation du brouillon, demander au propriétaire : envoyer via Gmail maintenant, ou enregistrer en tant que brouillon ? Exécuter son choix. Ensuite, consigner l'interaction en tant que note sur la chronologie du contact HubSpot.

8. Rapport. Un court paragraphe : réponse envoyée ou préparée, remboursement émis ou non, note HubSpot consignée.

Barrières d'approbation

• Ne jamais émettre un remboursement PayPal sans confirmation explicite du propriétaire — toujours afficher le montant, le nom du client, l'email, et l'ID de transaction avant d'exécuter.
• Ne jamais envoyer la réponse sans examen par le propriétaire. Toujours présenter le brouillon complet en premier.
• Ne jamais créer un contact HubSpot pendant le workflow de réponse. Le proposer après.
• Ne jamais auto-sélectionner une transaction PayPal. Si plusieurs correspondent, les afficher toutes et laisser le propriétaire choisir.
• Ne jamais fabriquer de détails de commande. Si PayPal n'a pas d'enregistrement, le dire directement dans le brouillon — ne pas inventer un statut.

Référence

• reference/gotchas.md — Bons et mauvais modèles pour le ton, la recherche PayPal, et les scénarios de remboursement ambigus
• reference/examples/respond-refund-request.md — exemple travaillé : demande de remboursement avec transaction PayPal trouvée