Relance panier : plugin vs CRM

🧺 Ce qu'un plugin fait bien

Un plugin de relance voit le panier, attend 1 h / 24 h / 72 h, envoie un mail avec un lien. Pour une boutique qui démarre, c'est assez. Pas de sync, pas de second outil, pas de RGPD en double. La TMA comprend déjà Woo ou Presta.

Ça casse quand on veut trop : coupons dynamiques, SMS, score, exclusion des relances marketing. Le plugin s'empile. Les mails de commande et les relances partagent un SMTP saturé. Voir l'article sur les mails de commande qui tombent en spam.

🧠 Ce qu'un CRM change

Le CRM (ou l'ESP) reçoit un événement « panier », pas une copie de toute la boutique. Il sait déjà qui a ouvert, qui est client, qui s'est désinscrit. La boutique reste la caisse. Le CRM reste la conversation.

Le coût : connecteur, mapping, RGPD, une TMA de plus. Sans événement fiable (webhook mort), le CRM relance des fantômes. On teste comme un paiement.

• Événement panier fiable
• Désinscription unique
• Adresse d'expéditeur alignée sur le DNS (SPF, DKIM, DMARC)
• Pas de relance si commande passée

⚠️ Pièges des deux côtés

Plugin : mails qui partent après commande, templates moches, conflit avec le cache, cron qui ne tourne pas (voir wp-cron). CRM : double opt-in mal compris, sync stock de 4 h, relance d'un prix faux.

Les deux mentent si le tunnel est cassé. Relancer vers un tunnel de vente en erreur 500, c'est payer pour de la colère.

On ne relance pas un panier plus vite qu'on ne répare la caisse.

✅ Décider en une réunion

Volume, canaux, qui rédige les mails, qui tient le SMTP. Si la réponse est « le stagiaire et le module à 49 € », restez plugin, soignez l'adresse d'expéditeur. Si la réponse est « on a déjà un CRM pour la newsletter », branchez l'événement, n'achetez pas un second plugin fourre-tout.

Je pose souvent le plugin 90 jours, on mesure, on décide. La relance n'est pas une religion.

✅ Liste de contrôle avant la première relance

Avant de choisir l'outil, j'écris combien de paniers sont abandonnés, à quelle étape et avec quelle adresse mail connue. La mesure qui compte : les commandes récupérées par la relance, pas le taux d'ouverture des mails.

Sauvegarde restaurable, mesure du taux de paniers récupérés avant, accès admin à votre nom. Puis la mise en route. Puis un mois d'observation : mails envoyés, réclamations, ventes récupérées. Sans cette mesure, on envoie des mails, sans savoir si le chiffre d'affaires suit.

• Taux d'abandon par étape relevé sur un mois
• Copie de test avant le premier envoi
• Un changement à la fois, documenté
• Test complet d'un panier abandonné, puis suivi des commandes récupérées pendant un mois

📌 Ce que je refuse sur ce sujet

Je refuse d'envoyer des relances à des clients qui n'ont pas accepté de recevoir des mails. Je refuse aussi d'empiler trois relances et un code promo automatique qui apprend aux clients à attendre.

Si les abandons viennent du tunnel lui-même, on corrige d'abord le tunnel. Un outil de relance ne rattrape pas des frais de port découverts au dernier moment.

🧭 Questions fréquentes

Faut-il changer de solution tout de suite ? Oui si les relances partent en double, tombent en spam ou ralentissent la boutique. Sinon, on mesure d'abord ce que rapporte l'outil actuel avant d'en acheter un autre.

Peut-on brancher une relance sans site de test ? Non : une règle mal posée envoie un mail à tous les paniers d'un coup. Voir la page Maintenance PrestaShop et l'article Tester un site WordPress en local et en préprod pour la préparation d'une copie de test.

Combien de temps ? Souvent une journée pour un plugin, une à trois semaines pour un CRM avec ses scénarios. Un devis « relance en deux heures » ne contrôle pas ce que reçoit réellement le client.