Confirmation COD

Pour une commande payée à la livraison, Trackily peut demander à l'acheteur de confirmer sa commande sur WhatsApp, par deux boutons. C'est le meilleur remède aux colis refusés — et l'option du module qui touche le plus directement à votre argent : elle peut annuler de vraies commandes et déplacer vos conversions publicitaires.

Concept

Une commande « paiement à la livraison » n'est qu'une intention : une part des acheteurs ne décroche pas, refuse le colis, ou a commandé par erreur. La confirmation COD pose la question avant l'expédition :

Commande COD passée ──▶ demande WhatsApp (Confirmer / Annuler) ──▶ l'acheteur clique
                                                                      │
                          ┌───────────────────────┬───────────────────┴───────────┐
                          ▼                       ▼                               ▼
                     Confirmer               Annuler                  Pas de réponse dans le délai
                 commande confirmée     refus noté (annulée si        la demande est close,
                 Purchase émis si       l'option est cochée)          Purchase émis quand même
                 retenu                 Purchase jamais émis          s'il était retenu

Tout se règle dans WhatsApp Marketing → Réglages, carte « Confirmation des commandes à la livraison (COD) ».

Les réglages, et ce qu'ils font vraiment

Les trois options sont indépendantes. Depuis l'agent IA, update_whatsapp_settings change ces réglages après une confirmation en deux temps.

Annuler sur refus : ce que ça coûte

C'est du chiffre d'affaires perdu sur-le-champ, et l'acheteur ne peut pas se raviser : une commande annulée le reste. La commande est annulée avec la note « refus WhatsApp », et son stock est remis si elle n'était pas encore expédiée. Si l'annulation échoue, Trackily la retente jusqu'à trois fois, à dix minutes d'intervalle, tant que la commande n'est pas expédiée — puis il faut l'annuler à la main.

Retenir le Purchase : ce que ça déplace

Vos pixels et vos rapports publicitaires verront moins de conversions, et plus tard : ils ne compteront plus que les commandes confirmées (ou restées sans réponse). C'est voulu — un signal plus propre. Mais si vos campagnes optimisent sur ces conversions, leur apprentissage va bouger, et le chiffre du jour paraîtra plus bas. Activez-la en connaissance de cause, et prévenez qui pilote vos campagnes.

Trois garanties tiennent cette option :

• un Purchase retenu est émis au plus une fois ;
• il n'est jamais émis pour une commande refusée, ni pour une commande annulée entre-temps ;
• un silence n'est pas un refus : sans réponse dans le délai, le Purchase part quand même, sinon une vente réelle resterait invisible pour toujours.

Si la demande n'a même pas pu être envoyée (voir « Quand la demande ne part pas »), rien n'est retenu : le Purchase part au placement, comme sans l'option.

Marquer la commande payée à la livraison

« Marquer payé » ne renvoie jamais un Purchase déjà parti : ni celui émis au placement (option éteinte, ou Purchase non retenu), ni celui émis à la confirmation ou à l'expiration. Si le Purchase est encore retenu (l'acheteur n'a pas répondu), il part au marquage, et la confirmation ou l'expiration qui suit n'en envoie pas un second. Avant le 26 septembre 2026, chaque marquage payé d'une COD renvoyait ses pixels : une livraison encaissée plusieurs jours après la commande comptait deux ventes dans vos régies.

Le Purchase envoyé par vos pixels (navigateur) et par la CAPI (serveur) porte le même identifiant, le numéro de commande (TR-000123) : Meta et TikTok le comptent une fois.

Le modèle de la demande

Le modèle doit :

• être approuvé et de catégorie UTILITY ;
• porter au moins deux boutons de réponse rapide, dont l'un a pour libellé votre « confirmer » et l'autre votre « annuler » ;
• s'il a des variables, les voir toutes remplies dans « Paramètres de la demande » (voir ci-dessous).

La comparaison ignore la casse, les espaces et les marques invisibles (celles que WhatsApp pose autour d'un texte arabe) : « Je confirme » et « JECONFIRME » sont la même réponse. Les libellés acceptent toutes les écritures, accents et emoji compris, 40 caractères au plus. Deux libellés identiques une fois comparés sont refusés : une même réponse ne peut pas valoir confirmation et annulation.

Les variables du modèle

Un modèle comme « Bonjour {{1}}, confirmez-vous la commande {{2}} ? » se remplit dans Paramètres de la demande : une clé par variable du modèle (body.1, body.2… — voir Modèles), et pour chacune un texte qui peut citer les variables d'une commande :

{ "body.1": "{{first_name}}", "body.2": "{{order_number}}" }

Seules les variables qu'une commande sait remplir sont acceptées : {{first_name}}, {{last_name}}, {{name}} (tirés du nom de la commande), {{order_number}}, {{order_total}}, {{order_subtotal}}, {{order_shipping}}, {{order_currency}}, {{order_date}}, {{order_items_count}}, {{order_items_text}}, {{order_payment_method}}, {{order_payment_status}}, {{customer_name}}, {{customer_phone}}, {{shipping_address}}, et celles du groupe d'un funnel à upsells : {{order_group_items_text}}, {{order_group_total}}, {{order_group_count}}, {{order_group_numbers}} (voir Les commandes de funnel). Un texte fixe (le nom de votre boutique) est accepté aussi.

L'enregistrement est refusé, avec un message qui dit quoi corriger :

• si une variable du modèle n'a pas de valeur (« il manque body.2 ») ;
• si une valeur cite une variable qu'une commande ne remplit pas — {{prenom}}, {{email}}, {{custom.ville}}, {{order_table}} : elle serait vide, et chaque demande échouerait.

Sous le champ, l'écran rappelle les variables du modèle choisi et marque en rouge celles qui n'ont pas de valeur. Regardez-le après avoir resynchronisé vos modèles : si Meta a ajouté une variable au modèle, les demandes ne partent plus (raison parametres_manquants) tant que vous ne l'avez pas remplie.

Une valeur vide pour UNE commande fait échouer SA demande. Un acheteur sans nom pour {{first_name}}, une adresse vide pour {{shipping_address}} : la demande de cette commande n'est pas envoyée, et le Purchase retenu part aussitôt, au passage suivant (cinq minutes au plus). Préférez {{order_number}} et {{order_total}}, qui existent toujours.

Pas de texte promotionnel dans une valeur fixe. « -20 % », « code promo », « livraison gratuite » : Meta peut reclasser un modèle UTILITY qui en porte en MARKETING, et la demande ne partirait plus. L'écran vous avertit quand une valeur fixe y ressemble.

Ces boutons n'existent que sur l'API officielle : Meta, 360dialog ou Twilio.

La confirmation COD ne fonctionne pas sur la voie SIM. Un modèle local ne porte pas de boutons : choisi comme modèle de la demande, il est écarté à chaque commande (raison modele_sans_boutons, même s'il a des variables), et le Purchase part au placement. Le bac à sable est écarté aussi : il ne reçoit aucune vraie réponse. Si vos confirmations comptent, mettez-les sur un compte de l'API officielle.

Un changement de libellé ne vaut que pour les demandes suivantes. Chaque demande garde les libellés contre lesquels ses boutons ont été vérifiés à son envoi : changer les libellés, ou même les échanger, pendant que des demandes attendent ne les dérègle pas, et un clic « Annuler » reste un refus. Le revers : si la correspondance était réglée à l'envers (le bouton « Oui » réglé en « annuler »), la corriger ne rattrape pas les demandes déjà envoyées ; elles se ferment à la réponse ou à l'expiration. L'option « Annuler la commande si l'acheteur refuse », elle, est lue au moment du clic : la cocher ou la décocher vaut aussi pour les demandes en attente.

Ce qui se passe, dans l'ordre

1. Au placement. La commande est COD, pas annulée, pas un aperçu, et elle n'a pas encore de demande. Trackily vérifie la licence, le modèle, ses boutons, le compte et le numéro de l'acheteur (lu avec le pays de la commande). Si tout va, la demande est mise en file — elle passe avant les étapes de séquence — et, si l'option est cochée, le Purchase est retenu.
2. Juste avant l'envoi. Le moteur relit la commande : une commande annulée entre-temps, ou dont la demande n'est plus attendue, ne reçoit rien — un message facturé pour rien, et un « Annuler » qui serait ignoré.
3. Au clic. La réponse n'est prise en compte que si c'est un clic sur un bouton de cette demande, venu du numéro de l'acheteur (sous l'une de ses écritures). Une réponse tapée à la main, ou venue d'un autre numéro, est ignorée : la commande reste en attente. Un double clic, ou un clic pendant l'expiration, ne tranche qu'une fois.
4. L'expiration. Toutes les cinq minutes, Trackily ferme les demandes dont le délai est dépassé, celles dont la commande a été annulée, et celles qui n'ont pas pu être remises (échec, sautée, annulée) — sans attendre le délai pour ces dernières. Une demande close encore en file est annulée. Ce passage tourne même sans licence et même option éteinte : un Purchase retenu doit toujours pouvoir sortir.

Une commande ne reçoit qu'une seule demande ; si deux placements se croisent, la seconde demande est annulée avant de partir.

Les commandes de funnel

Une commande COD passée dans un funnel reçoit la demande comme les autres, mais son Purchase n'est jamais retenu : le funnel émet le sien au moment de l'achat. Annuler sur refus s'applique normalement.

Un funnel avec des upsells : une seule demande, à la fin. Si le funnel a au moins une étape upsell active, la commande principale n'envoie rien au placement : Trackily attend que l'acheteur ait fini le funnel, puis envoie une seule demande pour la commande principale et ses upsells. Le funnel est fini quand l'acheteur arrive sur la page de merci (ou sur une sortie externe) — la demande part dans la minute — ou, s'il s'arrête en route, quand la fenêtre d'upsell du funnel se ferme (15 minutes après le dernier achat par défaut, 2 heures au plus après le premier ; l'agent IA règle ces deux durées par update_funnel, champs upsell_window_min et upsell_window_max_min). Aucun réglage WhatsApp de plus.

• La réponse vaut pour tout le groupe. « Confirmer » confirme la commande et ses upsells. « Annuler », si l'option « Annuler la commande si l'acheteur refuse » est cochée, annule les upsells pas encore expédiés, puis la commande principale ; un upsell déjà expédié n'est pas touché, le journal le signale pour que vous le traitiez à la main. L'acheteur ne peut pas garder la commande et refuser un seul upsell : c'est tout ou rien.
• Pour lister les achats dans le message, utilisez dans « Paramètres de la demande » les variables du groupe : {{order_group_items_text}} (les articles de la commande et de ses upsells), {{order_group_total}} (le total du groupe), {{order_group_count}} (le nombre d'achats) et {{order_group_numbers}} (les numéros de commande). Hors funnel, ou sans upsell acheté, elles valent la commande seule : un même modèle sert partout.
• Les conditions sont vérifiées à la fin du funnel, avec vos réglages de ce moment : une option éteinte pendant le funnel, ou une commande annulée entre-temps, et rien ne part.
• Un funnel sans étape upsell active garde la demande tout de suite, comme avant.
• Seule la première commande de la visite attend. Si l'acheteur a d'abord abandonné un paiement par carte (commande annulée), puis commande en COD dans la même visite, cette seconde commande reçoit sa demande tout de suite. Avant le 26 septembre 2026, elle attendait une fin de funnel qui ne l'envoyait jamais.
• Si un paiement d'upsell est encore en cours quand l'acheteur arrive au merci, Trackily attend qu'il aboutisse, ou la fin de la fenêtre d'upsell, avant d'envoyer la demande. La demande et le Purchase comptent alors cet upsell. Avant le 26 septembre 2026, ils partaient sans lui.
• Un funnel ne se supprime pas tant qu'un acheteur est dans sa fenêtre d'upsell, même en pause : la suppression est refusée (fenetres_ouvertes). Réessayez après la fermeture de la fenêtre, 2 heures au plus après l'achat. Avant le 26 septembre 2026, la suppression passait, et la demande de ces acheteurs ne partait jamais.

Si le serveur s'arrête au moment précis où le funnel se ferme, la demande de ce funnel peut ne jamais partir : la commande reste active, confirmez-la par téléphone.

Quand la demande ne part pas

La commande est alors marquée « non envoyée » avec sa raison, et le Purchase suit le comportement sans confirmation (émis au placement). Les raisons possibles : licence absente, modèle absent ou non approuvé, modèle sans deux boutons de réponse rapide (modele_sans_boutons), boutons qui ne portent pas vos deux libellés (boutons_non_reconnus), variable du modèle sans valeur dans « Paramètres de la demande » (parametres_manquants, le détail la nomme), compte désactivé, compte du bac à sable, numéro de l'acheteur illisible. Deux autres cas n'apparaissent qu'au moment de créer la demande : un modèle qui n'est pas UTILITY (raison envoi_impossible, détail categorie_non_transactionnelle), et un numéro bloqué pour tout dans les Suppressions (raison envoi_non_cree). Avant le 26 septembre 2026, tout modèle à variables était écarté : les commandes de cette période gardent la raison modele_a_variables.

Où voir les demandes

Au Journal des envois, nature « Confirmation COD » : chaque demande, son état de remise et sa raison en cas d'échec. Une demande sautée en demande_perimee est une demande qui n'avait plus d'objet au moment de partir (commande tranchée, expirée ou remplacée).

Une demande échouée en envoi_incertain est peut-être arrivée : le fournisseur a répondu 502 ou 504, ou n'a pas répondu deux fois. Trackily ne la renvoie pas, l'attente se ferme comme une demande non remise, et le Purchase part. Si l'acheteur répond quand même, sa réponse ne se rattache pas à la commande : vérifiez la conversation avant de confirmer ou d'annuler à la main. Pendant une panne, les autres demandes du compte attendent 5 minutes au lieu d'échouer à leur tour (filtre « Envoi incertain » du journal pour les retrouver).

Erreurs courantes

• Aucune demande ne part — l'option est éteinte, aucun modèle n'est choisi, ou le modèle ne remplit pas les conditions (voir les raisons ci-dessus). Après une resynchronisation des modèles, regardez le rappel sous « Paramètres de la demande » : une variable ajoutée par Meta et non remplie écarte chaque commande (parametres_manquants).
• « Réglage wa_cod_params incomplet » ou « invalide » à l'enregistrement — une variable du modèle n'a pas de valeur, ou une valeur cite une variable qu'une commande ne remplit pas. Le message nomme la clé et la variable ; corrigez puis réenregistrez.
• Des demandes échouent en parametre_manquant au Journal des envois — une variable s'est rendue vide pour ces commandes-là (acheteur sans nom, adresse vide). Leur Purchase n'est pas perdu : retenu, il part au passage suivant. Choisissez des variables toujours remplies. Une panne passagère de la base au moment de l'envoi ne produit pas cet échec. La demande reste « en cours d'envoi » et repart 10 minutes plus tard. Avant le 26 septembre 2026, elle échouait en parametre_manquant.
• Les clics ne font rien — le webhook du compte n'est pas configuré chez le fournisseur : les réponses ne remontent pas (voir Comptes ; sur 360dialog, Trackily le pose lui-même, et la dernière erreur du compte dit s'il n'a pas pu).
• Des commandes refusées ne sont pas annulées — l'option « Annuler la commande si l'acheteur refuse » est éteinte, ou l'annulation a échoué trois fois : annulez-la à la main.
• Le chiffre du jour a baissé dans vos régies — c'est l'effet attendu de « Retenir le Purchase » : les conversions arrivent à la confirmation.
• Une commande refusée a été expédiée quand même, et sa conversion n'apparaît jamais — un refus ne libère jamais le Purchase retenu, même si vous décidez ensuite d'expédier.

Voir aussi

• Modèles — synchroniser le modèle à deux boutons
• Déclencheurs — le message après achat, qui ne part jamais pour une commande COD
• Rotation — pourquoi les confirmations ne partagent pas le numéro des campagnes
• Commerce — Commandes — les commandes et leur annulation