Routez les demandes et notifiez les bonnes personnes

Vos données sont propres, validées, et structurées. Il est maintenant temps de les faire circuler vers les bonnes personnes. C'est l'étape où votre workflow commence à produire une valeur concrète et visible : une demande de support arrive chez l'équipe support, une opportunité commerciale atterrit chez le bon commercial, et chaque destinataire reçoit une notification claire qui lui dit exactement quoi faire.

Jusqu'ici, votre workflow fonctionnait en circuit fermé : il recevait des données, les transformait, les filtrait ; sans jamais contacter le monde extérieur. Pour envoyer des notifications, ça va changer : pour qu'un nœud puisse envoyer un email via Gmail, poster un message dans Slack, ou écrire dans une base de données, n8n a besoin d'une autorisation. C'est ce qu'on appelle des credentials.

Concevez une logique de routage par typologie de demande

Au chapitre précédent, vous avez introduit un nœud Switch pour séparer les demandes selon leur type. Ce Switch est la fondation de votre logique de routage. Il s'agit maintenant de le compléter : pour chaque branche, définir non seulement où va la demande, mais aussi comment elle est traitée selon son niveau d'urgence.

Voici la logique que vous pourriez mettre en place dans notre projet :

• Support → notifier le canal support. Si l'urgence esthigh, la notification part en priorité sur un canal dédié ou avec une mention spéciale.

• Sales → notifier le canal commercial avec les informations du contact.

• Autre → notifier un canal ops ou une boîte de réception générale.

• Fallback → toute demande qui ne correspond à aucune de ces catégories est capturée et signalée pour traitement manuel.

Commencez simple : une seule dimension à la fois. D'abord le type de demande, puis l'urgence. Évitez de croiser trop de conditions dès le départ : un workflow lisible vaut mieux qu'un workflow exhaustif que personne ne comprend.

Créez des notifications utiles et structurées

Une bonne notification répond à quatre questions en quelques secondes :

1. qui a soumis la demande ?

2. quoi (le sujet ou la description) ?

3. quelle urgence ?

4. et quelle action est attendue ?

Voici un format que vous pouvez utiliser dans notre projet :

Nouveau ticket [ID] — urgence : haute — de : marie.dupont@exemple.fr — sujet : problème de connexion — Action : traiter en priorité.

Et une version plus détaillée pour les canaux qui le permettent :

Nouveau ticket [ID] reçu le [date]. Type : support. Urgence : haute. Contact : Marie Dupont (marie.dupont@exemple.fr). Description : "Je n'arrive plus à me connecter à mon espace depuis ce matin." Prochaine action : contacter le client sous 2h.

Dans n8n, ces templates s'écrivent directement dans les nœuds de notification grâce aux expressions dynamiques. Chaque valeur entre accolades est automatiquement remplacée par la donnée réelle au moment de l'exécution.

Enregistrez une trace exploitable des demandes

Envoyer une notification, c'est bien. Mais si personne ne garde une trace de ce qui a été envoyé, vous n'avez aucun moyen de savoir combien de demandes ont été reçues, lesquelles ont été traitées, et lesquelles sont passées entre les mailles.

Dans n8n, vous pouvez ajouter un nœud pour enregistrer chaque demande dans une base simple (un Google Sheet, un Airtable, ou n'importe quel outil de votre choix) au moment où elle est routée.

Voici des informations que vous pouvez enregistrer dans ce journal :

• Un identifiant unique (le même que celui utilisé dans la notification) pour pouvoir retrouver une demande précise

• Le type de demande et le niveau d'urgence

• L'email du demandeur

• La date et l'heure de réception

• Le statut initial :nouveau,à qualifier, ourejeté

À vous de jouer !

Consigne : configurez 3 routes (support, sales, autre) avec une notification sur chaque branche, rédigez 2 templates de notification avec l'aide d'un outil d'IA, puis testez votre workflow sur 2 demandes de types différents.

Exemple de prompt IA pour vos templates :

"Génère 2 templates de notification pour un workflow de traitement de demandes entrantes. Template 1 : une ligne, pour un affichage dans Slack. Template 2 : 4 lignes, pour un email interne. Les deux doivent inclure : ID du ticket, type de demande, urgence, email du demandeur, et une prochaine action suggérée."

Résultats attendus :

• Demande de typesupport, urgencehigh→ notification sur le canal support prioritaire, ligne ajoutée au journal avec statutnouveau

• Demande de typesales, urgencelow→ notification sur le canal commercial, ligne ajoutée au journal avec statutà qualifier

En résumé

• Les credentials permettent à n8n de s'authentifier auprès de vos outils et d'agir en votre nom. Elles se configurent une fois et se réutilisent dans tous vos workflows.

• Un bon routage s'appuie sur des critères clairs (type de demande, niveau d'urgence) et prévoit toujours un fallback pour les cas non anticipés.

• Une notification utile répond en quelques secondes à quatre questions : qui, quoi, quelle urgence, quelle action. Un outil d'IA peut vous aider à rédiger et varier vos templates.

• Un journal des demandes donne à votre workflow une mémoire : chaque demande est tracée, identifiable, et consultable.

Votre workflow fonctionne de bout en bout. Mais comment s'assurer qu'il reste fiable dans le temps, et qu'il survit à une soumission inattendue ? C'est ce que vous allez apprendre dans le dernier chapitre.