7 травня 2026 року українські медіа повідомили, що Nova Post зазнала масштабної DDoS-атаки, через яку могли виникати тимчасові складнощі в роботі мобільного застосунку, особистого кабінету та частини сервісів. Компанія заявляла, що відділення й поштомати продовжують працювати, але отримання та відправлення посилок може займати більше часу.
Для українського Amazon-продавця це не лише локальна новина про перевізника. Якщо команда використовує Nova Post, Nova Global, партнерські маршрути або ручне оновлення tracking для FBM-замовлень, навіть короткий збій може виглядати в Seller Central як late ship confirmation, missing carrier scan, Valid Tracking Rate warning, A-to-z claim або негативний buyer feedback.
Збій перевізника не є готовою апеляцією
Amazon зазвичай оцінює конкретне замовлення: коли посилку передали перевізнику, коли підтвердили відправлення, який tracking був у Seller Central і що бачив покупець.
Коротка відповідь: відокремте затримку даних від затримки відправлення
Після carrier disruption продавцю треба швидко визначити, що саме сталося. Одна ситуація - посилка фізично передана вчасно, але scan або кабінет перевізника оновився пізніше. Інша - команда не змогла створити label, підтвердити shipment або передати товар до cut-off time. Для Amazon це різні факти, і їх не можна змішувати в одному поясненні.
- Позначте всі order IDs за день інциденту: marketplace, SKU, promised ship date, carrier, tracking number і фактичний час передачі посилки.
- Окремо виділіть замовлення, де shipment був підтверджений у Seller Central після expected ship date.
- Перевірте, чи був перший carrier scan, delivery scan або attempted delivery scan доступний у звіті Amazon, а не тільки на сайті перевізника.
- Не змінюйте заднім числом carrier name або tracking number без запису, хто і чому це зробив.
- Якщо затримка зачепила тільки особистий кабінет перевізника, збережіть скриншоти повідомлення про збій і статусів конкретних посилок.
FBM: що зберегти для VTR і Late Shipment Rate
Amazon пов'язує seller-fulfilled performance не з вашою внутрішньою хронологією, а з тим, що видно по замовленню. Late Shipment Rate рахує замовлення, підтверджені після expected ship date, а Valid Tracking Rate залежить від коректного tracking і carrier scan. Якщо поріг починає просідати, відповідь має бути order-level, а не загальна.
- Завантажте relevant order report і VTR/LSR report до того, як команда почне масові виправлення.
- Для кожного постраждалого order ID збережіть proof of handoff: квитанцію, manifest, scan sheet, фото відправлення або службовий запис складу.
- Зіставте час підтвердження shipment у Seller Central з часом фактичної передачі перевізнику.
- Якщо tracking number був валідний, але Amazon не бачив scan, зафіксуйте carrier tracking page і дату появи першого scan.
- Якщо частину замовлень неможливо було відправити вчасно, не називайте їх scan delay: це вже питання handling time, cut-off, capacity або contingency plan.
A-to-z, ODR і покупець: дійте до claim
Найгірший сценарій - чекати, доки покупець відкриє A-to-z Guarantee claim, а потім пояснювати Amazon, що перевізник мав DDoS. Order Defect Rate може постраждати через claim або негативний feedback, тому практичні дії мають початися до ескалації: чітка дата доставки, чесне повідомлення покупцю й доказ, що продавець контролював виняток.
- Перевірте замовлення з високою ціною, подарунковим характером, коротким delivery promise або попередніми повідомленнями покупця.
- Якщо parcel рухається, але scan запізнюється, дайте покупцю коротке order-specific оновлення без згадок, які звучать як виправдання.
- Якщо доставка реально зірвана, оберіть refund, replacement або інший customer-service маршрут до того, як покупець відкриє claim.
- Не просіть покупця закрити claim або змінити feedback у спосіб, який порушує правила Amazon.
- Після вирішення збережіть buyer message timeline, refund/replacement record і carrier proof в одному пакеті по order ID.
Як закрити день інциденту в операційній хронології
Один день збою корисно закривати як міні-інцидент, навіть якщо Seller Central ще не показує warning. Це дисциплінує команду і створює матеріал для майбутньої відповіді: не "у Nova Post був DDoS", а "ось які замовлення були зачеплені, які не були зачеплені, які дії ми виконали і як запобігли повторенню".
- Складіть timeline: перший сигнал про збій, affected tools, перехід на резервний процес, час відновлення і список post-checks.
- Оновіть SOP для днів, коли carrier cabinet, app або API нестабільні: хто створює labels, хто підтверджує shipment, хто перевіряє scans.
- Перегляньте handling time для SKU, які залежать від ручного пакування, митного оформлення або вечірнього cut-off.
- Відокремте FBM customer orders від FBA inbound: для FBA важливі shipment IDs, box content, labels і proof of delivery, а не LSR.
- Не подавайте performance appeal, доки не ясно, чи проблема в Late Shipment Rate, VTR, ODR, cancellation або customer messaging.
Практичний висновок: DDoS-атака на перевізника може пояснити контекст, але не замінює доказів по замовленню. Якщо після 7 травня у Seller Central з'явився warning, почніть з маршруту performance issues: окремо перевірте Late Shipment Rate, Valid Tracking Rate, Order Defect Rate і A-to-z chronology. Так ви не перетворите локальний збій логістики на слабку або надто загальну апеляцію в Account Health.