Під час дослідження за 30 травня найсильнішим сигналом став новий seller-fulfilled handling time announcement в Amazon Seller Forums: з 29 червня 2026 року час обробки SKU має відповідати фактичній швидкості підготовки замовлень. Amazon вказує на Automated Handling Time або на точні SKU-specific handling times, які будуть звірятися з недавньою історією відправлень.
Для українських продавців і команд, які керують Amazon.com, Amazon.co.uk або EU marketplace з України, Польщі, Чехії, Румунії чи США, це не дрібна зміна в Shipping Settings. Неправильний handling time може швидко перейти в Late Shipment Rate, OTDR, A-to-z, cancellation risk або inactive offer, якщо front-end promise не збігається з реальною роботою складу, 3PL, виробництва чи перевізника.
Збережіть стан до зміни AHT або template
Перед тим як увімкнути AHT, змінити SKU override або shipping template, збережіть поточні settings, ship-by dates, label records, перший carrier scan і notice від Amazon.
Спочатку знайдіть SKU, які справді залежать від ручного часу
Найгірше рішення - змінити всі FBM SKU одним масовим правилом. Товар на складі, made-to-order, handmade, кастомізація, важкий товар, SKU у 3PL і товар, який чекає партію від постачальника, мають різну операційну логіку.
- Вивантажте active seller-fulfilled SKU з поточним handling time, account default, SKU override, shipping template, inventory quantity і fulfillment channel.
- Окремо позначте custom, handmade, made-to-order, heavy/bulky, сезонні SKU і товари, залежні від постачальника або 3PL.
- Порівняйте 30-60 днів order history: order date, ship-by date, label purchase, shipment confirmation, first carrier scan і LSR defects.
- Розділіть Amazon.com, Amazon.co.uk, Amazon.de та інші marketplaces, щоб не пояснювати всі ринки одним US-only повідомленням.
- Поставте на паузу або зменште exposure SKU, які не можуть стабільно виконувати promise без ручного втручання.
AHT треба перевірити на винятках
Automated Handling Time може працювати для стабільного stock item. Але українські та діаспорні команди часто мають різні часові пояси, вечірній cut-off, локальні свята, customs handoff, ручне пакування, 3PL з іншим SLA або виробництво на замовлення. Минулі швидкі orders не завжди доводять майбутню capacity.
- Перевірте, чи AHT уже активний і для яких SKU Amazon має достатню стабільну історію.
- Якщо лишаєте manual handling time, запишіть чому він точний, а не просто зручний buffer.
- Документуйте weekend rules, holidays, carrier pickup days, warehouse cut-off, production steps і supplier dependency.
- Для custom або handmade SKU збережіть work order, внутрішній SLA або доказ production capacity.
- Не затримуйте відправлення штучно, щоб навчити метрику; краще узгодьте promise, inventory і реальну capacity.
LSR, OTDR і A-to-z не можна змішувати
Handling time стоїть поруч із кількома performance metrics, але кожна дивиться на інший факт. Late Shipment Rate питає, чи shipment confirmation була після expected ship date. OTDR питає, чи order доставлений до promised deliver-by date. A-to-z може залежати від Buy Shipping, proof of delivery, refund і buyer message chronology.
- Для LSR: order date, ship-by date, confirmation time, first carrier scan, причина затримки і corrective control.
- Для OTDR: promised deliver-by date, фактична delivery date, shipping template, SSA, AHT і Buy Shipping record.
- Для A-to-z: claim reason, proof of delivery, buyer messages, refund action і protected label signal, якщо він є.
- Якщо Amazon позначає offer, збережіть Account Health entry і Performance Notification до будь-якої зміни SKU.
- Якщо carrier scan запізнився, спочатку визначте, Amazon вимірює shipment confirmation чи delivery.
До кінця червня зберіть контрольний файл
Найцінніша підготовка до 29 червня - короткий SKU control file. Він має показати promise, реальну capacity, докази і owner для кожного ризикового SKU, а не просто загальний текст про хорошу логістику.
- Один рядок на SKU: current handling time, planned handling time, AHT decision, capacity reason, date changed і responsible owner.
- Додайте screenshots Handling Time, Shipping Settings, template, SKU offer, Account Health і приклади orders.
- Перевірте окремо normal week, promo week і week with holiday або carrier pickup gap.
- Визначте trigger pause: low stock, supplier delay, 3PL missed cut-off, carrier outage або повторні buyer complaints.
- У липні звіряйте файл щотижня, поки невеликі defects не стали performance notice.
Коли це вже recovery case
Зміна handling time сама по собі операційна. Вона стає recovery case, коли Amazon надсилає Account Health signal, seller-fulfilled offers під ризиком, LSR або OTDR ростуть, або команда не може довести, що buyer promise був реалістичним на момент замовлення.
Фінальний тест простий: reviewer має побачити, який promise мав SKU, які orders доводять реальну обробку, яке setting тепер відповідає capacity і який контроль не дасть проблемі повторитись. Якщо цього немає, поверніться до Late Shipment і Performance route до наступного шаблонного appeal.