← блог Paramiko
AI automation / business / Paramiko

Как автоматизировать претензии к WB/Ozon по потерям, недостачам и начислениям

Типичная история. Поставку на склад приняли не полностью. Возврат так и не доехал до продавца. За логистику списали больше, чем следует из габаритов. Каждый такой случай стоит немного, поэтому в моменте им никто не занимается. Через квартал выясняется, что набежали десятки тысяч рублей, а сроки подачи по половине случаев уже прошли.

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

Типичная история. Поставку на склад приняли не полностью. Возврат так и не доехал до продавца. За логистику списали больше, чем следует из габаритов. Каждый такой случай стоит немного, поэтому в моменте им никто не занимается. Через квартал выясняется, что набежали десятки тысяч рублей, а сроки подачи по половине случаев уже прошли.

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

Коротко

  • Деньги теряются в пяти местах: недостачи при приёмке, потери на складе, недошедшие или подменённые возвраты, ошибки в логистике и хранении, спорные штрафы и удержания.
  • Автоматизация здесь — это не бот, который пишет в поддержку маркетплейса. Это ежедневная сверка ваших данных с отчётами WB/Ozon, карточка по каждому расхождению, контроль сроков и черновик обращения.
  • Решение о подаче, проверку доказательств и отправку оставляем человеку. Так меньше отказов и нет риска, что система от вашего имени отправит ошибочную претензию.
  • Экономия приходит с двух сторон. Найденных случаев становится больше, потому что сверяется всё, а не выборка. На каждый случай уходит меньше времени: 5–7 минут на проверку вместо 20–40 минут на ручной разбор.
  • Начинайте с одного типа расхождений, обычно с недостач при приёмке, и считайте три цифры: сколько найдено, сколько подано, сколько возмещено.

Где селлер теряет деньги и почему претензии не подаются

Пять типов расхождений

Недостача при приёмке. Вы отгрузили 120 единиц, по акту приёмки — 112. Иногда это ошибка сборки на вашей стороне, иногда пересорт или потеря у площадки. Без своих данных об отгрузке (упаковочный лист, фото коробов, данные ТСД) спорить не о чем.

Потеря или порча на складе. Остаток по SKU уменьшился, но продажи, возврата или списания по нему нет. Либо товар числится повреждённым, а компенсацию не начислили или начислили по заниженной цене.

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

Логистика и хранение. Тариф посчитан по неверным габаритам или с другим коэффициентом склада. Хранение начислено за товар, который уже продан или передан на возврат. В одной строке это 20–80 рублей, на тысячах строк в месяц получается заметная сумма.

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

Почему руками это не работает

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

Вторая проблема — сроки. У каждого типа претензии своё окно для подачи, и площадки периодически меняют правила. Если расхождение нашли через шесть недель, спорить часто уже поздно.

Третья — доказательства. Фото коробов лежат в чате склада, упаковочные листы в 1С или МойСкладе, переписка с поддержкой в личном кабинете. Сборка одного пакета документов съедает больше времени, чем написание самого обращения.

Что отдаём автоматизации, а что нет

Граница простая. Система находит, считает, собирает и напоминает. Человек решает и отправляет.

Автоматизируем:

  • выгрузку отчётов и данных через API WB и Ozon (поставки, приёмка, остатки, финансовая детализация, возвраты) и из вашей учётной системы;
  • сверку и поиск расхождений по правилам;
  • карточку случая с суммой, ссылками на данные и найденными доказательствами;
  • расчёт дедлайна подачи и приоритета;
  • черновик обращения по шаблону под тип случая;
  • напоминания в Telegram ответственному;
  • контроль статуса: что подано, что в работе, что отклонено, что пора подать повторно.

Не автоматизируем без человека:

  • решение, подавать ли претензию (иногда ошибка на вашей стороне, и подавать не надо);
  • отправку обращения от имени магазина;
  • ответы на запросы поддержки площадки и спорную переписку;
  • любые действия с остатками, ценами и поставками.

Если вы ещё не решили, нужен ли тут AI-агент или хватит скриптов и таблиц, сначала почитайте чем AI-агент полезен бизнесу и где он не нужен. В претензиях 70–80% работы — обычная сверка данных. LLM нужна в основном для черновика текста и разбора нестандартных случаев.

Как выглядит рабочий процесс

1. Сбор данных

Раз в сутки система забирает данные из кабинетов WB и Ozon через API и из вашей учётки: что отгружено, в каком составе, с какими фото и документами. Если фото коробов присылают в Telegram-чат склада, бот складывает их в хранилище с привязкой к номеру поставки. Это самый недооценённый шаг: без него через месяц доказательства придётся искать вручную.

Для доступа к API нужен токен только с правами на чтение: аналитика, статистика, финансы, поставки. Права на изменение цен, карточек и поставок для этой задачи не нужны.

2. Сверка и поиск расхождений

Под каждый тип расхождения пишется отдельное правило. Например:

  • отгружено по упаковочному листу больше, чем принято по акту, → кандидат «недостача при приёмке»;
  • возврат оформлен в отчёте, но через N дней не появился в остатках или в возвратах продавцу → кандидат «недошедший возврат»;
  • тариф логистики в детализации выше расчётного по габаритам из карточки больше чем на X% → кандидат «переплата за логистику».

Пороги задаём явно. Расхождение в одну единицу на поставке в 500 штук может не стоить вашего времени. Это бизнес-решение, а не техническое.

3. Карточка случая

Каждое расхождение превращается в запись в таблице или CRM. Пример:

Случай: WB-2026-0412
Тип: недостача при приёмке
Поставка: 28471953, склад Электросталь, приёмка 14.10.2026
SKU: 184520311 (органайзер, серый)
Отгружено: 120 шт. (упаковочный лист, короба 1–6)
Принято: 112 шт.
Расхождение: 8 шт. × 1 140 ₽ = 9 120 ₽
Доказательства: упаковочный лист ✓, фото коробов ✓ (6 из 6), видео сборки ✗
Подать до: 21.10.2026 (проверить по актуальным правилам)
Приоритет: высокий
Статус: ждёт проверки
Ответственный: Анна

Видно сразу, сколько стоит случай, чего не хватает и сколько осталось времени.

4. Сроки и приоритеты

Сроки подачи по каждому типу претензии храните в настройках: в таблице или конфиге, а не в коде. Площадки меняют правила, и обновить одну строку быстрее, чем переписывать логику. Приоритет зависит от суммы, остатка срока и полноты доказательств. Каждое утро ответственный получает в Telegram короткую сводку: «3 случая горят в ближайшие 48 часов, сумма 21 400 ₽».

5. Черновик обращения

Здесь LLM действительно полезна. Модель получает карточку случая и шаблон под этот тип претензии и пишет короткий текст по фактам: номер поставки, SKU, количество, сумма, список приложенных документов. Модели прямо запрещено придумывать факты и ссылаться на документы, которых нет в карточке.

Здравствуйте. По поставке № 28471953 (приёмка 14.10.2026) по артикулу
184520311 принято 112 шт. при отгруженных 120 шт. Расхождение — 8 шт.
Прикладываем упаковочный лист и фото шести коробов с маркировкой.
Просим провести проверку и компенсировать недостачу.

Хорошее обращение короткое и проверяемое. Длинные и эмоциональные тексты обычно рассматривают не быстрее.

6. Проверка и отправка человеком

Менеджер открывает карточку, сверяет цифры с кабинетом, смотрит доказательства, правит текст и отправляет обращение через личный кабинет. После этого вносит в карточку номер обращения. На проверку одного случая с готовым пакетом уходит 5–7 минут.

7. Контроль статуса

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

8. Учёт результата

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

Сколько это экономит

Цифры зависят от оборота, количества SKU и дисциплины склада, поэтому ниже условный пример, а не обещание.

Селлер: 300 SKU, 10–12 поставок в месяц на WB и Ozon. Раньше менеджер тратил на претензии 8–10 часов в месяц, проверял выборочно и подавал 5–7 обращений.

После внедрения сверка идёт по всем поставкам и возвратам. Система находит 25–40 кандидатов в месяц. Часть отсеивается сразу: ошибка на вашей стороне или сумма ниже порога. Остальные человек проверяет примерно по 6 минут. Получается 3–4 часа в месяц вместо 8–10, а подано в 3–4 раза больше обращений.

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

эффект в месяц = возмещённая сумма + (сэкономленные часы × стоимость часа) − стоимость поддержки решения

Возмещённая сумма — это фактически начисленные компенсации, а не выявленные расхождения. Часть обращений отклонят, и это нормально. Если за три месяца возмещённая сумма не покрывает поддержку, значит, автоматизировали не тот тип случаев или проблема в процессах склада, а не в претензиях. Подробнее о том, как оценить процесс до внедрения, — в статье как понять, что процесс пора автоматизировать.

Риски и как их закрыть

Ложные срабатывания. Из-за кривых данных (пересорт в собственной учётке, задержка отчёта) система находит недостачу, которой нет. Лечится порогами, задержкой перед проверкой (не сверять приёмку в тот же день) и тем, что каждый случай проверяет человек.

Ошибка на вашей стороне. Иногда расхождение — это недовложение при сборке. Претензия по нему будет отклонена и может испортить отношения с площадкой. Поэтому сверка должна опираться на ваши фактические данные отгрузки, а не только на план.

Доступы. Токены API только на чтение, хранятся в защищённом хранилище, а не в таблице. Доступ к карточкам случаев — только у тех, кто работает с претензиями. В Telegram-сводки не отправляйте токены и персональные данные покупателей.

Галлюцинации в черновике. Модель может «дописать» несуществующий документ или неверную сумму. Защита: цифры в черновик подставляются из карточки, а не генерируются, а финальный текст проверяется перед отправкой.

Изменение правил площадок. Сроки, формы обращений и состав доказательств меняются. Раз в месяц проверяйте актуальные условия в справке и оферте и обновляйте настройки.

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

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

С чего начать внедрение

Неделя 1. Ручной аудит одного типа. Возьмите недостачи при приёмке за последние 2–3 месяца и сверьте вручную или полуавтоматически в таблице. Так станет понятно, есть ли вообще деньги в этой задаче и каких данных не хватает.

Неделя 2. Наведите порядок в доказательствах. Договоритесь со складом о фото коробов по каждой поставке и их хранении с привязкой к номеру. Без этого автоматизация будет находить случаи, по которым нечего приложить.

Недели 3–4. Сверка и карточки. Подключите API, настройте правило для одного типа расхождений, карточки в таблице или CRM и утреннюю сводку в Telegram.

Месяц 2. Черновики и статусы. Добавьте шаблоны обращений, генерацию черновика и контроль статусов. Подключите второй тип расхождений — обычно возвраты или логистику.

Месяц 3. Оценка. Сравните выявленные, поданные и возмещённые суммы. Решите, что расширять, а что отключить.

Чек-лист перед стартом

  • [ ] Есть токены API WB/Ozon с правами только на чтение.
  • [ ] Данные об отгрузке хранятся в одном месте: 1С, МойСклад или таблица.
  • [ ] Склад фотографирует короба и упаковочные листы по каждой поставке.
  • [ ] Назначен один ответственный за проверку и отправку претензий.
  • [ ] Записаны актуальные сроки подачи по каждому типу претензии.
  • [ ] Определены пороги: от какой суммы случай стоит подавать.
  • [ ] Понятно, где живут карточки случаев и кто их видит.

FAQ

Можно ли полностью автоматизировать подачу претензий на WB и Ozon?

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

Какие расхождения стоит автоматизировать первыми?

Обычно недостачи при приёмке. По ним проще всего собрать данные (ваша отгрузка против акта площадки), понятны доказательства, а суммы по одному случаю бывают заметными. Вторыми идут недошедшие возвраты, третьими — переплаты за логистику и хранение: там случаев много, но каждый мелкий, и правила расчёта сложнее.

Нужен ли для этого AI или хватит скриптов?

Большую часть работы делают обычные скрипты и правила: выгрузка, сверка, расчёт сумм и сроков. AI полезен для черновика обращения, разбора ответов поддержки и классификации нестандартных случаев. Если у вас 5–10 случаев в месяц, можно начать вообще без LLM, с таблицы и шаблонов.

Что делать, если у нас нет фото коробов и упаковочных листов?

Начните с организационной части. Без доказательств претензии по недостачам почти бесполезны, и автоматизация это не исправит. Договоритесь со складом о фото каждой поставки, а бот в Telegram может принимать эти фото и привязывать их к номеру поставки. Для старых случаев ориентируйтесь на то, что есть: данные учётной системы и ТСД.

Безопасно ли давать доступ к кабинету маркетплейса?

Для этой задачи нужен только API-токен с правами на чтение отчётов, поставок и финансов, без прав на изменение цен, карточек и поставок. Токен хранится в защищённом хранилище, все обращения к API логируются. Пароль от личного кабинета передавать не нужно.

Сколько времени занимает внедрение?

Сверка по одному типу расхождений с карточками и уведомлениями занимает 2–4 недели, включая аудит данных. Черновики обращений, контроль статусов и второй-третий тип расхождений — ещё 3–6 недель. Сроки сильно зависят от того, насколько аккуратно у вас ведётся учёт отгрузок.

Как понять, что автоматизация окупается?

Считайте возмещённые суммы, а не выявленные, плюс сэкономленное время менеджера, минус стоимость поддержки решения. Через 2–3 месяца станет видно, какие типы претензий приносят деньги, а какие стоит отключить. Если почти всё отклоняют, проблема обычно в доказательствах или в процессах склада.

Вывод

Претензии к WB и Ozon — это прежде всего работа с данными. Нужно вовремя заметить расхождение, собрать доказательства и не пропустить срок. Эту часть система делает каждый день и по всем поставкам, а не раз в месяц по выборке. Человек проверяет готовый случай, отправляет обращение и разбирает спорные ответы.

Практический первый шаг — сверить недостачи при приёмке за последние 2–3 месяца. Станет понятно, сколько денег лежит в этой задаче и каких данных не хватает для автоматизации.

Разберём 10–20 SKU и покажем, где теряются деньги: в цене, рекламе, остатках, возвратах или закупках. Напиши Дмитрию в Telegram @dmkosik.

marketplace diagnostic

Покажем, где селлер теряет деньги

Разберём 10–20 SKU и проверим цену, рекламу, остатки, возвраты и закупки. На выходе — список конкретных утечек и действий по приоритету.

Разобрать 10–20 SKU →