Ce que couvre réellement un workflow de validation en support
Un workflow de validation se déclenche chaque fois que quelqu'un de l'équipe n'a pas le droit d'agir seul. En support, cela recouvre généralement trois types de demandes :
- L'argent : remboursements, avoirs, gestes commerciaux et suppressions de frais au-delà de ce qu'un agent peut accorder.
- Les exceptions : tout ce qui sort de la politique écrite, comme un retour hors délai ou une résiliation sans dépannage. Mon guide sur la gestion des exceptions de support explique comment les consigner.
- Le travail de l'IA : réponses et actions rédigées par un agent IA qu'une personne vérifie avant leur envoi.
Le cas de l'argent est le plus ancien, et les agents de première ligne le décrivent de la même manière dans tous les secteurs. Voici comment un employé du support d'un opérateur télécom a décrit une véritable échelle d'avoirs :
"Supervisors can approve up to about $300 in credits, then whatever is left gets rolled up to their managers. Floor support or SME'S have about the same limit as a supervisor, but they do not have access to things like the credit qué and a few other things."
C'est un workflow, même si personne ne l'a jamais écrit : des plafonds par rôle, une file que seuls certains voient, puis une remontée vers le haut. L'écrire est la première étape, et sa place est dans vos procédures de support, à côté de la politique elle-même.
La carte de demande est l'endroit où la plupart des workflows échouent, donc je commence par là. Un approbateur doit pouvoir décider à partir de la seule carte :
Si le manager doit ouvrir le ticket, faire défiler le fil, puis chercher la commande, l'approbation prend 15 minutes au lieu de 15 secondes. Côté file, j'en vois le coût chaque semaine : le client attend, et l'agent devient le messager d'une décision qu'il n'a pas prise.
Décidez de ce qui nécessite une approbation avant de choisir un outil
La question de l'outil vient en second. D'abord, décidez quelles demandes ont besoin d'une deuxième personne, et pour cela j'utilise deux tests.
Test 1 : est-ce au-dessus du plafond de l'agent ? Fixez des paliers de montants, donnez un approbateur à chaque palier, et laissez les agents traiter tout ce qui est sous leur palier sans demander. Une approbation sur de petits montants est un pur gaspillage, comme l'a souligné un commentateur après avoir attendu pour un remboursement de 37 centimes :
"This is why for the store it is better to have a smoother process for small price adjustments, it should not be necessary to wait 15 minutes for the store manager's approval on a 37 cent refund, nor should he even have to deal with it at all, that is a waste of his time and salary to be attending to something so minor."
Test 2 : peut-on l'annuler ? Celui-ci compte davantage dès que l'IA entre en jeu, car un remboursement peut être inversé ou passé en perte, alors qu'une promesse faite par e-mail ne se reprend pas. Un fil récent sur ce que les agents IA devraient faire sans approbation est arrivé exactement à cette conclusion :
"imo the cutoff isnt really about the action type, its about reversibility. if the agent does something you can undo in 30 seconds, let it run. if undoing it requires an apology email to a customer, that needs approval."
Combinez les deux tests et vous obtenez une échelle. Les chiffres ci-dessous sont un exemple, pas une référence. Choisissez les vôtres à partir de votre propre historique de remboursements :
La plupart des tickets devraient s'arrêter à la marche du bas. Si la moitié de vos tickets de remboursement montent l'escalier, les plafonds sont trop bas, et chaque montée ajoute une attente pour le client. Le guide sur la matrice d'approbation des remboursements détaille comment fixer les paliers. Il y a aussi un contre-argument légitime : certaines approbations ont une raison d'être, car le personnel de première ligne ne sait pas toujours pourquoi un prix ou une politique est fixé ainsi. L'objectif est moins d'approbations, mieux ciblées, pas zéro.
Où chaque helpdesk place les approbations
J'ai parcouru les centres d'aide des helpdesks que je vois le plus dans les déploiements d'eesel. Ils se répartissent en trois groupes : des outils avec un véritable objet d'approbation, des outils conçus pour les approbations IT, et des outils où « approbation » signifie un brouillon partagé plus une permission retirée. Choisissez le vôtre pour voir la configuration, l'endroit où les approbateurs décident et l'offre requise :
En bref : si vous avez besoin d'un objet d'approbation avec un statut, un blocage de fermeture et une trace, Zendesk Professional, Freshservice et Jira Service Management sont les trois seuls ici à en proposer un pour les tickets. Tous les autres y arrivent par le processus.
Zendesk : de vraies demandes d'approbation, à partir de Suite Professional
Zendesk cite les remboursements comme cas d'usage : un agent reçoit un ticket de remboursement, crée une demande d'approbation et l'envoie à un approbateur, par exemple son chef d'équipe. Les règles sont strictes de façon utile, d'après la documentation sur les approbations de Zendesk :
- Jusqu'à 5 approbateurs par demande. Avec plusieurs, tous doivent approuver, et un seul refus refuse tout le bloc.
- L'approbateur ne peut pas être le demandeur du ticket, l'agent assigné ni la personne qui a créé la demande. La séparation des tâches est intégrée.
- Les approbateurs de groupe ne fonctionnent que pour les groupes de 30 membres ou moins, et la première réponse compte.
- Une demande en attente empêche la fermeture du ticket tant que tous n'ont pas répondu ou qu'elle n'est pas retirée.
- Les demandes ne sont pas modifiables après leur création. On les retire et on les recrée.
Les limites méritent d'être connues avant de concevoir autour de cet outil. Il n'y a pas de chaîne séquentielle : si vous voulez d'abord le chef d'équipe puis le manager, vous créez une demande, vous attendez, puis vous créez la suivante. Zendesk ne documente pas non plus de réglage de rappel, donc relancer un approbateur lent est un travail manuel de partage de lien. Un product manager de Zendesk a aussi confirmé en commentaire que l'approbation par réponse e-mail est exclue pour des raisons de conformité.
La partie Slack est le grand changement de 2026. Depuis mai 2026, les approbateurs individuels reçoivent un message privé Slack, et les approbations de groupe ouvrent un canal privé temporaire avec tous les membres du groupe :
En octobre 2026, Zendesk a ajouté des commentaires Slack qui se synchronisent vers le ticket comme trace auditable. Vous ne pouvez toujours pas créer ou retirer une demande depuis Slack. Pour les flux automatisés, la recette d'action flows peut se mettre en pause jusqu'à 30 jours et bifurquer selon Approved, Denied, Withdrawn ou Expired, même si Zendesk indique que les actions d'approbation avancées nécessitent son programme d'accès anticipé.
Si vous êtes sur Suite Team, la solution de repli ce sont les side conversations, qui sont un fil séparé et non un objet approuver ou refuser. Les offres requises figurent dans mon décryptage des tarifs Zendesk, et le guide des rôles et permissions explique qui peut créer des demandes.
Freshservice et Jira Service Management : des chaînes de niveau IT
Les deux outils viennent du monde IT et cela se voit : les approbations y sont un objet de premier plan avec une logique à plusieurs étapes que les helpdesks de service client n'ont pas.
Dans Freshservice, les approbateurs sont dans des groupes, et les groupes dans une chaîne. Chaque groupe a une règle (Everyone, Anyone, Majority ou First Responder), et la chaîne en a une aussi :
Deux fonctions que j'aimerais voir copiées par les outils de service client. Freshservice peut relancer les approbateurs toutes les N heures, et les approbateurs peuvent déléguer des approbations à un collègue avec des dates de début et de fin, ce qui règle le problème du « manager en vacances ». Les prix vont de 19 à 99 $ par agent et par mois en facturation annuelle, avec les workflows multi-approbation cochés dans chaque offre. Mon guide des tarifs Freshservice détaille les offres.
Jira Service Management ajoute l'approbation comme une étape sur un statut de workflow. Vous choisissez le nombre d'approbateurs, d'où ils viennent, et de quels champs les exclure, comme l'agent assigné ou le rapporteur. Les approbateurs agissent depuis le centre d'aide, l'e-mail, Slack ou Teams, et ils n'ont pas besoin de licence JSM. L'article sur les tarifs Jira Service Management explique pourquoi les 100 e-mails par jour de l'offre Free peuvent pénaliser les notifications d'approbation.
Si votre équipe de support partage déjà un compte Freshworks ou Atlassian avec l'IT, il peut valoir la peine d'y faire tourner les approbations de remboursement. Sinon, ces outils représentent beaucoup de configuration pour une équipe de support qui veut seulement le oui d'un manager.
Front, Help Scout et Freshdesk : brouillons et permissions
Ces trois outils n'ont pas de bouton d'approbation pour les tickets. Ils ont en revanche un brouillon que quelqu'un d'autre peut voir, plus un moyen d'empêcher certaines personnes d'envoyer.
La politique suggérée par Front lui-même est de « toujours partager le brouillon avec un manager pour approbation sur les questions de prix », d'après son article sur les workflows de support. Les brouillons partagés sont activés par défaut dans les boîtes partagées, mais les collègues ne sont pas notifiés sauf si vous les mentionnez avec @ :
Pour en faire une règle ferme, vous retirez la permission « Send messages » à un groupe comme les nouvelles recrues. Cela demande Enterprise à 105 $ par siège et par mois, et ne couvre que les canaux partagés. Front suggère aussi une tâche liée assignée à un manager pour les demandes d'approbation, qui fonctionne dans toutes les offres et remonte la conversation en haut quand la tâche est résolue. Le détail des offres est dans mon article sur les tarifs Front.
L'approche documentée de Help Scout est plus simple : les nouveaux agents enregistrent leurs réponses en brouillons, et un manager envoie en leur nom depuis le menu Send options. Les Light Users, qui peuvent laisser des notes mais pas répondre, nécessitent Plus ou Pro. Le hic : Help Scout indique qu'il n'existe aucune méthode pour restreindre des conversations individuelles, donc vous ne pouvez pas dire « cet agent a besoin d'une approbation uniquement sur les tickets de remboursement ». Plus de détails dans le décryptage des tarifs Help Scout.
Freshdesk documente un workflow d'approbation, mais pour les articles de la base de connaissances dans Enterprise, pas pour les tickets. La validation des tickets dans Freshdesk est un processus que vous construisez avec les rôles et permissions et des notes internes. Le guide des approbations Freshdesk passe en revue ces options.
Gorgias et HubSpot : droits par rôle, approbations ailleurs
Gorgias encadre les remboursements par rôle plutôt que par approbation. Les utilisateurs Basic, Lead et Admin peuvent déclencher un remboursement ou une annulation Shopify directement depuis le ticket, les utilisateurs Observer et Lite non, et je n'ai trouvé aucun plafond de montant par agent dans les tableaux des permissions utilisateur. Ce qui se rapproche le plus d'une étape de relecture, c'est que les actions de macro apparaissent sous l'éditeur, où l'agent peut les prévisualiser, les modifier ou les retirer avant l'envoi. Si vous avez besoin d'un manager dans la boucle sur Gorgias, c'est une question de conception de rôles et de norme d'équipe, que vous pouvez appuyer avec des règles Gorgias qui étiquettent les tickets de remboursement pour qu'un responsable les vérifie.
HubSpot a l'interface d'approbation la plus soignée du groupe, avec Approve, Reject et Request changes sur la fiche, mais elle vaut pour les affaires et les devis. Les tickets ne figurent pas dans la liste des objets d'approbation de HubSpot. Les règles du pipeline de tickets dans Service Hub Professional peuvent limiter qui modifie les tickets à certaines étapes, mais les super admins, les workflows et l'API peuvent les contourner. Mon guide sur l'IA pour HubSpot Service Hub couvre ce que le côté support peut automatiser.
Mettez aussi le plafond de montant dans la couche de paiement
Quand votre helpdesk ne peut pas faire respecter un plafond, le système de paiement le peut parfois. Stripe propose l'approbation de remboursement native la plus claire que j'aie trouvée : une règle d'approbation à deux parties sur « Refund is created », avec un seuil de montant facultatif. Un utilisateur ne peut pas approuver sa propre demande, et les demandes non approuvées expirent au bout de 14 jours, d'après la documentation de Stripe sur les approbations à deux parties.
L'administration en ligne de Shopify propose des permissions de remboursement activées ou désactivées, sans plafond de montant. Shopify POS est différent : remboursements, remises et avoirs en magasin peuvent être réglés sur « Approval required », et un manager approuve en saisissant son code PIN. Les rôles POS personnalisés sont une fonctionnalité de POS Pro.
Approuver les réponses et actions de l'IA
Tout ce qui précède suppose qu'un agent humain demande et qu'un humain approuve. Avec un agent IA dans la file, il y a une deuxième couche : l'IA prépare le travail, et une personne l'approuve avant qu'il n'atteigne le client ou vos systèmes. Un commentateur de Hacker News a bien décrit ce montage bien avant que la plupart des éditeurs ne le proposent :
"Now if AI agents are free to issue refunds or discounts by their own? Great, let's do that and suddenly most people are on board. But get ready for rampant abuse. Best solution would be an AI cyborg system where it readies a recommendation and a human swings by and approves or denies it without wasting time talking to people."
C'est proche de ce que proposent désormais les éditeurs, chacun à sa manière :
- Zendesk auto assist (inclus dans le module Copilot) suggère des actions qu'un agent approuve avant leur exécution. Les admins peuvent marquer une action comme pré-approuvée, et la recommandation de Zendesk est que les actions d'écriture comme les remboursements restent approuvées par l'agent. Mon guide des actions d'auto assist détaille la configuration.
- Front Les règles Autopilot ont un champ « Hold reply for review » qui crée un brouillon au lieu d'envoyer, et Front recommande de commencer par là avant l'automatisation complète.
- Help Scout Les AI Drafts sont écrits pour que les agents les relisent et les révisent avant l'envoi, dans Plus et Pro.
- Gorgias AI Agent a un réglage « Customer confirmation », mais notez qui approuve : c'est l'acheteur qui confirme, pas un manager. Il s'active automatiquement pour les actions irréversibles comme l'annulation d'une commande.
- Stripe applique des règles d'approbation par défaut aux remboursements créés avec des clés d'API étiquetées agent. Même la couche de paiement traite les remboursements initiés par l'IA comme un acteur distinct.
Voici le flux que je viserais pour une demande de remboursement avec de l'IA dans la boucle :
Ce que les gens sous-estiment, c'est ce que les relecteurs font réellement des brouillons d'IA. Dans un essai sur du trafic réel dans une boîte Zendesk d'e-commerce, le tri était juste à 93 %, mais les agents n'ont envoyé que 12 % des brouillons d'IA tels quels. Le schéma était de survoler puis réécrire : un brouillon de 8 à 15 phrases réduit à 1 à 3 phrases. Environ 65 % des réécritures concernaient la longueur et le ton, le genre de chose qu'on corrige en entraînant l'IA sur les réponses envoyées par l'équipe, et seulement environ 5 % venaient d'une erreur factuelle de l'IA.
Deux enseignements côté file. D'abord, un bouton oui ou non ne suffit pas. Un client Freshdesk m'a dit qu'il devait modifier les brouillons d'IA avant l'envoi, parce qu'approuver tel quel ou rejeter l'obligeait à copier-coller. Ensuite, vérifiez que la version modifiée est bien celle qui part. Un collègue a un jour signalé un client Freshdesk dont les brouillons modifiés partaient dans leur version originale non modifiée, ce qui rendait le workflow inutilisable jusqu'à correction. Testez ce chemin avant de lui faire confiance.
Si vous comparez des outils de copilote IA, ces deux détails en disent plus que n'importe quelle démo. Le point de vue de Freshdesk lui-même sur la rédaction est dans mon article sur les brouillons de réponse IA de Freshdesk.
Comment je fais tourner une IA avec approbation préalable chez eesel
Le collègue IA d'eesel est conçu comme vous intégreriez une nouvelle recrue. Il ne reçoit pas d'interrupteur d'autonomie le premier jour. Il gagne son autonomie par du travail relu. En pratique, cela se résume à un réglage par action, choisi par agent, comme décrit dans la documentation Actions and Approvals :
- Auto : s'exécute seule, sauf si les instructions disent de demander d'abord dans une situation donnée.
- Needs approval : l'agent prépare l'action, et une personne l'approuve ou la refuse avant que quoi que ce soit n'arrive.
- Disabled : l'agent ne peut pas du tout l'utiliser.
Les actions sont regroupées en Read et Write, donc un point de départ courant est Read sur Auto et la plupart de Write sur Needs approval, avec les actions à faible risque comme les notes internes sur Auto :
Quand une action nécessite une approbation, l'approbateur voit le texte exact de la réponse ou le montant du remboursement (ou l'étiquette), puis choisit parmi trois boutons. Approve l'exécute maintenant. Always allow l'exécute et passe cette action en Auto à partir de là, pour cet agent uniquement. Deny l'ignore, et l'agent continue sans elle. Ce bouton « Always allow » est l'étape de diplôme : vous approuvez des remboursements sur un agent de boutique cinq fois, ils sont corrects, et vous le laissez voler de ses propres ailes.
L'approbation arrive là où l'approbateur travaille déjà, ce qui compte, puisque l'admin Zendesk cité au début ne voulait pas un onglet de plus à surveiller. Les approbations apparaissent dans le tableau de bord eesel, sous forme de carte dans le fil Slack d'où l'exécution est partie, sous forme de lien dans un e-mail ou une note du helpdesk, et dans le terminal :
Quelques règles sur lesquelles je m'appuie pour configurer un nouveau client :
- Les politiques d'exception s'écrivent en mots simples. Vous pouvez laisser les réponses sur Auto et écrire « demande avant de répondre sur tout ce qui concerne les remboursements », et l'agent ne demande que dans ces cas. La documentation inclut des modèles pour exactement cela, comme escalader tout remboursement de plus de 100 $ ou sauter la demande de photo sur les réclamations pour dommages de moins de 50 $. C'est ainsi qu'un administrateur de support a appris à son agent la règle « dépanner avant de résilier » : en le corrigeant comme une nouvelle recrue.
- Seuls les Editors peuvent approuver. Les Owners et les Editors décident. Les Viewers voient les approbations mais ne peuvent pas agir, et dans Slack, la personne qui clique est associée à un Editor par e-mail.
- Rien ne s'approuve automatiquement à l'expiration d'un délai. Une action en attente reste en attente, et l'agent laisse une note indiquant qu'une personne fera le suivi. Chaque décision indique qui a décidé et quand sur la page Activity.
- Rien ne tourne tant que vous n'avez pas créé une automatisation. Connecter Zendesk ne fait répondre l'agent à personne.
Pour les équipes qui vivent dans un terminal, ou qui veulent que Claude Code, Codex ou Cursor gèrent les approbations, la CLI eesel pilote le même agent que le tableau de bord. eesel approvals liste ce qui attend, eesel approvals approve <id> --always approuve et fait passer l'action en automatique d'un coup, et eesel integrations zendesk actions affiche chaque action avec son réglage d'approbation. Les écritures de la CLI suivent les mêmes permissions, donc les écritures d'un Viewer sont toujours retenues pour un Editor.
Avant que tout cela ne touche un client, je demande d'abord une simulation. Avec un helpdesk connecté, l'agent rejoue de vrais tickets passés et compare ses réponses à ce que l'équipe a envoyé. Dans l'exemple de la documentation, 17 tickets sur 20 échantillonnés correspondaient, avec un score par thème et une liste de correctifs classée. Cela vous dit quelles actions sont prêtes pour Auto et lesquelles doivent rester derrière une approbation. Pour la vue d'ensemble, voyez mes articles sur les collègues IA et l'agent IA de helpdesk.
Erreurs courantes dans les workflows de validation
- Tout approuver. Si chaque remboursement nécessite un manager, le manager devient la file. Relevez les plafonds des agents jusqu'à ce que la plupart des tickets s'arrêtent à la marche du bas.
- Une demande maigre. « Puis-je rembourser ceci ? » oblige l'approbateur à reconstituer le ticket. Utilisez la carte en cinq lignes : commande, demande, ligne de politique, recommandation, échéance.
- Pas de rappel ni d'approbateur de secours. Je n'ai trouvé aucun réglage de rappel d'approbation dans la documentation de Zendesk ni de Jira. Si votre outil n'en a pas non plus, fixez un SLA interne pour les approbations et nommez un suppléant.
- Pas de trace écrite. Une approbation dans un message privé est invisible pour l'agent suivant. Gardez la décision sur le ticket pour qu'elle alimente votre journal des exceptions et les futurs changements de politique.
- Donner trop tôt son autonomie à l'IA. Passez une action en automatique après du travail relu, pas après une belle démo. L'entrée sur les garde-fous de l'IA couvre les autres limites à fixer, et l'injection de prompt est la raison pour laquelle les actions de remboursement méritent une attention particulière.
- Oublier où vont les escalades. Approbation et escalade sont cousines. Si une approbation est refusée, l'agent a besoin d'un chemin clair, ce que couvrent l'escalade par l'IA et l'escalade inter-équipes.
Quand les politiques changent, mettez à jour les règles d'approbation le même jour aussi. Mon guide de la gestion des changements de politique explique comment garder agents, macros et instructions d'IA synchronisés, et le contrôle d'accès des agents de support explique comment délimiter ce que chaque siège, y compris celui de l'IA, peut toucher.
Essayez eesel pour une IA avec approbation préalable sur votre file
Si vous utilisez Zendesk, Freshdesk, Gorgias ou un autre helpdesk auquel eesel se connecte, le collègue IA de helpdesk d'eesel peut démarrer comme vous démarreriez n'importe quelle nouvelle recrue sur les remboursements : il rédige la réponse ou le remboursement, et vous l'approuvez depuis Slack, le ticket ou le tableau de bord. Les actions qui reviennent justes obtiennent « Always allow », et tout ce qui coûte de l'argent peut rester derrière votre feu vert aussi longtemps que vous le souhaitez. La vue des rapports montre combien d'actions ont été approuvées, rejetées ou sont encore en attente, par outil :
Les approbations ne coûtent rien de plus. Un ticket ou un chat vaut 1 crédit, quel que soit le nombre de réponses et d'actions qu'il demande, avec des sièges illimités ; l'offre gratuite comprend 100 crédits sans carte, et les offres payantes commencent à 299 $ par mois pour 500 crédits. Essayez eesel sur votre propre file avec chaque réponse sur Needs approval, et voyez combien vous en auriez envoyé telles quelles.
Comment approuver des réponses rédigées par l'IA avant leur envoi ?