Під час перевірки джерел за 25 червня свіжий seller-сигнал був незвичним: продавці обговорювали email Amazon про technical issue, через який частина draft listings була submitted without your input і опублікована між 8 і 19 червня 2026 року. У повідомленні Amazon також вказував, що impacted listings не були автоматично зняті offline, а продавець має переглянути список SKUs і вирішити, що робити далі.
Для українських продавців, які ведуть Amazon.com, Amazon.ca, Amazon.co.uk або EU marketplace з України, Балтії, Чехії, Румунії чи діаспори, це не просто catalog glitch. Draft, який раптом став live, може створити неправильну ціну, marketplace exposure, FBM promise, FBA stranded inventory, compliance request або Account Health restriction. Тому відповідь має починатися з інвентаризації фактів, а не з масового delete.
Не видаляйте все без snapshot
Amazon може писати, що impacted listings будуть exempt від AHR impact, але продавець усе одно має довести, які SKUs були зачеплені, що саме стало live, який marketplace постраждав і які дії були зроблені після notice.
Збережіть email і impacted SKU list
Перший файл у цьому case - не appeal, а evidence folder. Якщо Amazon дав посилання на impacted SKUs, воно може мати строк дії. Після цього команда часто лишається лише з власними screenshots і export, а reviewer бачить розрізнені твердження про системну помилку.
- Збережіть повний email Amazon: subject, sender, дата, marketplace, wording про technical issue, період June 8-June 19 і будь-який deadline для download link.
- Завантажте impacted SKU file і покладіть поруч raw copy без редагування та робочу копію для notes.
- Для кожного SKU зафіксуйте ASIN, marketplace, status, quantity, fulfillment channel, price, shipping template, variation parent і дату останньої зміни.
- Зробіть screenshots Manage All Inventory, Complete your drafts, Account Health, Fix Your Products і affected detail page до будь-якого delete або edit.
- Якщо email не прийшов, але старі listings раптово ожили, зробіть окрему таблицю suspected SKUs і не змішуйте її з офіційним impacted list.
Відділіть harmless listing від реального ризику
Не кожен опублікований draft шкодить акаунту. Один SKU міг бути готовий до запуску, інший - мати неправильну категорію, застарілу ціну або product claim, який продавець ніколи не хотів публікувати. Amazon reviewer оцінюватиме не емоцію, а зв'язок між технічною помилкою і конкретним policy або performance наслідком.
- Позначте SKUs як keep, edit, close, delete або investigate, але спочатку поясніть причину рішення.
- Окремо перевірте listings, які стали live в marketplace, де акаунт був на vacation, де немає складу або де товар не мав локальної compliance readiness.
- Перевірте ціну, currency, business price, shipping cost, handling time, inventory quantity і whether offer could receive orders.
- Якщо SKU має FBA inventory, звірте stranded status, listing match, FNSKU, inbound shipments і removal pressure.
- Якщо товар регульований, перевірте category approval, dangerous goods, battery, kids, food contact, health claims, CE/UKCA або інші compliance fields.
AHR exemption не замінює коротке пояснення
У seller-сигналі Amazon прямо зазначав, що listings, impacted by the technical issue, мають бути exempt від impacts to Account Health Rating, а якщо продавця попросять appeal account restrictions, варто коротко описати, як technical issue вплинув на бізнес. Це важлива підказка: не треба писати довгий POA, якщо Amazon просить route-specific clarification.
- Якщо в Account Health немає violation, не створюйте зайвий appeal: закрийте або виправте listing і збережіть evidence folder.
- Якщо є Account Health record, зіставте його з impacted SKU list, датою публікації draft і точним policy label.
- У brief description вкажіть: Amazon technical issue, affected SKU/ASIN, чому listing не мав бути live, яку дію зроблено і який контроль додано.
- Не включайте в appeal SKUs, яких немає в impacted list, якщо не можете пояснити їх окремо.
- Якщо Amazon відхиляє AHR exemption, відкрийте route через case chronology, а не через загальне звинувачення Amazon у glitch.
Не змішуйте catalog, orders і funds
Найгірший сценарій - коли draft listing став live, отримав order, створив pricing loss або зачепив FBA inventory. Це вже не один catalog case. Потрібно розкласти наслідки за маршрутами, щоб не подавати фінансову скаргу як ASIN appeal або performance defect як доказ technical issue.
- Catalog route: неправильний title, category, variation, brand, product ID, image, attributes або inactive/suppressed listing.
- Compliance route: restricted product, safety document, dangerous goods, food/health claim, regional product approval або missing certification.
- Order route: FBM order accepted with wrong handling time, wrong ship-from, cancelled order, buyer message, A-to-z або negative feedback.
- Inventory route: stranded FBA units, wrong ASIN/SKU match, removal/disposal pressure або inbound shipment tied to the wrong offer.
- Funds route: refunds, fee lines, negative balance, Ads spend або reimbursement impact після unintended listing activity.
Коли це вже recovery case
Сам email про draft listings ще не означає, що потрібна повна Amazon appeal strategy. Recovery case починається тоді, коли listing залишається inactive або restricted, Amazon не застосовує AHR exemption, affected SKU отримав compliance request, marketplace exposure створив orders або inventory/funds consequences, які не закриваються звичайним edit/delete.
Практичний висновок: ведіть цей incident як ASIN evidence case з короткою AHR хронологією. Якщо проблема лишається в catalog status, починайте з ASIN/listing deactivation. Якщо з'явився policy або safety record, підключайте restricted products route. Якщо помилка вже створила orders, inventory або payout damage, тримайте performance і funds evidence окремо від першого пояснення по technical issue.