Les cas limites sont les seuls qui ont besoin d'une personne
Les décisions de remboursement se partagent en trois, et une seule a besoin de jugement. Clairement dans la politique, clairement hors de la politique, et la bande entre les deux où la réponse dépend d'un contexte que la politique n'avait pas prévu.
La plupart des équipes envoient les trois à une personne, donc les dix pour cent intéressants reçoivent la même attention que les quatre-vingt-dix évidents. Les relecteurs cessent de lire avec soin parce que la plus grande part de ce qu'ils voient n'exige aucune lecture.
Automatiser les cas clairs n'est sûr que si la frontière est tracée avec prudence. Une demande presque dans la politique est limite, pas approuvée. Le coût de cette prudence est une relecture plutôt qu'un remboursement donné à tort.
La politique écrite doit être la source. Un modèle qui raisonne à partir d'un sens général de l'équité produit des décisions que vos conditions ne soutiennent pas, et ces décisions deviennent un précédent dès qu'un client en cite une.
Comment l'ActionFlow s'exécute sur le canevas
La politique vit dans une table plutôt que dans un prompt. Un nœud Google Sheets ou PostgreSQL tient les règles comme conditions structurées (fenêtre d'achat, catégorie de produit, nombre de remboursements antérieurs) pour qu'un responsable finance puisse les changer sans toucher au flux.
Un déclencheur Webhook livre la demande. Un nœud HTTP Request récupère la commande et l'historique de remboursements du client.
Un nœud Generate Object évalue la demande au regard des règles récupérées et renvoie trois champs : une bande de décision, les règles précises appliquées, et une valeur de confiance. Nommer les règles appliquées rend la décision auditable plus tard.
Un nœud Switch agit sur la bande. Les approbations claires vont à un nœud HTTP Request qui les traite et un nœud Email qui confirme. Les refus clairs vont à un nœud Generate Text qui écrit l'explication, en nommant la règle applicable.
Les cas limites vont à un nœud Slack de la catégorie Human in the Loop, avec le raisonnement et les règles joints, pour que le relecteur décide plutôt qu'il n'enquête.
Un nœud Google Sheets consigne chaque décision avec sa bande et ses règles, ce qui est à la fois la piste d'audit et le jeu de données qui montre où la politique elle-même n'est pas claire.
Nœuds utilisés par cet ActionFlow
- Webhook (Trigger) : livre la demande de remboursement.
- Google Sheets (Integration) : tient la politique comme règles structurées. PostgreSQL occupe le même emplacement.
- HTTP Request (Util) : tire la commande et l'historique de remboursements. Shopify occupe le même emplacement pour les boutiques.
- Generate Object (AI Core) : renvoie la bande de décision, les règles appliquées et une valeur de confiance.
- Switch (Control) : sépare les approbations claires, les refus clairs et la bande limite.
- Generate Text (AI Core) : écrit l'explication de refus en nommant la règle qui s'est appliquée.
- Slack (Human in the Loop) : envoie les cas limites à une personne avec le raisonnement joint.
- Google Sheets (Integration) : consigne les décisions comme piste d'audit et jeu de données sur la clarté de la politique.
Questions fréquentes
Newsletter
Recevoir les mises à jour produit
Nouveaux nœuds, agents et notes produit. Nous n'envoyons un e-mail que lorsqu'il vaut la peine de l'ouvrir.