Le débit à l’expédition …. voilà un sujet qui divise le monde de l’e-commerce !
Pour caricaturer , les e-commerçants sont contre, les consommateurs sont pour .
C’est donc un bon sujet à aborder dans ce blog !
Pour cela, je vous propose de le faire en 2 temps : prenons dans un premier temps le point de vue du client . J’aborderai, dans un second billet, le point de vue du e-marchand.
Pour ceux qui prennent le débat en cours de de route, tout a (réellement) commencé avec la faillite d’une entreprise célèbre de la VPC : CAMIF. En continuant à prendre des commandes alors que sa mort était annoncée, la société a débité les comptes bancaires de clients tout en sachant qu’elle ne pourrait probablement jamais les livrer.
Cet exemple, pas très glorieux, a mis en évidence une problématique qui est liée à la mécanique du e-commerce tel qu’on le pratique le plus souvent et tel que le client, jusqu’à présent, l’acceptait:
l’internaute passe commande, il paie (son compte en banque est débité) et il reçoit sous quelques jours (temps de préparation + temps de transport) sa commande.
Dans la plupart des cas, ça se passe réellement comme ça … mais il y a des exceptions .
Le « débit à l’expédtion » a vocation à protéger l’acheteur de ces exceptions.
D’ailleurs, mettons nous un peu à la place du client . Quand ça se passe mal, que pensez-vous que votre client imagine ?
Une amie m’expliquait hier qu’elle attendait sa commande, passée sur un acteur majeur de la vente en ligne, depuis 2 mois. Pour reprendre son expression, « j’ai un peu l’impression de faire travailler la trésorerie de » **beeep** ….
Aucun intérêt de citer le marchand en question : j’ai fait ce métier, je sais que les commandes en souffrance, ça arrive … malheureusement. Les raisons à ces défaillances sont multiples, surtout quand on gère des centaines de commandes par jour comme c’est le cas du e-marchand qui est ici incriminé.
Avec cet exemple, on peut cependant penser que mon amie serait sans doute moins « fâchée » si son argent n’avait pas été débitée lors du passage de commande . Elle ne serait aujourd’hui sans doute pas « heureuse » de la situation mais un peu plus compréhensive et surtout moins suspicieuse …
Certes mais si on pousse un peu plus loin la réflexion, on se dit qu’entre le moment où le colis quitte l’entrepôt et le moment où le colis arrive chez le client … il peut encore se passer pas mal de choses. Le colis peut être, par exemple, perdu par le transporteur qui gère lui aussi des milliers de commandes ….
Ce n’est donc pas « un débit à l’expédition » mais un « débit à la livraison » qu’il faudrait mettre en place, non ?
Des sociétés se sont déjà positionnées sur le créneau . Elles permettent de gérer le risque financier pour le commerçant. Je n’en ferai pas ici la publicité car je ne suis pas un grand fan de leur modèle.
Quoiqu’il en soit, il paraît raisonnable de penser que ce service, bien mis en valeur dans les éléments de réassurance du site, est un facteur qui contribue à déclencher l’achat.
Pour en revenir au « débit à l’expédition », je considère pour ma part que c’est un bon compromis entre le risque financier pris par le e-marchand et celui pris par le client (celui de voir son colis disparaître dans la nature lors du transport). Le débit à la livraison fait lui basculer tous les risques du côté du marchand.
Je considère également que, en plus d’être un vrai service client, c’est aujourd’hui un excellent élément de différenciation pour les sites e-commerce.
Pour les activités qui démarrent, ce serait dommage de ne pas le mettre en place dès le début de son activité. Bref, je le recommande souvent à mes clients.
Cependant, ils ont des éléments très factuels à m’opposer.
Je vous propose de vous les présenter dans un prochain billet ….
Le gros problème est au niveau des TPE virtuels.
Il faut déjà être un très gros compte afin d’AVOIR LE DROIT de payer le prix exorbitant de la licence de l’API pour interfacer son ERP avec le système de prélèvement de notre TPE. Aussi faut-il avoir un ERP ou un autre système qui permet de tracker les colis.
Sinon, il faut le faire manuellement, ce que je fait le plus souvent possible, mais je ne cacherais à personne que je ne prend pas le temps de le faire et que donc, mes clients sont débités à J+6 alors que leurs commandes sont expédiées à jour J et livré à J+2.
Donc malgré moi (et surement comme bcp de petit e-commerçant), je fait du paiement à livraison+4.
Bonjour Alban,
dans ton cas, c’est toi qui prend effectivement tous les risques
Tu n’as jamais eu d’impayés ?
Bonsoir,
Le paiement est présenté comme un rempart à des commerçants ayant failli ce qui n’est à mon avis pas une solution idéale. En effet, ce paramètre de débit est piloté uniquement par le commerçant qui pourrait en jouer pour affiner sa géstion de trésorerie pour les moments difficiles, sachant que les clients sont pour la plupart débités en fin de mois et ne font pas forcemment une comptabilité très fine au jour le jour. Sauf peut-être à voir murir les solutions avec un tiers de confiance.
A titre personnel, il m’importe lorsque j’effectue un achat, de savoir dans le détail quand et comment cela va se passer, payer à J, j+3 ou j+7 ne m’importe peu car ne faisant pas de gestion de trésorerie. Au pire, je décale mon achat.
Je serais en revanche intéressé par être sûr d’être livré, toujours en attente de ma tablette graphique achetée l’année dernière chez *beep* (un autre probablement) qui est injoignable, buté et surtout capable de perdre un client. Ce que fera moins facilement un petit e-commerçant pour qui les impacts seraient plus lourds.
J’attends avec impatience la seconde partie de votre billet, nous reflechissons tous les jours (ou presque) à comment faire et surtout être persuadé de l’intérêt et des impacts.
A vous lire, Alex.