WhatsApp Flows : 8 cas d'usage, limites et coûts (guide 2026)

Réponse rapide : les WhatsApp Flows sont des formulaires natifs, sur un ou plusieurs écrans, qui s'ouvrent dans une conversation WhatsApp. Un client peut ainsi réserver un créneau, demander un devis ou s'inscrire sans quitter la discussion. Ils fonctionnent uniquement sur la WhatsApp Business Platform, exigent une entreprise vérifiée, et s'envoient dans un modèle approuvé ou comme message interactif dans la fenêtre de 24 heures. En octobre 2026, Meta n'affiche aucun frais propre aux Flows : vous payez le message qui le transporte.

Points clés (octobre 2026)

• Chaque écran d'un Flow contient jusqu'à 50 composants et exactement 1 pied de page ; boutons radio et cases à cocher acceptent jusqu'à 20 options, une liste déroulante jusqu'à 200 (référence des composants de Meta).
• Les Flows sans endpoint couvrent la plupart des formulaires d'une petite entreprise. Un endpoint doit répondre en moins d'une seconde, et un Flow jugé défaillant est limité à 10 envois par heure.
• Un Flow dans un modèle est facturé selon la catégorie du modèle ; dans une fenêtre ouverte, c'est un message de service, et chaque numéro en a 1 000 par mois sans facturation.
• Un nouveau numéro peut ouvrir des conversations avec 250 personnes uniques sur 24 heures glissantes, puis 2 000, 10 000, 100 000 et illimité, et les modèles avec Flow comptent dans ce plafond.
• Les Flows s'ouvrent sur Android 6.0+ et iOS 12+, pas sur WhatsApp Web, la limite la plus souvent oubliée.

La plupart des entreprises découvrent les WhatsApp Flows de la même façon : un prestataire montre en démo un joli formulaire de réservation qui s'ouvre dans le chat, et la question devient « faut-il en créer ? ». La réponse honnête dépend de trois choses que ce guide traite dans l'ordre : ce qu'est vraiment un Flow sous le capot, ce qu'il faut pour en créer et en envoyer un, et si votre prise d'informations est assez longue et fixe pour justifier un formulaire. Pour beaucoup de petites équipes, le chemin le moins cher est une courte conversation qui enregistre les réponses au fil de l'eau. Pour d'autres, un Flow est l'outil le plus propre qu'elles montreront jamais à un client.

Nous avons vérifié chaque fait sur les Flows dans la documentation développeurs de Meta en octobre 2026. Quand Meta ne publie pas de chiffre, nous le disons.

Que sont les WhatsApp Flows ?

Les WhatsApp Flows sont des interactions structurées sur plusieurs écrans qu'une entreprise envoie sur la WhatsApp Business Platform. Le client touche un bouton, un formulaire natif s'ouvre dans le chat, il passe d'un écran de champs et de choix à l'autre, puis, à l'envoi, les réponses reviennent à l'entreprise sous forme de message. On dirait une petite application dans WhatsApp.

La documentation développeurs de Meta décrit les Flows comme « un moyen de créer des interactions structurées pour la messagerie professionnelle », et ses guides d'exemple portent sur des offres de prêt pré-approuvé, des devis d'assurance, la collecte d'intention d'achat et des offres produit personnalisées. Cette liste en dit long : ce sont des formulaires à la forme connue, où l'entreprise sait exactement quels champs il lui faut.

Techniquement, chaque Flow est écrit en Flow JSON, un format défini par Meta. Un Flow est un ensemble d'écrans, et chaque écran est un nœud de ce que Meta appelle une machine à états : un identifiant, une mise en page et les composants qu'elle contient. Les écrans se relient par des actions. Les principales :

• navigate : passer à un autre écran en transmettant ce que le client a saisi.
• complete : terminer le Flow et renvoyer les réponses dans le chat.
• data_exchange : envoyer les données en cours à votre serveur, qui décide de la suite. Nécessite un endpoint.
• update_data et open_url : actualiser une partie de l'écran (par exemple recharger une liste déroulante après un choix) ou ouvrir un lien dans le navigateur. Toutes deux exigent Flow JSON 6.0 ou plus.

Chaque Flow doit se terminer sur au moins un écran final, et cet écran doit comporter un bouton de pied de page. Les Flows ont aussi un cycle de vie : Meta liste les états Draft, Published, Throttled, Blocked et Deprecated. On peut modifier un Flow publié, mais la modification le renvoie en brouillon jusqu'à la prochaine publication.

Inutile d'écrire le JSON à la main. WhatsApp Manager propose une interface Flow Builder, Meta offre un Flows Playground pour prévisualiser un Flow simple, et la Flows API permet à un logiciel de créer et publier des Flows automatiquement.

Comment fonctionne un WhatsApp Flow, étape par étape

Un Flow a deux faces. Le client voit un bouton, quelques écrans et une confirmation. L'entreprise voit un message envoyé, un Flow ouvert, puis une réponse structurée qui arrive sur son webhook avec chaque réponse étiquetée. Connaître les deux faces aide à repérer où ça casse.

Voici le parcours complet d'un Flow de réservation typique, tel que le décrit le guide d'envoi de Meta :

1. L'entreprise envoie un message qui porte le Flow. Soit un modèle de message avec bouton Flow (à l'initiative de l'entreprise, modèle à faire approuver), soit un message interactif avec bouton d'appel à l'action (dans une fenêtre de service ouverte). Le libellé du bouton d'un modèle est limité à 25 caractères ; Meta conseille 30 caractères maximum, sans emoji, pour le bouton d'un message interactif.
2. Le client touche le bouton. Le Flow s'ouvre sur son écran d'entrée, que l'entreprise peut préremplir avec ce qu'elle sait déjà, comme le nom du client.
3. Le client avance d'écran en écran. Chaque écran valide ses propres champs : une date obligatoire manquante ou un e-mail mal formé est repéré avant de continuer.
4. Le client envoie. Le bouton de pied de page de l'écran final déclenche l'action complete.
5. Les réponses reviennent. WhatsApp livre un message de réponse au webhook de l'entreprise, avec la valeur de chaque champ. Votre logiciel doit alors en faire quelque chose d'utile : créer le contact, réserver le créneau, mettre à jour l'affaire.

C'est à l'étape 5 que se cache l'essentiel du travail. Un Flow collecte très bien les réponses, mais le Flow ne range rien dans votre CRM. Ce qui reçoit le webhook décide si ces réponses deviennent un rendez-vous dans l'agenda ou un bloc de JSON dans un journal que personne ne lit.

Deux détails techniques comptent pour la planification. Chaque envoi porte un flow token, un identifiant généré par l'entreprise pour rattacher la réponse au bon client et au bon dossier. Et vous pouvez envoyer un Flow en mode brouillon pour le tester sur votre propre téléphone avant de le publier.

Les briques : écrans et composants

Un écran de Flow se construit avec des composants, et Meta plafonne leur nombre et la longueur de leurs textes. Les limites sont larges pour un formulaire de réservation ou de devis, étroites pour tout ce qui voudrait remplacer un site entier. Concevez vos écrans en fonction d'elles.

Voici les composants les plus utilisés par les petites entreprises, avec les limites de la référence de Meta en octobre 2026 :

Trois autres limites façonnent les vrais projets. Un écran contient au plus 50 composants. Le modèle de routage, qui indique quel écran mène où, autorise jusqu'à 10 branches. Et le Flow JSON complet ne peut dépasser 10 Mo. Pour les fichiers, Meta conserve les médias envoyés via un Flow sur son CDN jusqu'à 20 jours : récupérez-les rapidement.

La logique est possible aussi. Les composants If et Switch affichent ou masquent des parties d'écran selon les réponses précédentes, avec jusqu'à 3 niveaux d'imbrication pour If. Un écran peut ainsi demander « C'est pour une entreprise ? » et n'afficher le champ raison sociale que si la réponse est oui.

Flows avec et sans endpoint

Un Flow sans endpoint est un formulaire fixe : écrans, choix et routage sont définis d'avance, et les réponses reviennent à l'envoi. Un Flow avec endpoint appelle votre serveur entre deux écrans pour obtenir des données en direct, comme des créneaux libres ou un prix calculé. La plupart des formulaires de petite entreprise n'ont besoin d'aucun endpoint.

Sans endpoint. Tout ce que voit le client est écrit dans le Flow JSON ou transmis à l'envoi, et Meta génère le modèle de routage automatiquement. Une demande de devis avec des prestations fixes, un sondage de satisfaction, une inscription à un événement ou un formulaire de prospect s'y prêtent. Vous le créez dans le Flow Builder, le publiez, l'attachez à un modèle, et le côté WhatsApp est réglé.

Avec endpoint. L'action data_exchange envoie ce que le client a saisi à une URL que vous gérez, et votre serveur renvoie les données de l'écran suivant. C'est ainsi qu'un Flow de réservation n'affiche que les horaires vraiment libres, ou qu'un Flow de commande montre le stock du jour. Les exigences techniques sont réelles, toutes tirées du guide endpoint de Meta :

• Le serveur doit accepter des requêtes POST en HTTPS avec un certificat TLS valide.
• Chaque échange est chiffré : une clé AES arrive chiffrée en RSA, et les données utilisent AES-GCM. Votre serveur déchiffre chaque requête et chiffre chaque réponse.
• Il doit répondre aux contrôles de santé, un « ping » que WhatsApp peut envoyer à tout moment aux endpoints des Flows publiés.
• Le guide de surveillance de Meta vise une réponse en moins d'une seconde. Si le taux d'erreur ou la latence se dégradent nettement, Meta envoie des alertes par webhook, puis limite le Flow à 10 messages par heure, et si la situation empire, le bloque : il ne peut plus être envoyé ni ouvert.

Meta pousse elle-même vers l'option simple : son guide indique que les Flows avec endpoint devraient éviter de l'appeler quand ce n'est pas nécessaire, car s'en passer réduit la latence et simplifie le développement. Si vous pouvez transmettre les données du premier écran à l'envoi et naviguer avec navigate, faites-le.

8 exemples et cas d'usage des WhatsApp Flows

Les Flows sont rentables quand l'entreprise a besoin des mêmes réponses de chaque client, dans un ordre fixe, avec des choix qu'elle peut lister d'avance. Ces huit cas couvrent l'essentiel de ce que construisent les petites équipes, de la réservation à l'inscription, avec une note sur le besoin d'endpoint.

1. Prise de rendez-vous. Prestation, date souhaitée dans un CalendarPicker, plage horaire, nom et champ de remarques. Sans endpoint, le client choisit un créneau souhaité que vous confirmez ; avec, le Flow n'affiche que les créneaux libres. Pour les rappels qui suivent, notre guide des rappels de rendez-vous WhatsApp traite du bon timing.

2. Capture de prospects. Nom, e-mail, sujet d'intérêt, fourchette de budget et consentement marketing. Un Flow relié à une publicité click-to-WhatsApp transforme les clics en prospects complets en moins d'une minute. Notre guide de génération de leads sur WhatsApp montre où il se place parmi les autres sources.

3. Demande de devis. Type de travail, taille ou quantité, délai et photos via PhotoPicker. Les options fixes rendent les réponses comparables, et les photos évitent le premier aller-retour. Endpoint seulement si vous voulez un prix immédiat.

4. Avis client et sondages. Une note, deux ou trois questions à choix et un commentaire facultatif, envoyés après la prestation. Court et fixe, le terrain idéal des Flows. Restez sur un ou deux écrans.

5. Bon de commande. Produit, variante, quantité, livraison ou retrait et adresse. Un catalogue simple marche sans endpoint ; stock en direct, frais de port ou remises en demandent un. Pour une large gamme, comparez d'abord avec les fonctions catalogue de WhatsApp.

6. Inscription à un événement ou un cours. Session dans une liste déroulante, nombre de participants, besoins alimentaires ou d'accessibilité, consentement. L'inscription est le formulaire fixe par excellence, et un composant OptIn recueille au même moment l'accord pour les messages de suivi.

7. Prise en charge du support. Référence de commande ou de compte, type de problème, description et capture d'écran via DocumentPicker ou PhotoPicker. La personne qui répond démarre avec tout ce qu'il lui faut. Notre guide WhatsApp pour le service client couvre le reste du dispositif.

8. Préférences et consentements. Les sujets qui intéressent le client, la fréquence, et une désinscription claire. Une façon propre de recueillir le consentement que Meta exige avant les modèles marketing, puis de le respecter.

Leur point commun : l'entreprise peut écrire chaque question avant le début de la conversation. Quand la question suivante dépend d'une réponse libre, le formulaire commence à se battre contre la conversation.

Ce qu'il faut pour utiliser les WhatsApp Flows

Pour envoyer des Flows, il faut la WhatsApp Business Platform avec la Cloud API, une entreprise vérifiée, une bonne qualité de messages, un Flow publié et, pour les envois à votre initiative, un modèle approuvé. Il faut aussi un logiciel ou un développeur qui reçoit les réponses et agit. L'application WhatsApp Business ne peut pas envoyer de Flows.

La liste issue des guides de démarrage et d'envoi de Meta, avec les aspects pratiques :

• Un compte WhatsApp Business Platform. Il donne accès à WhatsApp Manager, où se trouve le Flow Builder, et à un numéro configuré sur la Cloud API. Notre comparatif application WhatsApp Business ou API explique ce qui change.
• La vérification de l'entreprise. Les guides de Meta indiquent qu'elle est obligatoire pour envoyer des Flows aux clients. Notre guide du compte WhatsApp Business vérifié détaille les étapes.
• Une bonne qualité de messages. Meta demande de la maintenir. Un numéro mal noté risque des limites d'envoi plus basses, donc moins de destinataires pour vos modèles avec Flow.
• Un modèle approuvé, si vous ouvrez la conversation. Son statut doit être APPROVED et non PENDING avant l'envoi. Notre guide des modèles de message WhatsApp couvre catégories et validation.
• Un récepteur pour les réponses. La réponse du Flow arrive sur votre webhook. Sans logiciel qui la transforme en contact, rendez-vous ou tâche, vous avez collecté des données sans les ranger nulle part d'utile.
• Un prestataire ou un développeur, sauf si votre équipe code. La plupart des entreprises créent leurs Flows avec les outils d'un prestataire ; avec un endpoint, il faut un développeur de toute façon.

Les limites d'envoi s'appliquent. En octobre 2026, la limite de la Platform commence à 250 destinataires uniques par 24 heures glissantes pour les conversations à l'initiative de l'entreprise, puis passe à 2 000, 10 000, 100 000 et illimité selon la qualité et la vérification. Un Flow attaché à un modèle marketing compte comme tout autre envoi de modèle.

L'appareil compte. La documentation de Meta indique Android 6.0+ et iOS 12+ et précise que les Flows ne sont pas pris en charge sur les appareils associés comme WhatsApp Web. Si beaucoup de vos clients écrivent depuis un ordinateur, certains verront le message sans pouvoir ouvrir le formulaire.

Combien coûtent les WhatsApp Flows ?

En octobre 2026, la page de tarification de Meta ne mentionne aucun frais séparé pour les Flows. Un Flow voyage sur un message, facturé selon les règles habituelles de Meta : un modèle avec Flow selon sa catégorie, un message interactif avec Flow dans la fenêtre de service comme message de service.

Concrètement, d'après la documentation tarifaire de Meta :

• Flow dans un modèle. Facturé par message livré, selon la catégorie du modèle (marketing, utilitaire ou authentification) et le pays du destinataire. Les modèles marketing sont toujours facturés.
• Flow dans un message interactif. Possible uniquement dans la fenêtre de service de 24 heures ouverte quand le client vous écrit. Depuis le 1er octobre 2026, chaque numéro professionnel dispose de 1 000 messages de service livrés par mois sans facturation ; le reliquat n'est pas reporté, et au-delà les messages de service sont facturés.
• Le point d'entrée gratuit. Si un client vous écrit depuis une publicité click-to-WhatsApp sur l'application Android ou iOS et que vous répondez à temps, une fenêtre de 7 jours au plus s'ouvre, pendant laquelle les messages marketing, utilitaires, d'authentification et de service ne sont pas facturés. Ordinateur et web ne comptent pas. Un Flow envoyé dans cette fenêtre ne coûte rien pour le message.
• L'envoi du client. Meta ne facture pas les messages que les utilisateurs envoient aux entreprises : la réponse contenant les données n'est pas facturée.
• Les tarifs. Meta ne peut modifier ses tarifs que le premier jour d'un trimestre, donc quatre fois par an au plus, avec préavis. Comme ils varient selon le pays du destinataire, fiez-vous à la grille à jour sur le site de Meta plutôt qu'à un chiffre publié ailleurs. Pour le détail des catégories, lisez notre guide tarifs de la WhatsApp Business API.

Le coût principal n'est souvent pas celui de Meta. C'est la construction : l'abonnement du prestataire qui inclut un Flow Builder, les heures de développement pour un endpoint, et le travail de connexion au CRM. Un formulaire de prospect fixe peut prendre un après-midi. Un Flow de réservation avec disponibilités en direct, chiffrement et surveillance est un vrai projet logiciel.

Limites et points de défaillance à anticiper

Les Flows échouent de façon prévisible : les clients sur WhatsApp Web ne peuvent pas les ouvrir, les formulaires longs sont abandonnés, les endpoints lents sont limités, et les réponses reçues par webhook n'arrivent jamais dans le CRM. Chaque problème s'évite si on le prévoit dès le départ.

L'abandon est invisible. Un client qui ouvre un Flow de cinq écrans et le ferme au troisième ne vous envoie rien. Vous ne savez qu'il l'a ouvert que si votre prestataire le signale. Faites court, mettez les questions faciles d'abord, et prévoyez une relance pour ceux qui n'envoient pas.

Le texte libre est à l'étroit. Un TextInput est limité par défaut à 80 caractères, un TextArea à 600. Suffisant pour un nom ou une courte description, frustrant pour qui veut expliquer une demande inhabituelle.

Tous les appareils ne les ouvrent pas. Le trou de WhatsApp Web est réel. Ajoutez toujours une ligne de secours dans le message, du type « Ou répondez simplement ici avec vos coordonnées ».

L'endpoint ajoute un point de panne. Un serveur lent donne un Flow limité, puis bloqué. Si votre Flow de réservation dépend de l'API de votre agenda, ses pannes deviennent vos pannes WhatsApp.

Chaque modification relance un cycle. Modifier un Flow publié le renvoie en brouillon, et changer le modèle qui le porte peut exiger une nouvelle validation.

Voici un Flow face aux deux alternatives courantes pour collecter les mêmes informations :

L'alternative sans Flow : demander dans le chat, enregistrer dans des champs

Pour beaucoup de prises d'informations, la meilleure option n'est pas un formulaire. Un assistant pose les mêmes questions une à une dans le chat, et chaque réponse s'écrit dans le bon champ de la fiche client dès son arrivée. Pas de Flow JSON, pas d'endpoint, et rien de perdu si le client s'arrête à mi-chemin.

Cela marche parce qu'une conversation est déjà une interaction structurée quand les questions sont fixes et les réponses bien rangées. « Quelle prestation vous intéresse ? », puis « Quand cela vous arrangerait ? », puis « À quelle adresse e-mail envoyer le devis ? » collectent les mêmes données qu'un Flow de trois écrans. La différence tient à ce qui se passe autour :

• Les réponses partielles comptent. Si le client répond à deux questions puis se tait, vous avez deux informations sur la fiche et une raison de relancer. Un Flow fermé avant l'envoi ne laisse rien.
• Ça marche partout. Un message simple s'ouvre sur tous les appareils, WhatsApp Web compris.
• Le client peut sortir du script. Si quelqu'un demande au milieu « Vous travaillez le week-end ? », un agent peut répondre puis revenir aux questions. Un formulaire, non.
• Tout reste dans la fenêtre. Les questions posées après que le client vous a écrit sont des messages de service, couverts par les 1 000 messages mensuels par numéro avant facturation.

Le compromis porte sur la longueur et la précision. Un formulaire de douze champs avec une liste de 200 éléments est pénible en chat et simple en Flow. Une prise d'infos de trois à cinq questions, c'est l'inverse. Notre guide du bot de qualification de leads WhatsApp explique comment choisir et ordonner ces questions, et notre article agent IA ou chatbot montre ce qui change quand une IA les pose à la place d'un script fixe.

Comment Zoye recueille des réponses structurées sur WhatsApp

Zoye est un AI Business Operator. Ses treize outils sont déjà reliés entre eux (contacts, affaires, tâches, agenda, documents, factures, automatisations WhatsApp et plus), et une assistante IA les pilote pour vous depuis l'application web, WhatsApp, Slack ou le connecteur Claude. Pour les réponses structurées sur WhatsApp, Zoye choisit la voie du chat plutôt que les Flows.

Les réponses données par un prospect sur WhatsApp arrivent sur sa fiche à côté des notes, et la personne qui le recontacte part avec toute l'information.

Le bot de qualification. Vous fixez les questions, l'ordre et la formulation. Le bot les pose dans le chat et enregistre chaque réponse dans le bon champ du CRM dès son arrivée : un prospect qualifié est déjà rempli quand vous l'ouvrez, et un prospect qui s'est arrêté en route garde ce qu'il a dit. Les réponses se filtrent comme n'importe quel champ, ce qui permet de bâtir une audience « intéressé par la prestation B, pour ce mois-ci » sans lire une seule transcription. L'ensemble des automatisations WhatsApp montre comment tout s'enchaîne.

Tout ce qui entoure les questions. Un nouveau prospect reçoit un message d'accueil immédiat, avec un réglage par source (publicités, formulaires, site, API, saisie manuelle) et un seul message par personne. L'agent IA répond à ce que le client demande vraiment, propose des créneaux depuis une seule liste de réservations avec des rappels envoyés automatiquement, peut envoyer un lien de paiement dans le chat (Stripe, ou Grow en Israël), et passe la main à un collègue quand un humain doit prendre le relais, avec toute la conversation déjà sur la fiche du prospect.

Créé à partir d'une description. Dites à l'assistante ce qui doit se passer, par exemple « quand un nouveau prospect arrive du site, demande-lui quelle prestation et quand il veut commencer, puis crée une tâche d'appel pour le responsable ». Zoye en fait une vraie règle, vous la présente en langage clair et n'exécute rien avant votre accord. Les six automatisations WhatsApp démarrent désactivées et chacune demande confirmation avant d'envoyer.

Les règles de Meta sont gérées. Zoye fonctionne sur la WhatsApp Business Platform officielle (Cloud API). Les premiers messages, et tout ce qui part plus de 24 heures après la dernière réponse du client, utilisent automatiquement un modèle approuvé ; Zoye classe les modèles, les soumet à Meta et suit leur statut. Chaque message sortant comporte une option de désinscription, et STOP est respecté dans tout l'espace de travail.

Limites honnêtes. Zoye ne crée pas de formulaires Flow JSON de Meta, et ce n'est ni un revendeur BSP, ni un outil d'envoi en masse, ni une suite de helpdesk. Si votre prise d'informations exige vraiment un long formulaire fixe avec des dizaines d'options, un Flow créé avec un outil dédié est le bon choix, et les frais de messages de Meta s'ajoutent à n'importe quel logiciel, Zoye comprise.

Tarifs : Almost Free coûte 5 $ par mois (4 $ en annuel) et couvre 1 membre, 1 Go, les outils de base, 15 prompts IA par mois et les intégrations Google ; les automatisations n'en font pas partie. Starter coûte 29 $ par mois (23 $ en annuel) avec 10 membres et 5 Go, Growth 59 $ (47 $) avec 20 membres et 10 Go, Scale 119 $ (95 $) avec 100 membres et 25 Go, et Customize est sur devis. Tous les détails sur la page tarifs.

Idéal pour : les petites équipes dont la prise d'informations WhatsApp tient en quelques questions et qui veulent chaque réponse sur la fiche du prospect, suivie de la bonne étape.

Faut-il créer un WhatsApp Flow ? Mini guide de décision

Créez un Flow quand votre prise d'informations est longue, fixe et riche en options, que vos clients sont sur mobile et que vous avez un logiciel pour recevoir les réponses. Posez les questions dans le chat quand elle est courte, quand les gens sortent du script, ou quand l'équipe ne peut pas maintenir un Flow JSON et un endpoint.

Passez votre processus au crible de quatre questions :

1. Combien de questions ? Plus de six, ou une liste de plus de dix options, penche vers un Flow. Trois à cinq penchent vers le chat.
2. Pouvez-vous écrire chaque question d'avance ? Si oui, un Flow est possible. Si la question suivante dépend de la réponse, le chat est meilleur.
3. Faut-il des données en direct ? Si le formulaire doit montrer de vrais créneaux ou un vrai stock, un Flow implique un endpoint et un développeur. Une conversation peut vérifier et répondre.
4. Où vont les réponses ? Si rien ne transforme une réponse de Flow en fiche, réglez cela d'abord. Un beau formulaire qui alimente un journal que personne n'ouvre vaut moins qu'une simple question qui arrive sur le bon contact.

Quelle que soit la voie, jugez-la au bout de deux semaines sur un seul chiffre : parmi ceux qui ont commencé à répondre, combien ont terminé, et combien sont devenus un rendez-vous, un devis ou une vente. Et si vous voulez la voie du chat avec vos prospects sur WhatsApp, chaque réponse enregistrée sur la fiche, consultez les tarifs ; la connexion de votre propre numéro professionnel arrive bientôt.

À lire aussi

• Génération de leads sur WhatsApp : 9 sources et la couche de capture
• Bot de qualification de leads WhatsApp
• Modèles de message WhatsApp
• Tarifs de la WhatsApp Business API