Bot WhatsApp Business : menus, champs et reprise humaine
Concevoir un bot WhatsApp Business borné : menus, champs structurés, gestion des erreurs et reprise humaine sans impasse pour le client.
Un bot WhatsApp Business bien conçu ne cherche pas à tout faire : il couvre un périmètre précis, commande ou support, guide le client par des menus courts, collecte des champs structurés et sait passer la main à un conseiller au bon moment. Vous trouverez ici une méthode de conception complète : arborescence, règles de saisie, gestion des erreurs, cas de refus et mécanisme d'arrêt du bot, avec un exemple original commenté de bout en bout.
Cadrer un bot borné : commande ou support, pas les deux
La première décision n'est pas technique mais éditoriale : quel périmètre couvre l'assistant WhatsApp ? Un bot borné annonce ce qu'il fait et, surtout, ce qu'il ne fait pas. Un bot de commande gère catalogue limité, panier simple et confirmation. Un bot de support gère statut de commande, questions fréquentes et qualification avant transfert. Mélanger les deux produit des menus à rallonge et des impasses.
Cette borne sert aussi la reprise humaine : quand le conseiller reçoit la conversation, il doit savoir en un coup d'œil de quel parcours il s'agit et quelles données ont déjà été collectées. Un bot qui « fait tout » transmet un contexte flou. Pour aller plus loin sur la structuration des demandes entrantes, consultez notre guide sur l'agent IA WhatsApp et l'organisation des demandes clients.
Enfin, un périmètre borné facilite la conformité : vous collectez moins de données, vous documentez moins de flux, et vous pouvez justifier chaque champ demandé. La fenêtre de service de 24 heures de la WhatsApp Business Platform, réouverte à chaque message de l'utilisateur, et l'obligation de modèles approuvés au-delà sont des contraintes à intégrer dès la conception, pas après.
Menus numérotés plutôt que compréhension ouverte
Pour un bot borné, les menus numérotés courts battent l'interprétation de langage libre dans la quasi-totalité des cas utiles à une PME. Trois options par menu, quatre au maximum, avec une option de sortie visible : « 3. Parler à un conseiller ». Le client répond « 1 », « 2 » ou « 3 » ; le bot n'a pas à deviner.
La saisie libre reste nécessaire à certains endroits : numéro de commande, adresse de livraison, description d'un problème. La règle de conception est simple : un champ libre à la fois, avec une question fermée et un exemple de format attendu. « Quel est votre numéro de commande ? Il commence par CMD, par exemple CMD-1042. »
Ne présumez pas que tous les composants riches sont disponibles dans votre intégration : selon la solution retenue, les listes interactives, les formulaires structurés ou les catalogues ne sont pas toujours accessibles. Un menu en texte numéroté fonctionne partout, y compris via l'application simple, et se teste facilement. Si vous concevez un parcours de prise de rendez-vous, notre article sur le chatbot de rendez-vous et le parcours client sans impasse détaille les mêmes principes appliqués à la planification.
Collecter des champs structurés, pas des paragraphes
Chaque donnée demandée doit avoir un destinataire et un usage identifiés. Un champ « informations complémentaires » libre attire tout et n'importe quoi ; trois champs ciblés — numéro de commande, nature du problème, urgence — produisent un ticket exploitable.
Concrètement, définissez pour chaque champ : le format attendu, la validation, et le comportement en cas d'échec. Un numéro de commande se valide par un motif simple (préfixe plus chiffres). Un code postal se valide par longueur et contenu numérique. Une description de problème reste libre mais bornée : demandez « en une phrase, que s'est-il passé ? » plutôt qu'un champ illimité où le client raconte tout le contexte depuis le début.
Ces champs structurés sont ce que le conseiller verra à la reprise. Un transfert avec « client mécontent » ne sert à rien ; un transfert avec « commande CMD-1042, colis non reçu, client disponible avant 12h » permet une prise en charge immédiate. La protection des données s'applique aussi ici : ne demandez que ce qui est nécessaire au traitement, conformément aux grands principes de protection des données rappelés par la CNIL.
Gérer les erreurs sans boucle infinie
L'erreur la plus fréquente des bots WhatsApp est la boucle : « Je n'ai pas compris » répété jusqu'à l'abandon. Fixez une règle explicite : après deux échecs de validation sur le même champ, le bot change de stratégie — il reformule avec un exemple plus précis, ou il propose la sortie vers un humain.
Deuxième règle : chaque menu doit avoir une sortie. Un client qui arrive par erreur dans un parcours de support doit pouvoir revenir au menu principal ou taper « stop » à tout moment. Un raccourci global unique, mémorisable, vaut mieux que dix commandes cachées.
Troisième règle : distinguez l'erreur de saisie de l'erreur de parcours. Un numéro de commande inexistant n'est pas une faute de frappe à corriger indéfiniment ; après une vérification, le bot propose soit une reformulation, soit le transfert. Notre guide sur le transfert à un conseiller dans un chatbot de service client détaille ces points de sortie.
Les cases de refus et les messages hors horaires
Un bot borné doit refuser proprement ce qu'il ne sait pas faire. Ces « cases de refus » sont des réponses préparées pour les demandes hors périmètre : réclamation tarifaire, demande juridique, urgence de sécurité, sujet que vous ne traitez pas. Le refus n'est pas un échec : c'est une réponse honnête qui oriente. « Je ne peux pas traiter les demandes de remboursement supérieures à notre seuil. Je vous mets en relation avec un conseiller qui pourra examiner votre dossier. »
Les messages hors horaires suivent la même logique. Si votre service client ferme à 18h, le bot doit le dire, indiquer la réouverture, et proposer une option asynchrone : « Votre demande est enregistrée, un conseiller la traitera dès demain 9h. Souhaitez-vous laisser un message ? » Attention à la mécanique de la plateforme : la fenêtre de service de 24 heures s'ouvre au message de l'utilisateur ; si le bot répond dans ce délai, aucun modèle approuvé n'est nécessaire. En revanche, un rappel programmé le lendemain au-delà de la fenêtre exigera un modèle approuvé, avec un coût par message livré qui varie selon la catégorie et le marché selon la tarification de Meta pour la WhatsApp Business Platform. Tous les scénarios horaires présentés ici sont des exemples hypothétiques de conception, pas des engagements.
Préparer le contexte transmis au conseiller
La reprise humaine réussit ou échoue sur un seul élément : le récapitulatif. Avant de transférer, le bot doit reformuler en quelques lignes ce qu'il sait : identité déclarée, numéro de commande, nature du problème, actions déjà tentées, disponibilité du client. Le conseiller ne doit jamais reposer une question déjà traitée.
Ce récapitulatif a aussi une fonction d'arrêt du bot : quand le transfert est déclenché, le bot se retire clairement — « Je vous passe un conseiller, vous allez continuer avec Marie » — pour éviter que le bot et l'humain ne répondent en alternance au même message. Définissez qui a la main : une fois le bot arrêté, seul l'humain répond jusqu'à la clôture de la conversation.
Prévoyez enfin le cas du conseiller absent : file d'attente explicite, promesse de délai réaliste, et message hors horaires si le transfert arrive après la fermeture. Un transfert qui aboutit à un silence est pire qu'un bot qui assume sa limite.
Tableau décisionnel : quand le bot continue, quand il s'arrête
| Situation | Décision du bot | Pourquoi |
|---|---|---|
| Réponse au menu valide | Continuer le parcours | Le client suit le chemin prévu |
| Deux échecs de validation sur un champ | Reformuler avec exemple, puis proposer l'humain | Éviter la boucle d'erreur |
| Demande hors périmètre | Case de refus orientée vers l'humain ou vers l'information exacte | Le refus honnête évite la frustration |
| Numéro de commande introuvable après vérification | Proposer reformulation ou transfert | Ne pas faire porter l'erreur au client |
| Message reçu hors horaires | Accuser réception, indiquer la réouverture, proposer l'enregistrement | Gérer l'attente explicitement |
| Mot-clé « conseiller » ou « stop » | Arrêt immédiat du bot et transfert | Respecter la sortie demandée |
| Transfert déclenché, conseiller absent | File d'attente avec délai annoncé | Un silence après transfert casse la confiance |
Procédure de conception en six étapes
- Écrivez le périmètre en une phrase. « Ce bot traite les demandes de statut de commande et les problèmes de livraison. » Tout ce qui n'entre pas dans cette phrase a une case de refus.
- Dessinez l'arborescence sur papier. Chaque menu, chaque champ, chaque sortie. Comptez les impasses : un nœud sans sortie vers le menu principal ou vers l'humain est un défaut.
- Définissez les champs et leurs validations. Format, exemple de réponse correcte, comportement après deux échecs.
- Rédigez les messages de refus et hors horaires. Chacun annonce ce qui est possible et ce qui se passe ensuite.
- Spécifiez le récapitulatif de transfert. Quelles lignes, dans quel ordre, avec quelles données.
- Testez les chemins d'erreur avant les chemins nominaux. Un bot qui gère bien le cas nominal mais mal les erreurs produira des abandons silencieux. Notre article sur le test d'un agent conversationnel IA propose une méthode de jeu d'essai adaptée.
Exemple principal : arborescence commentée d'un bot de support livraison
Voici un exemple hypothétique, volontairement minimal, pour un bot de support livraison fictif.
``` Accueil : "Bonjour ! Je suis l'assistant de LivraisonPlus (exemple fictif). Je peux vous aider sur : 1. Suivre ma commande 2. Signaler un problème de livraison 3. Parler à un conseiller"
[1] Suivre ma commande : "Quel est votre numéro de commande ? Il commence par CMD, exemple : CMD-1042." → Valide : réponse avec statut, puis "Autre chose ? 1 / 2 / 3" → Invalide (2 fois) : "Je ne retrouve pas ce numéro. Souhaitez-vous parler à un conseiller ? (oui / non)"
[2] Signaler un problème : "Désolé pour ce désagrément. En une phrase, que s'est-il passé ?" → Champ libre borné, puis : "Quand êtes-vous disponible pour un échange ? 1. Cet avant-midi 2. Cet après-midi 3. Demain" → Si réponse hors horaires du service (après 18h, exemple fictif) : "Notre équipe est fermée jusqu'à demain 9h. Votre signalement est enregistré, il sera traité en priorité dès la réouverture."
[3] Parler à un conseiller : "Je résume votre situation : commande CMD-1042, colis non reçu, préférence de contact cet avant-midi. Je vous passe un conseiller." → Arrêt du bot, transmission du récapitulatif.
Case de refus (toute autre demande) : "Je ne peux traiter que le suivi et les problèmes de livraison. Pour toute autre demande, tapez 3 pour parler à un conseiller."
Raccourci global : "stop" à tout moment arrête le bot et propose le transfert humain. ```
Ce que cet exemple illustre : chaque champ a un format annoncé, chaque échec a une issue, la case de refus réoriente sans humilier, et le récapitulatif de transfert contient exactement ce dont le conseiller a besoin. Aucun message ne promet ce que le bot ne peut pas tenir.
Ce qu'un bot borné ne peut pas faire à votre place
Un bot WhatsApp Business exécute les règles que vous avez écrites ; il ne décide pas de votre politique commerciale ni de vos seuils de remboursement. Les cas ambigus — un client à la fois furieux et hors périmètre, une demande mixte commande plus facturation — nécessitent soit une règle explicite de votre part, soit le transfert par défaut. Préférez le transfert : un conseiller qui reçoit trois conversations sans objet par jour coûte moins cher qu'un client perdu.
Gardez aussi à l'esprit les limites du canal : le client peut quitter la conversation, changer de numéro, ou écrire depuis un compte partagé. Vérifiez les conditions d'usage de la WhatsApp Business Platform et obtenez le consentement avant tout message initié par vous ; notre article sur l'automatisation WhatsApp Business, le consentement et les modèles détaille ce cadre.
Si vous souhaitez définir une mission de conception de bot WhatsApp adaptée à votre PME, rendez-vous sur nos offres d'agents.
Questions fréquentes
Faut-il un menu ou de la saisie libre dès l'accueil ?
Un menu court dès l'accueil, sans exception. La saisie libre en premier message force le bot à interpréter, donc à se tromper. Le menu oriente en une réponse, et le raccourci « conseiller » couvre les cas que le menu ne prévoit pas.
Comment arrêter le bot sans fermer la conversation ?
Prévoyez un mot-clé global unique, par exemple « stop » ou « conseiller », reconnu à n'importe quelle étape. Il déclenche l'arrêt du bot et le transfert, sans clôturer le fil : le conseiller prend la main sur la même conversation, avec le contexte.
Que faire quand un client écrit en dehors des horaires ?
Le bot accuse réception, indique l'heure de réouverture et propose d'enregistrer la demande. Si vous souhaitez envoyer ensuite un message au-delà de la fenêtre de 24 heures, il faudra un modèle approuvé, facturé selon la catégorie et le marché.
Combien de champs structurés demander avant un transfert ?
Le minimum nécessaire au traitement : typiquement trois à cinq champs, dont un identifiant (numéro de commande, par exemple) et une disponibilité. Chaque champ supplémentaire doit être justifié par un usage réel côté conseiller.
Peut-on faire un bot de commande et de support dans le même assistant ?
C'est possible mais déconseillé en première version : les menus s'allongent, les cases de refus se multiplient et le récapitulatif de transfert devient confus. Commencez borné sur un périmètre, puis étendez seulement quand les points de sortie fonctionnent.