Service client e-commerce — moins de tickets « où est mon colis »

Le service client e-commerce s'enlise souvent non pas dans les cas difficiles, mais dans des questions que le client n'aurait pas eu besoin de poser s'il avait eu l'information plus tôt. « Où est mon colis ? » est une catégorie de demande si répétitive dans l'e-commerce que le secteur lui a donné son propre nom — WISMO — même si aucun organisme de normalisation n'en a jamais donné de définition formelle. Cet article examine ce qui permet réellement d'anticiper cette question — communication de statut, processus de réclamation clair — et où un chatbot aide vraiment, et où il ne fait qu'ajouter un écran supplémentaire entre le client et la réponse.

« Où est ma commande ? » — WISMO, une catégorie, pas une norme

WISMO signifie « Where Is My Order » (où est ma commande), utilisé dans l'e-commerce et les outils de service client pour désigner une catégorie de ticket précise et très fréquente. Shopify le dit sans détour : « WISMO stands for 'Where is my order?' and represents one of the most common types of customer inquiries for ecommerce merchants » (consulté le 1er octobre 2026). Freshworks le présente de la même manière : « A WISMO call is a 'where is my order' inquiry. These occur between the purchase and delivery stages, especially if an order is taking longer than expected » (consulté le 1er octobre 2026).

Il convient d'être clair sur ce que WISMO n'est pas : ce n'est pas un terme formellement normalisé par un organisme de normalisation — c'est une terminologie qui s'est imposée dans les contenus des éditeurs e-commerce et help desk (Shopify, Freshworks), répétée de façon assez constante dans le secteur pour devenir une étiquette communément comprise, sans source de référence unique faisant autorité. Cela n'a pas d'importance pour la gestion d'une boutique — ce qui compte, c'est ce que cela décrit : un ticket qui n'est pas causé par un problème avec la commande, mais par le fait que le client n'a pas l'information de statut dont il a besoin au moment où il en a besoin.

Pourquoi isoler cette catégorie avant de s'attaquer au reste de la file de support ? Parce que, pour un ticket WISMO, la réponse est toujours la même pour un statut donné — « votre commande est en route, livraison prévue le [date] » ne change pas d'un client à l'autre, seuls la date et le numéro de suivi changent. Cela fait de cette catégorie une excellente candidate pour anticiper complètement la question plutôt que d'attendre qu'elle soit posée — contrairement aux réclamations ou aux questions commerciales, où la réponse dépend réellement de la situation propre à chaque client.

Notifications de statut — anticiper la question avant qu'elle ne soit posée

Le mécanisme qui réduit les tickets WISMO est simple : le client est informé de chaque changement de statut de sa commande (acceptée, expédiée, en transit, livrée) automatiquement, au moment où il se produit — par e-mail, SMS ou dans son espace client — plutôt que de l'apprendre seulement quand il le demande. Cela nécessite deux choses à la fois : une intégration entre votre système de commandes et le transporteur (pour que le statut parvienne réellement à votre boutique dans un délai raisonnable) et un canal que le client consulte effectivement (un e-mail qui tombe dans les spams, ou un SMS envoyé à un numéro obsolète, n'aidera pas, quelle que soit la qualité du mécanisme lui-même).

Le volet technique de cette intégration — données transporteur, poids volumétrique, tarification des colis professionnels par la Poste Suisse — est un sujet distinct, traité dans notre article sur la livraison e-commerce en Suisse. Du point de vue du support, une seule chose compte : si le statut parvient au client avant qu'il ne pose la question, il n'a aucune raison d'écrire — ce ticket n'a jamais besoin d'être « traité » par un bot ou un modèle de réponse.

En pratique, mieux vaut répartir cette communication sur des moments précis du cycle de commande, pas un simple « statut » générique : un message de confirmation de commande immédiatement après l'achat (avec un numéro de commande auquel le client peut se référer), une notification d'expédition avec un numéro de suivi (à partir de laquelle le client peut suivre son colis lui-même), et — moins souvent mise en place, mais tout aussi utile — une alerte proactive en cas d'incident (retard du transporteur, tentative de livraison infructueuse), envoyée avant que le client ne remarque lui-même que quelque chose ne va pas. Ce troisième moment compte particulièrement, car selon Freshworks, les demandes WISMO surviennent « especially if an order is taking longer than expected » (surtout quand une commande prend plus de temps que prévu) — un client informé d'un retard par la boutique n'a pas à le découvrir lui-même en voyant un numéro de suivi qui n'évolue plus.

Réclamations — aucun délai légal, mais un processus reste nécessaire

Les réclamations constituent une catégorie de ticket différente de WISMO, et le droit suisse ne fixe aucun délai légal pour la rapidité avec laquelle un vendeur doit répondre à une réclamation — le Code des obligations (CO) ne prévoit pas de délai de réponse fixe pour les réclamations, contrairement à ce que prévoient certains autres pays. C'est un point distinct du fait que la Suisse n'a pas de droit de rétractation légal pour les achats en ligne : les retours en Suisse reposent sur la politique volontaire propre à chaque boutique et sur les règles de garantie du Code des obligations, pas sur un droit d'annulation — sujet traité en détail dans notre article sur les retours en Suisse. Les deux points ne doivent pas être confondus : l'un porte sur l'existence d'un délai pour répondre à une réclamation, l'autre sur la possibilité, ou non, pour le client de se rétracter de l'achat.

Ce qui vaut quel que soit le cadre juridique : accuser réception de la réclamation immédiatement, même si vous ne pouvez pas la résoudre sur-le-champ ; l'examiner et y répondre dans un délai que vous vous fixez vous-même et que vous respectez réellement, plutôt qu'un délai ouvert ; et transmettre la réponse elle-même par écrit, sous une forme que le client peut conserver — e-mail ou message dans l'espace client, pas une réponse verbale par téléphone qui ne laisse aucune trace. Une réclamation qui s'étire sans aucun délai, ni interne ni externe, est celle qui abîme le plus la confiance.

Du point de vue de l'organisation du support, cela a tout de même une conséquence pratique, même sans délai légal : une réclamation a besoin de son propre compteur de temps interne, visible, distinct de la file WISMO. Si les réclamations atterrissent dans la même boîte générale que les questions « où est ma commande », il est facile de perdre de vue que l'une a besoin d'une réponse documentée et datée et l'autre non — marquez les réclamations comme une catégorie de ticket distincte dès leur arrivée, avec la date de réception enregistrée sans ambiguïté (pas la date à laquelle quelqu'un a lu le message par hasard), puisque c'est à partir de cette date que se compte tout délai interne.

Chatbots — où ils aident, et les limites de ce que montrent les données

Avant de déployer un chatbot, mieux vaut distinguer honnêtement ce que l'on sait de ce que l'on suppose. Les recherches menées pour cet article n'ont mis au jour aucune enquête suisse indiquant combien d'acheteurs en ligne ont déjà échangé avec le chatbot d'une boutique, ni comment ils ont jugé l'expérience : les chiffres de marché de Handelsverband.swiss portent sur le chiffre d'affaires du commerce en ligne, pas sur l'usage des chatbots. Plutôt que d'emprunter les chiffres d'un autre marché, cette section décrit donc le mécanisme.

Ce mécanisme découle directement de la définition de WISMO ci-dessus : un chatbot a les meilleures chances de réussir là où la question a une seule réponse correcte et répétitive, indépendante du client concerné — statut de livraison, horaires d'ouverture, conditions de base d'une politique de retour. Il a les pires chances là où le client a besoin de jugement, d'empathie ou d'une personne capable de s'écarter d'un script — un litige de paiement, une réclamation inhabituelle, tout ce qui appelle une décision plutôt qu'une simple consultation. Déployer un chatbot n'est pas, en soi, la preuve qu'il fonctionne bien : la seule façon honnête de le savoir est de le mesurer par rapport à votre propre file de tickets, ventilée par catégorie, plutôt que de supposer que la technologie est uniformément bonne ou uniformément mauvaise.

Indiquer qu'il s'agit d'une IA

La Suisse n'a pas de loi spécifique à l'IA qui imposerait expressément à un chatbot de se signaler, et l'AI Act européen (règlement (UE) 2024/1689) n'est pas du droit suisse. Deux éléments vont pourtant dans le même sens. D'une part, le Préposé fédéral à la protection des données et à la transparence (PFPDT) estime que la loi sur la protection des données (nLPD) s'applique déjà à l'IA et que, face à un modèle de langage qui communique directement avec lui, l'utilisateur « a le droit de savoir s'il parle ou écrit à une machine » (prise de position du 9 novembre 2023 — une lecture de la nLPD par l'autorité, pas un arrêt de tribunal). D'autre part, l'AI Act ne s'arrête pas aux frontières de l'UE : selon son article 2, paragraphe 1, point c), il vise aussi les fournisseurs et déployeurs établis dans un pays tiers lorsque les sorties produites par le système d'IA sont utilisées dans l'Union. Si votre chatbot répond à des clients dans l'UE, l'obligation de transparence de l'article 50, paragraphe 1 — applicable dès le 2 août 2026 et adressée au fournisseur du système d'IA — peut donc vous concerner, vous ou l'éditeur de votre bot.

En pratique, la réponse est la même dans les deux cas : signalez clairement le chatbot, par exemple avec une mention « assistant IA » près de la fenêtre de chat. Un test pratique avant de déployer un chatbot : quelqu'un qui lui écrit pour la première fois, sans avoir lu vos conditions générales, saurait-il immédiatement qu'il ne parle pas à une personne ? Si la réponse n'est pas un « oui » sans ambiguïté — le bot a un prénom humain, répond à la première personne sans aucune mention, ou l'interface de chat ressemble exactement à une conversation avec un agent réel — ajoutez une mention explicite plutôt que de vous fier au fait que ce serait « évident ».

Centre d'aide et canaux

Que vous déployiez un chatbot ou non, il est utile d'avoir un seul endroit où votre équipe voit chaque ticket, quel que soit le canal par lequel il est arrivé — e-mail, Messenger, formulaire web, message via une marketplace. Le mécanisme est facile à décrire et plus difficile à mettre en œuvre : si le support doit basculer entre plusieurs boîtes et interfaces indépendantes juste pour voir l'historique complet du contact avec un client, le délai de réponse augmente, quel que soit le nombre de personnes embauchées. Une vue unique des tickets, avec le statut de la commande visible à côté de chaque conversation, supprime l'étape « je vais vérifier dans l'autre système » de chaque interaction — c'est une différence opérationnelle, pas un artifice technologique.

Les canaux diffèrent aussi par la rapidité de réponse attendue — le chat en direct suppose par nature une conversation en temps réel, l'e-mail non — et vendre sur Galaxus ou Ricardo peut imposer les règles propres à la marketplace concernant la rapidité de réponse aux messages des acheteurs, indépendamment de ce que vous avez mis en place en interne ; vérifiez les conditions de la marketplace concernée. Si vous gérez tous les canaux depuis un seul endroit, fixez un délai de réponse cible par canal — sinon, il est facile de tout traiter selon la norme la plus lente, ce qui nuit à l'expérience sur les canaux où les clients attendent une réponse plus rapide.

Mesurer le service client e-commerce — deux indicateurs qui comptent

Deux indicateurs suffisent pour savoir si le support d'une petite boutique fonctionne, sans tableau de bord d'entreprise à vingt indicateurs :

• Délai de réponse — le temps écoulé entre l'arrivée d'un ticket et la première réponse réelle et substantielle (pas un accusé de réception automatique du type « nous avons bien reçu votre message »). Mesuré par canal, car les attentes diffèrent entre l'e-mail et le chat en direct.
• Résolution au premier contact (first contact resolution, FCR) — la part de tickets clos sans nécessiter un nouvel échange de messages. Un FCR faible spécifiquement sur les tickets WISMO peut signifier que l'information de statut donnée au client est incomplète ou peu claire — pas que le support répond mal.

Aucun des deux indicateurs ne peut être comparé de façon pertinente à un quelconque « bon score » universel sans connaître le secteur et le volume concernés — mesurez les vôtres dans le temps, plutôt que par rapport à un référentiel d'un tiers dont vous ne connaissez pas la méthodologie.

Une façon pratique d'utiliser les deux chiffres ensemble : si le délai de réponse est court mais le FCR faible, l'équipe répond vite mais de façon incomplète — le client doit encore envoyer un message pour clore réellement le sujet. Si c'est l'inverse — FCR élevé, mais délai de réponse long — les réponses sont complètes, mais le client attend trop longtemps. Le premier schéma peut révéler des lacunes dans l'information dont dispose le support (pas de vue unique du statut de commande, par exemple) ; le second pointe vers un manque d'effectifs ou un processus interne trop lent. Suivre les deux indicateurs ensemble, pas seulement l'un des deux, montre lequel de ces deux problèmes concerne réellement votre boutique.