Produit
Comment automatiser la confirmation d'une commande COD sur WhatsApp ?
Une règle Nawras s'écrit en une phrase : quand un événement se produit, si des conditions sont réunies, alors une action part. Huit événements sont disponibles — de la commande créée au colis bloqué chez le transporteur — et les conditions puisent dans les faits réels de la commande : total, ville, zone, origine, produit. Ce qui distingue une règle Nawras d'une automatisation ordinaire, c'est qu'elle ne s'arrête pas à l'envoi : le client reçoit des boutons, et vous décidez de la suite pour chacune des quatre issues possibles, y compris l'absence de réponse.
Quand, Si, Alors — et rien à taper
Une règle tient en trois morceaux : l'événement qui la réveille, les conditions qui décident si elle vous concerne, l'action qui part. Vous ne l'écrivez pas, vous la choisissez — chaque morceau se prend dans une liste que le produit vous sert, et une valeur hors liste ne peut pas être saisie.
Nouvelle date après un échec
Quand
Échec de tentative de livraison
Si
Nombre de tentativesest égal à1
ETZone logistiqueest égale àRurale
Alors
Envoyer un WhatsApp
Modèle « Nouvelle date de livraison » · Numéro principal
41 exécutions · dernière il y a 3 h
Les huit événements qui peuvent réveiller une règle
- Nouvelle commande créée
- Statut de commande modifié
- Client injoignable
- Rappel dû
- Échec de tentative de livraison
- Commande bloquée trop longtemps
- Message WhatsApp reçu
- Bouton de message automatique cliqué
Les conditions lisent la commande, pas une étiquette
Onze faits sont comparables : le total, la ville reconnue, la région, la zone logistique, le nombre d'articles, le nom du client, les frais de livraison, la source, l'origine, la campagne et les produits. La ville comparée est celle que le dictionnaire a reconnue, jamais ce que le client a tapé — « casa », « dar lbida » et « الدار البيضاء » désignent la même ville, et une règle écrite sur la saisie brute en aurait manqué les trois quarts sans que rien ne le signale.
Une adresse illisible porte un nom
Quand le dictionnaire ne reconnaît pas la ville d'un client, la commande n'obtient pas une valeur vide : elle obtient « inconnue », et vous pouvez écrire une règle dessus — « ville non reconnue, préviens-moi, je regarde à la main ». Sans ce nom, une condition négative du type « région autre que Casablanca-Settat » aurait attrapé toutes les adresses illisibles, en silence.
Un message reçu n'est pas une commande
Deux des huit événements naissent d'une conversation et non d'une commande : un client peut vous écrire sans avoir jamais rien acheté. Ceux-là n'offrent donc pas les faits d'une commande — vous proposer un filtre sur le total reviendrait à vous proposer un filtre qui ne serait jamais vrai.
Puis elle attend la réponse, et repart différemment pour chacune
C'est le moment exact où une automatisation ordinaire s'arrête. Le client reçoit trois boutons ; il en clique un, ou aucun. Ces quatre issues sont fixées une fois pour toutes dans le produit — vous ne les inventez pas, vous décidez seulement de ce que chacune déclenche.
S'il confirme
Répondre par un message · Prévenir l'équipe
La décision est prise, et c'est justement pour ça que cette sortie ne peut pas confier le fil à l'agent IA. Lui donner la main ici rouvrirait une mission sur un objectif déjà atteint : un agent chargé d'obtenir une confirmation qu'il vient de recevoir. Cette interdiction n'est pas une précaution d'écriture — c'est un incident de production qui l'a posée.
S'il annule
Répondre par un message · Prévenir l'équipe
Vous êtes prévenu tout de suite, pendant qu'il est encore possible de sauver la vente. Même interdiction de passation, pour la même raison exactement : la décision est prise, il n'y a plus d'objectif à poursuivre.
S'il demande une modification
Prévenir l'équipe · Confier à l'agent IA
C'est la seule sortie où le produit vous retire l'envoi, et c'est voulu : « Modifier » ouvre une vraie conversation. Elle appartient à l'agent IA ou à un humain, pas à une phrase figée écrite trois semaines plus tôt, qui ne saura pas quoi répondre à « vous pouvez me livrer samedi plutôt ? ».
S'il ne répond pas
Envoyer un modèle approuvé · Prévenir l'équipe
Le silence est la seule issue qui se programme : vous choisissez le délai dans une liste de cinq — une heure, six heures, un jour, deux jours, trois jours. Une liste fermée plutôt qu'une saisie libre, parce qu'un délai tapé à la main crée un rendez-vous que plus personne n'attend.
Aucune des quatre ne peut changer le statut
Le clic vient déjà de faire bouger la commande. Y réagir ferait rentrer la règle dans sa propre trace, et c'est le mode de panne qui rend les outils d'automatisation effrayants. Chaque sortie accepte jusqu'à cinq actions, et une sortie laissée vide ne fait simplement rien.
Modèle ou message libre : ce n'est pas vous qui choisissez
WhatsApp n'autorise un message écrit librement que dans les vingt-quatre heures qui suivent le dernier message du client — cette période s'appelle la fenêtre de service. Passé ce délai, seul un modèle approuvé à l'avance peut partir. Nawras ne vous demande pas de suivre cette règle : le mode découle de la sortie, il est donc connu au moment où vous écrivez la vôtre.
La fenêtre de service, en une phrase
Le client vous écrit, ou clique un bouton : la fenêtre s'ouvre pour vingt-quatre heures. Pendant ce temps vous lui répondez ce que vous voulez, et Meta ne facture rien. Ensuite, il faut un modèle approuvé, et celui-là est facturé.
Un clic vient d'ouvrir la fenêtre, donc message libre
Les trois sorties de bouton n'acceptent que le message libre. Vous l'écrivez en clair, jusqu'à mille caractères, et vous y glissez des variables en cliquant dessus : le nom du client, son numéro de commande, le montant, la liste de ses articles, son lien de suivi.
Le silence veut dire fenêtre froide, donc modèle
Une relance après vingt-quatre heures est toujours un modèle approuvé. Nawras ne vous laisse pas configurer l'inverse — pas par prudence, mais parce que l'inverse est refusé par WhatsApp, et qu'un envoi qui échoue en silence coûte plus cher qu'un envoi qu'on n'avait pas prévu.
Le mode n'est jamais deviné à l'envoi
S'il était choisi à l'exécution, deux clients ayant cliqué le même bouton à deux minutes d'écart recevraient deux choses différentes, et vous ne sauriez pas laquelle est partie à qui. Il est donc fixé sortie par sortie, et l'éditeur ne vous propose que ce qui peut réellement partir.
Les variables se cliquent, elles ne se tapent pas
Dix variables sont servies avec l'éditeur, sous forme de puces. Une variable inventée ferait échouer l'enregistrement sans vous dire quoi écrire à la place — une liste cliquable rend la faute impossible au lieu de la rendre compréhensible. Et si l'une d'elles n'a pas de valeur sur une commande, elle disparaît du message : le client ne lit jamais notre mécanique interne.
Quand la règle renonce, et ce qu'elle fait ensuite
Une règle qui envoie coûte que coûte finit par parler par-dessus quelqu'un. Nawras préfère renoncer — mais renoncer sans abandonner : chaque renoncement porte, ou non, l'instant où sa cause cessera de s'appliquer, et c'est cette présence qui décide de la suite.
Une seule voix par clic
Quand un client clique, Nawras lui répond par un accusé de réception. Si votre règle prévoit une réponse à ce clic, c'est elle qui parle et l'accusé se tait : jamais deux messages. Une sortie qui se contente de prévenir votre équipe ne parle pas au client — l'accusé reste donc à sa place, sinon le client aurait cliqué dans le vide.
Ce qui la fait renoncer
Quelqu'un de votre équipe est en train de répondre à ce client. L'agent IA a un tour en cours. Vous avez coupé ce numéro, ou atteint le plafond quotidien que vous lui avez fixé. La fenêtre de service est refroidie. Dans tous ces cas la règle se retire : elle n'a rien à ajouter à quelqu'un qui parle déjà.
Un motif temporaire repose la question, une fois
Quand la cause a une fin connue — une réponse humaine en cours tient deux minutes, un tour d'agent quelques secondes — la question est reposée à l'instant calculé où cette cause aura cessé. Une fois, jamais deux : un report qui reporte un report est une boucle qui a l'air d'un service.
L'absence de date de reprise EST la définition de « définitif »
Un abonnement suspendu ne se réactive pas dans l'heure : il n'y a aucun instant de reprise à écrire, donc aucun report. Il n'existe pas, dans le produit, de liste de motifs définitifs à tenir à jour — l'absence de date suffit à trancher, ce qui rend impossible d'oublier un motif d'un côté et pas de l'autre.
Au bout du report, une notification — pas un silence
Si le report renonce à son tour pour une cause encore temporaire, vous êtes prévenu. C'est le seul moment où vous devez le savoir : prévenir au premier renoncement aurait été du bruit, puisque le système allait réessayer tout seul.
Ce qu'elle écrit quand elle n'a rien envoyé
Un historique d'automatisation qui n'affiche que des succès finit par ne plus être lu. Chaque exécution garde donc ce qu'elle a fait, ce qu'elle n'a pas fait, et pourquoi — au même endroit et avec le même sérieux.
Trois verdicts, pas deux
Réussie, échouée, ou renoncée. Le troisième existe parce qu'un renoncement n'est pas une erreur — le système vient au contraire de bien se comporter. Mais une exécution dont toutes les actions ont renoncé n'a rien produit, et l'afficher en vert apprend à ignorer l'historique. Une action qui renonce à côté d'une action qui aboutit reste, elle, un succès : c'est le cas total qui ment.
Le motif est écrit, pas résumé
« Un humain répondait », « la fenêtre était fermée », « le numéro était coupé », « le plafond du jour était atteint ». Quand une seule action a renoncé, son motif remonte sur l'exécution entière ; quand plusieurs ont renoncé pour des raisons différentes, chacune garde la sienne — un motif moyen ne serait vrai pour aucune.
Une exécution ne se rejoue jamais
Un envoi n'est pas une opération qu'on peut refaire sans conséquence : la rejouer, c'est un message en double chez le client. Une exécution interrompue en plein vol est donc marquée comme interrompue et laissée telle quelle, plutôt que reprise « pour bien faire ».
Une annulation automatique porte son propre nom
Quand une règle annule une commande, elle l'inscrit comme telle : « règle d'automatisation ». Elle n'emprunte aucun des motifs humains — doublon, client injoignable, annulation du marchand. Ce n'est pas du vocabulaire : l'un de ces motifs sort la commande de vos taux de performance, et votre taux de confirmation aurait grimpé tout seul à chaque annulation automatique.
Questions fréquentes
Faut-il savoir coder pour écrire une règle ?
Non, et il n'existe aucun champ où l'on pourrait essayer. Chaque morceau se choisit dans une liste que le produit vous sert : les événements disponibles, les faits comparables pour l'événement retenu, les opérateurs autorisés pour ce fait, et les valeurs quand elles sont connues à l'avance — les douze régions du Maroc, les zones, vos numéros, vos modèles approuvés. Une valeur hors liste n'est pas refusée après coup : elle ne peut pas être saisie.
Mes clients peuvent-ils recevoir deux messages pour un seul clic ?
Non. Un clic déclenche une seule voix vers le client : soit l'accusé de réception automatique, soit la réponse que votre règle prévoit — jamais les deux. Une sortie qui se contente de prévenir votre équipe ne parle pas au client, l'accusé reste donc à sa place. Et si la réponse de votre règle renonce, personne ne parle : l'accusé n'est pas rejoué derrière, parce qu'un rattrapage qui arrive après coup ressemble à une panne, pas à une politesse.
Et si mon client répond n'importe quoi au lieu de cliquer ?
Aucun message automatique ne part, et c'est délibéré : une règle ne sait pas lire une intention dans une phrase libre. L'événement « message WhatsApp reçu » existe bien — vous pouvez filtrer sur le type de message ou sur un mot qu'il contient — mais il n'autorise qu'une seule action : prévenir votre équipe. Répondre à une phrase est le travail de l'agent IA ou d'un humain, et la conversation les attend dans la boîte partagée.
Puis-je automatiser sans jamais envoyer de message ?
Oui. Trois actions ne parlent à personne : prévenir votre équipe, confier la commande à un membre nommé, et annuler la commande. Vous pouvez donc aiguiller vos commandes dès leur création — celles au-dessus d'un certain montant vers votre meilleur confirmateur, celles d'une zone rurale vers la personne qui la connaît — sans qu'un seul message parte. L'aiguillage nomme toujours quelqu'un : il n'existe pas de « répartir au moins chargé », parce que deux règles qui poursuivent le même équilibre se contredisent à la milliseconde près.
Une règle peut-elle se déclencher en boucle sur elle-même ?
Non, et c'est une décision de conception plutôt qu'une promesse. Une action qui fait bouger le statut d'une commande — l'annulation, mais aussi l'assignation à un membre, qui emprunte la même transition — est bloquée dès que ce statut a lui-même été bougé par une automatisation. La chaîne s'arrête donc au premier maillon, et une borne à trois niveaux ferme le cas général. Un blocage n'est jamais silencieux : il s'écrit dans l'historique sous son nom, comme n'importe quel autre renoncement.
Prêt à reprendre le contrôle ?
Créez votre espace en 2 minutes et mesurez l'impact dès la première semaine.
Zéro dirham. Zéro engagement. Annulation en 1 clic.
