« Où est ma commande ? » Automatisez le suivi Shopify et WooCommerce

Une politique d’expédition décrit un délai habituel. Elle ne dit pas si le colis d’un client précis est parti. Connecter votre site lit le catalogue public ; Commandes relie le système privé. Widget, politiques entraînées et catalogue ne donnent pas accès aux commandes.

Ouvrez un agent dans votre compte intoCHAT, allez dans Actions et trouvez Commandes sous Réservation. Choisissez Shopify ou WooCommerce. Chaque agent connecte une boutique. Il lit les commandes sans pouvoir les annuler, les modifier ou les rembourser. Ajoutez aux Connaissances les procédures d’expédition et de colis manquants pour expliquer la suite quand les données sont incomplètes.

Utilisez l’adresse permanente .myshopify.com, pas votre domaine personnalisé. Si Installer sur Shopify est proposé dans Commandes, suivez le parcours et approuvez la lecture demandée dans Shopify. Sinon, utilisez l’option documentée d’app personnalisée.

Tester et connecter vérifie l’accès et la lecture de l’e-mail nécessaire à la correspondance. Si l’accès aux données client protégées bloque l’e-mail, corrigez cette autorisation. Une commande sans e-mail lisible n’est jamais montrée au visiteur.

Saisissez l’adresse HTTPS de WordPress dans Commandes. HTTP et les adresses de réseaux privés ou internes sont refusés. Dans WordPress, ouvrez WooCommerce → Réglages → Avancé → REST API → Ajouter une clé. Choisissez un utilisateur pouvant gérer les commandes, sélectionnez Lecture et générez la clé.

Collez consumer key et consumer secret dans intoCHAT puis Tester et connecter. Le contrôle demande le nom de la boutique et l’identifiant d’une commande récente, sans afficher de données client. Corrigez les accès ou la configuration si les clés sont refusées ou l’API inaccessible avant de tester une demande.

WooCommerce ne fournit pas de suivi de colis par défaut. Il faut Shipment Tracking ou un plugin enregistrant les données au format pris en charge. Un plugin de numérotation personnalisée peut aussi influer : intoCHAT cherche une correspondance exacte, mais retrouver le numéro dépend du plugin.

Sans e-mail transmis pour un visiteur connecté, l’outil demande numéro de commande et e-mail utilisé à l’achat. Un mauvais e-mail produit le même résultat visible qu’une commande absente. Avec vérification d’identité et e-mail transmis par le site, cet e-mail est utilisé et celui saisi dans le chat est ignoré. Seul l’identifiant utilisateur est signé : ce n’est pas une preuve indépendante de possession de l’e-mail.

Exemple fictif : Alpine Desk est un commerçant inventé et la commande #1042 est inventée. Première réponse illustrative : « Quel e-mail avez-vous utilisé à la caisse ? Il me faut cette information pour vérifier la commande. » Si l’outil confirme paiement, traitement effectué et lien de suivi, une réponse possible est : « La commande #1042 est payée et traitée. Voici le lien de suivi fourni par la boutique. » Ce sont des attentes, sans test d’un commerçant ou d’une commande réels pour ce guide.

Le modèle reçoit numéro et date, état du paiement et du traitement, annulation, titres, variantes et quantités, transporteur et suivi disponibles, total et devise. La vue limitée exclut adresses, téléphones, cartes, notes client, e-mail et autres commandes. Un état de traitement ne prouve pas une date d’arrivée.

Chaque échec appelle une suite adaptée. Une panne du fournisseur n’est pas une correspondance de propriété refusée. Ces cas illustrent les attentes, pas des résultats d’une boutique connectée.

Adaptez-les à votre support. Elles n’activent pas Commandes, n’accordent pas d’accès et ne connectent aucun transporteur.

Activez le relais e-mail ou le chat en direct dans Configuration si votre équipe doit intervenir. Le direct exige une personne en ligne ; le relais e-mail demande accord et adresse de réponse. Confirmez l’envoi après le succès de l’action, sans promettre un délai absent du processus.

Retours et échanges est une option distincte de Commandes, désactivée au départ. L’agent recueille articles, quantités, retour ou échange et motif, puis vérifie à nouveau la commande. Un succès enregistre une demande pour l’équipe. Il ne valide pas le retour, ne rembourse pas, ne crée pas d’étiquette et ne modifie pas la boutique.

Réponse fictive attendue après succès : « Votre demande pour un article de la commande #1042 a été reçue. La boutique vous recontactera. » Accord et résolution restent dans le support normal. Les retours apparaissent dans l’onglet Leads ; les notifications dépendent de vos canaux configurés.

Partez du modèle de suivi et adaptez politiques et destination du support. Dans le Playground, utilisez votre commande de test : correspondance correcte, e-mail volontairement faux, commande sans suivi et relais. Les consultations y sont réelles et comptent dans les limites ; e-mails et retours peuvent notifier l’équipe. Coordonnez ces vérifications.

Consultez Pourquoi cette réponse pour la recherche de commande et le journal d’accès dans Commandes. Les clients simulés vérifient les règles de dialogue mais simulent commandes et retours : ils ne prouvent pas l’accès réel. Ce guide ne rapporte ni test réel de boutique ni baisse mesurée des demandes.

La démo publique ci-dessous montre uniquement la découverte de produits publics. Elle n’accède pas aux commandes privées et ne valide pas ce parcours. Créez un compte intoCHAT, configurez Commandes avec un accès autorisé et suivez la documentation. La checklist suisse couvre le déploiement multilingue plus large.