+39 379 368 2435
8 Grand Canal Pl, The Liberties, Dublin, D08 HN88, Ireland
Performance livraison

Délai de traitement FBM après le 29 juin : contrôles SKU et AHT

Depuis le 29 juin, le délai de traitement des commandes expédiées par le vendeur doit rester prouvable au niveau SKU. Le sujet n’est pas seulement le réglage AHT : c’est la preuve de promesse, de capacité et de scan si Amazon relie ensuite le dossier à LSR, OTDR ou A-to-z.

30 juin 2026 • 7 min de lecture
Relecture éditoriale

Cette page publique est maintenue selon la méthode d’analyse des dossiers utilisée par Northline.

À propos de la méthode
Rédigé par
Michele Corvo
Publié
30 juin 2026

Dans la veille du 29 juin, le signal le plus utile pour les vendeurs FBM n’était plus le rappel de préparation. C’était le passage à l’exécution : Amazon indique que les SKU expédiés par le vendeur doivent avoir des délais de traitement cohérents avec le comportement réel, avec le Délai de traitement automatisé, ou AHT, comme route recommandée et les délais spécifiques SKU comme route à justifier.

Pour un vendeur basé en France qui vend sur une marketplace concernée, notamment avec des commandes internationales ou une équipe qui règle plusieurs comptes, la mauvaise réponse consiste à raccourcir ou rallonger les délais sans figer la preuve. Si une commande part ensuite en retard, si une livraison manque la promesse ou si une réclamation A-to-z apparaît, Amazon ne relira pas seulement le paramètre : il regardera la commande, le scan, la date promise et la cohérence opérationnelle.

Le réglage AHT ne remplace pas le dossier

Après le 29 juin, conservez l’état des SKU, des modèles d’expédition et des commandes avant toute modification, sinon il devient difficile de prouver pourquoi la promesse client était réaliste.

Figez l’état du 29 juin avant de modifier

Le premier travail n’est pas de choisir entre AHT et délai manuel. Il faut d’abord capturer ce qu’Amazon pouvait voir au moment où la nouvelle exigence devenait active. Une capture faite après plusieurs ajustements ne montrera plus pourquoi le SKU était exposé.

  • Exportez les SKU FBM actifs avec marketplace, quantité disponible, modèle d’expédition, délai de traitement par défaut, délai spécifique SKU et état AHT.
  • Gardez les captures de Shipping Settings, Handling Time, modèle d’expédition, fiche offre SKU, Buy Shipping et éventuelle notification Amazon.
  • Isolez les produits personnalisés, handmade, volumineux, saisonniers, dépendants d’un fournisseur ou expédiés seulement certains jours.
  • Comparez les 30 derniers jours de commandes : date de commande, ship-by date, achat du label, premier scan transporteur et confirmation d’expédition.
  • Séparez chaque marketplace au lieu de copier une correction Amazon.com, Amazon.fr ou Amazon.co.uk sans vérifier le périmètre exact.

Décidez si AHT décrit vraiment votre capacité

AHT peut réduire les erreurs de promesse lorsque l’historique récent reflète la capacité réelle. Il peut aussi devenir dangereux si l’historique a été accéléré par une semaine exceptionnelle, un stock déjà préparé, un renfort temporaire ou un transporteur qui ne collecte pas tous les jours.

  • Utilisez AHT si le SKU a un historique stable, des heures de collecte régulières et une équipe capable de tenir la promesse sans exception cachée.
  • Conservez un délai spécifique SKU si la fabrication, la personnalisation, le contrôle qualité ou l’approvisionnement impose une contrainte mesurable.
  • Vérifiez les jours non ouvrés, coupures transporteur, jours fériés locaux, pics Soldes/Prime Day et capacité d’emballage avant d’accepter un délai plus court.
  • Ne retardez pas volontairement les expéditions pour influencer la moyenne : corrigez plutôt la promesse ou la capacité.
  • Documentez la raison de chaque choix par famille de SKU, pas seulement avec une note générale dans un tableur.

Reliez délai de traitement, LSR et OTDR

Le délai de traitement se trouve au croisement de plusieurs métriques. Le taux d’expéditions en retard, ou LSR, regarde si l’expédition a été confirmée après la date attendue. Le taux de livraison dans les délais, ou OTDR, dépend de la promesse client et du résultat de livraison. Les deux dossiers partagent des preuves, mais ils ne se défendent pas avec le même angle.

  • Pour LSR, conservez date de commande, ship-by date, heure de confirmation, label, premier scan et raison de tout retard de confirmation.
  • Pour OTDR, conservez date promise, service choisi, tracking, scan de prise en charge, preuve de livraison et modèle d’expédition actif.
  • Pour une réclamation A-to-z, reliez promesse, messages client, preuve de livraison, remboursement éventuel et décision Amazon.
  • Pour une désactivation d’offre, sauvegardez l’entrée Santé du compte ou Performance Notification avant de modifier le SKU.
  • Pour une annulation, montrez si la cause vient du délai affiché, du stock, du transporteur, de la capacité ou d’une erreur de modèle.

Préparez une feuille de contrôle post-29 juin

Le bon dossier est court, mais il doit être par SKU. Il doit permettre à un reviewer de suivre la promesse affichée au client, l’action du vendeur, le scan transporteur et la correction appliquée sans deviner entre plusieurs paramètres Seller Central.

  • Colonnes catalogue : marketplace, ASIN, SKU, type de produit, stock, mode FBM, modèle d’expédition et délai affiché.
  • Colonnes décision : AHT activé ou non, délai spécifique SKU, raison opérationnelle, date de changement et responsable interne.
  • Colonnes preuve : exemples de commandes, ship-by date, label, premier scan, livraison et capture du paramètre au moment de la commande.
  • Colonnes risque : LSR, OTDR, annulation, A-to-z, feedback, offre inactive ou entrée Santé du compte.
  • Colonnes correction : SKU pausé, délai ajusté, capacité changée, transporteur remplacé, modèle corrigé ou message client amélioré.

Quand escalader

Un simple nettoyage des délais reste un sujet opérationnel. Il devient un dossier recovery si Amazon signale une métrique, menace une offre, rattache une commande à Santé du compte, refuse une contestation A-to-z ou si l’équipe ne peut pas prouver pourquoi la promesse affichée était réaliste au moment de la commande.

Le test final est concret : pouvez-vous montrer, pour chaque SKU touché, quel délai était affiché le 29 juin, pourquoi ce délai était tenable, quelle commande a raté la promesse et quelle route Amazon doit examiner ? Si cette ligne n’est pas claire, revenez au contexte taux d’expéditions en retard, performance ou A-to-z avant d’envoyer une réponse générale.

Route principale du dossier

La page qui porte vraiment le dossier reste la route Expéditions en retard.

Ouvrir Expéditions en retard
Pages de cas liées

Consultez ces pages seulement si les preuves orientent clairement le dossier vers une autre catégorie.

Nous utilisons des cookies pour les fonctions essentielles du site et, avec votre accord, pour l’analyse et la mesure publicitaire.