Маркетплейс лёг, а штрафы остались: регламент на случай сбоя площадки

В публичных новостях о сбоях маркетплейсов есть странная деталь: площадка пишет «технические работы» или «временно приостановили приём», а у селлера всё равно идёт таймер. Отгрузка просрочена, ярлык не сформирован, заказ не принят в статусе, и в конце месяца в отчёте видна строка с удержанием.

После атак на дата-центры Яндекса и перебоев в работе Яндекс Маркета, Ozon и узбекского Uzum стало понятно, что инфраструктура площадок тоже бывает недоступна. Яндекс Маркет временно приостанавливал отгрузки в ПВЗ, об этом писал vc.ru. Но когда это происходит, разбираться с последствиями приходится не площадке, а менеджеру по маркетплейсам, который накануне просто выполнял инструкцию.

Ниже я разбираю, что в этот момент ломается у селлера, почему виноватым оказывается человек, а не процесс, и какой каркас регламента можно внедрить за неделю. В конце есть таблицы, шаблон обращения и чек-лист.

Привычная логика, которая подводит

Первая реакция большинства команд такая: «Это форс-мажор, площадка сама всё снимет». Иногда так и бывает. При массовых сбоях платформы нередко отключают штрафы или пересчитывают метрики. Но на этом ожидании строится слабая позиция, и вот почему:

Автоматика не знает про сбой. Штрафы и метрики считаются по меткам времени в системе. Если заказ в статусе «не принят» после дедлайна, система не различает, не довёз ли селлер или не принял ПВЗ.
Исключения делаются выборочно. Площадка может освободить от штрафов за один тип нарушений и оставить другой. Часть метрик, например индекс качества, пересчитывается позже и вручную не всегда правится.
У оспаривания есть окно. Условия оферты у каждой площадки свои, но срок на претензию почти всегда ограничен. Если спохватиться через месяц, доказательств уже не собрать: скриншотов нет, логи ротировались, а человек, который был на смене, не помнит деталей.
Доказывать приходится вам. Это базовое правило любого спора. «У всех лежало» не аргумент. Нужны время, идентификаторы, ответы системы.

Мой вывод такой: сбой площадки нельзя считать только внешним событием. Это ситуация, в которой у вас должна быть собственная процедура. Без неё один и тот же инцидент превращается либо в потерянные деньги, либо в панику.

Что именно ломается у селлера

Я разделяю последствия на четыре зоны. У каждой свой механизм потерь.

1. Ярлыки и документы

Ярлык формируется через ЛК или API. Если сервис недоступен, команда или идёт на ручные обходы (печать со старых шаблонов, ручная маркировка), или ничего не отгружает. Ручные обходы опаснее: ПВЗ или СЦ не отсканирует такую маркировку, и заказ повиснет без статуса. Потери здесь двойные: заказ не едет и вы платите за срыв срока.

2. Приёмка в ПВЗ и сортировочных центрах

Здесь возможны два разных сценария, и их часто путают:

Приёмка остановлена официально. Это видно по новостям, уведомлению в ЛК или сообщению менеджера. Доказательная база сильная, нужно только всё зафиксировать.
Приёмка идёт, но статусы не обновляются. Физически товар сдан, в системе его нет. Это самый неприятный случай: машина с товаром стоит, а в отчёте вы просрочили. Тут решает только ваш собственный след: фото, накладная, отметка водителя.

3. Индекс качества и рейтинг

Заказы, которые выпали из окна доставки или были отменены из-за сбоя, попадают в показатели: доля отмен, просрочек, возвратов. Показатели влияют на позиции в выдаче и на доступные условия. Пересчёт происходит с задержкой, и о проблеме вы узнаёте уже по падению продаж. Это скрытая потеря, которая обычно в разборе инцидентов не учитывается.

4. SLA-штрафы и удержания

Штрафы начисляются за просрочку отгрузки, нарушение окон поставки, недопоставку и прочее. Конкретные суммы и условия определяет оферта вашей площадки, поэтому первый шаг регламента здесь простой: выписать, за что именно вы можете получить удержание и в какой срок это можно оспорить. Многие команды впервые делают это уже после инцидента.

Почему «крайним» становится менеджер

Типичная картина такая: сбой случился в субботу вечером, дежурит один человек, роли «кто принимает решение» нет. Он:

не знает, можно ли переносить отгрузку без согласования;
не знает, кому звонить, если склад уже отправил машину;
не понимает, что нужно сохранить как доказательство;
боится сделать лишнее и потому ждёт.

В понедельник приходит отчёт со штрафами. Руководитель смотрит на цифру и спрашивает менеджера: «Почему не отреагировал?» Менеджер отвечает: «Мне никто не говорил, что делать». Оба правы. Проблема в процессе, а не в человеке: ответственность размазана, и решение принимается по умолчанию, то есть никак.

Когда я пересобираю такие процессы, начинаю с трёх вопросов, и в них нет ничего про мотивацию или обучение:

Кто имеет право принять решение в этот момент (в том числе ночью и в выходные)?
Какой срок на это решение, если смотреть от дедлайна отгрузки, а не от начала сбоя?
Какие данные нужно сохранить, чтобы через две недели выиграть спор?

Каркас ниже построен на ответах на эти вопросы.

Каркас регламента: матрица сценариев

Базовый документ состоит из одной таблицы. Ниже пример для типового селлера. Сроки и роли подстройте под себя.

Принципы заполнения:

Идентификаторы в приоритете. Номера отправлений, поставок, тикетов. Без них обращение превращается в жалобу.
Время только с таймзоной. Одной площадке удобнее МСК, вашему складу местное время. Фиксируйте оба.
Одно действие, один владелец. Если в ячейке стоят два имени, значит, владельца нет.

Пороги эскалации: считайте от дедлайна

Главная ошибка в эскалации: привязывать её к длительности сбоя. «Если лежит больше двух часов, звоним директору». Но два часа в понедельник утром и два часа за двадцать минут до закрытия слота отгрузки это разные ситуации.

Я предлагаю привязывать пороги к ближайшему критичному дедлайну: времени закрытия приёмки, cut-off отгрузки, окну поставки. Стартовые значения такие (подстройте под свою оборачиваемость):

Уровень 0, дежурный менеджер. Сбой замечен, до дедлайна больше 4 часов. Действия: проверить публичные источники и статус-страницу площадки, зафиксировать, начать журнал инцидента.
Уровень 1, руководитель e-com. До дедлайна меньше 4 часов, или под риском больше заданной доли дневных отгрузок. Решение: переносить ли отгрузку, использовать ли обходной канал, предупреждать ли склад.
Уровень 2, директор и финансы. До дедлайна меньше 1 часа, либо потенциальный штраф или потеря выручки выше согласованного порога, либо сбой затрагивает несколько площадок сразу. Решение: компенсаторные меры, коммуникация с партнёрами, обращение к менеджеру площадки.

Пороги по деньгам и доле заказов нужно задать заранее и записать цифрами. «Серьёзный риск» это не порог. Лучше ошибиться в границах, чем оставить их на усмотрение дежурного.

Доказательная база: что собираем и как

Чтобы выиграть спор, нужно показать три вещи: что сбой был, что он повлиял именно на ваши отправления, что вы действовали добросовестно.

Минимальный набор для папки инцидента:

Внешние подтверждения сбоя. Уведомления площадки, публикации в СМИ, сообщения менеджера. Сохраняйте ссылку и скриншот с датой.
Технический след. Скриншоты ошибок, ответы API с кодами и временем, лог мониторинга.
Физический след. Фото и видео в ПВЗ или СЦ, накладные, отметки водителя, акт приёмки, если он есть.
Журнал решений. Кто, во сколько и что решил. Достаточно записи в общем чате с тегом #инцидент, но с автором и временем.
Список затронутых отправлений. Таблица: ID отправления, ожидаемая и фактическая дата, статус, штраф (если уже начислен).

На автоматизации я бы остановилась отдельно. Скриншоты руками делаются плохо, потому что в момент сбоя нет на это времени. Достаточно простого скрипта или интеграции, которые:

каждые 5–10 минут пингуют ключевые методы API и пишут результат в журнал;
при серии ошибок отправляют алерт в рабочий мессенджер дежурному;
раз в час сохраняют срез статусов открытых отправлений.

Это дешёвая вещь по сравнению со штрафом. И главное: у вас появляются собственные данные, а не только «мы видели, что не работало».

Шаблон обращения в поддержку

Обращение должно быть коротким, структурированным и проверяемым. Вот каркас, который можно подставить в форму или письмо:

> Тема: Просим отменить штраф / скорректировать метрику в связи со сбоем на стороне площадки. Период: [дата, время — дата, время, МСК]

> Кто: [юрлицо, ID кабинета]

> Что произошло: В период [время] наблюдалась недоступность [формирования ярлыков / приёма в ПВЗ / API / ЛК]. Информация о сбое подтверждается [ссылка на уведомление или публикацию].

> Как это повлияло на нас: Отправления из приложенного реестра не могли быть сформированы / приняты в срок по причинам, не зависящим от продавца.

> Что мы сделали: [коротко: фиксировали ошибки, предупредили склад, пытались сдать повторно, обращались в поддержку — с номерами тикетов и временем].

> Что просим: Отменить удержания по списку [ID штрафов, суммы] и не учитывать указанные отправления в расчёте [названия метрик].

> Приложения: 1) реестр отправлений, 2) скриншоты и ответы API с временем, 3) фото и накладные, 4) ссылки на публичные сообщения о сбое.

> Просим ответить до: [дата].

Рабочие правила:

Одно обращение на один инцидент, а не на каждый штраф. Так площадке проще увидеть закономерность.
Тон нейтральный. Эмоции в спорах не помогают, а список ID помогает.
Если ответа нет в срок, повторяйте обращение в том же тикете и фиксируйте это. Это ваш след добросовестности.

Таблица ответственности

Эта таблица должна висеть там, где её видит дежурный в момент сбоя: в закреплённом сообщении рабочего чата, в корпоративной вики. В папке, о которой знают двое, она не сработает.

Как внедрить за неделю

Без больших проектов и консалтинга можно сделать так:

День 1. Выписать все типы штрафов и удержаний по вашей оферте, сроки на претензии, ключевые дедлайны отгрузки.
День 2. Заполнить матрицу сценариев (таблица выше) под ваши процессы.
День 3. Назначить владельцев и дежурства, согласовать пороги эскалации с руководством и финансами. Записать цифрами.
День 4. Создать шаблон папки инцидента и шаблон обращения. Настроить общий чат или канал с тегом.
День 5. Поставить базовый мониторинг API и алерты в мессенджер.
День 6–7. Провести учение на 60 минут: условный сбой, дежурный проходит по матрице, мы смотрим, где регламент ломается.

После первого реального инцидента добавьте в регламент то, что не предусмотрели. Он должен жить.

Чек-лист перед тем, как закрыть тему

[ ] Выписаны виды штрафов, срок оспаривания и контакты площадки
[ ] Есть матрица «сбой → владелец → срок → доказательства»
[ ] Пороги эскалации привязаны к дедлайнам и выражены в цифрах
[ ] У каждого действия один владелец
[ ] Определён дежурный на выходные и ночные смены
[ ] Есть шаблон обращения и папка доказательств
[ ] Настроен мониторинг API с алертами
[ ] Проведено хотя бы одно учение
[ ] Назначен человек, отслеживающий срок оспаривания штрафов

Вместо вывода

Сбои площадок невозможно предсказать, но потери от них можно ограничить. Главный риск не в самом сбое, а в том, что в этот момент в компании нет ни владельца решения, ни дедлайна, ни привычки собирать доказательства. Это вопрос процесса, а не усердия отдельного менеджера. Обучение команды может быть частью решения, но начинать стоит с матрицы, ролей и порогов: без них даже хорошо обученные люди будут импровизировать.

Если хотите, пришлите ваш случай: какие площадки, как устроена отгрузка, где уже были потери от сбоев. Я разберу, какие сценарии стоит закрыть в первую очередь и что в мониторинге можно автоматизировать. Пишите в комментариях или в личные сообщения.