Как я проверяю заявки на скидку в Ozon Seller и ставлю нижнюю границу цены
Одобренная скидка ещё не означает выгодную продажу: часть расходов остаётся прежней, а денег с заказа становится меньше. Показываю, как проверить цену из заявки после удержаний, себестоимости и налогов, а затем использовать расчёт для ограничения автоматического согласия.
Когда в моих магазинах приходит заявка на скидку, я сначала смотрю не на размер уступки, а на остаток денег после продажи. Небольшое снижение цены легко принять за безобидный способ получить заказ, особенно если товар давно лежит без движения. Но закупка от этого дешевле не становится, упаковка тоже, а часть расходов площадки зависит совсем не от моей щедрости. Поэтому я не считаю цену приемлемой только потому, что она выше себестоимости. Между этими суммами ещё стоит весь путь товара до покупателя.
Самое неприятное в таких заявках — решение выглядит проще, чем оно есть. Покупатель предлагает цену, продавец соглашается, и кажется, что осталось дождаться продажи. На деле я принимаю решение о том, сколько готов заработать или потерять на конкретном заказе. Если поручить согласие автоматике без расчёта нижней границы, она будет повторять мою ошибку при каждой подходящей заявке. Ниже покажу, какие данные я собираю, что из чего вычитаю и где проверяю настройку, которая должна удерживать цену выше моего порога.
Откуда берётся заявка на скидку и что означает согласие
Заявка приходит от покупателя, которому доступна возможность запросить скидку на товар через интерфейс Ozon. Обычно путь начинается с предложения запросить скидку в карточке, но я не предполагаю, что такая кнопка есть у каждого товара и у каждого посетителя. Покупатель сообщает, на каких условиях готов рассмотреть покупку, а продавец получает запрос в кабинете. Это не требование площадки снизить цену всему ассортименту и не уже оплаченный заказ. Я воспринимаю заявку как предложение поторговаться, которое ещё нужно проверить на своей экономике.
Запрос «озон селлер заявка на скидку» часто скрывает сразу несколько вопросов: кто попросил скидку, где её одобрить и обязательно ли вообще соглашаться. Сам факт появления заявки не делает предложенную цену выгодной или обязательной для меня. Я открываю её условия и смотрю товар, запрошенную цену и доступные действия, а также срок действия предложения, если он указан в интерфейсе. Не переношу условия одной заявки на другую по памяти. Покупательский интерес полезен, но он ещё ничего не говорит о допустимой для моего магазина цене.
Согласие я также не приравниваю к гарантированной продаже. Покупатель может не завершить оформление, а состоявшийся заказ впоследствии может вернуться. Поэтому число одобренных запросов само по себе для меня не показатель результата: я сопоставляю их с завершёнными продажами и деньгами, которые после них остались. Если заявок много, а выкупов мало, постоянное снижение цены может вообще не решать проблему. Возможно, покупателя останавливает доставка или содержание карточки, но без данных по его поведению я не выдаю это предположение за установленную причину.
Юнит-экономика по каждому товару: себестоимость, реальная выплата Ozon, комиссия, реклама и прибыль. Убыточные помечаются сразу — их не приходится высматривать в таблице.
Какую цену брать для проверки заявки
Для расчёта мне нужна сумма, которая станет доходом продавца по условиям продажи, а не просто заметная цена на экране покупателя. Между ними могут быть различия из-за механики скидок, компенсаций и других условий площадки. Я проверяю, за чей счёт уменьшается цена, что отражается в начислениях и из какой базы рассчитываются связанные удержания. Если этой информации нет, не записываю предполагаемую компенсацию себе в прибыль. Лучше оставить её за пределами предварительного расчёта, чем согласовать убыточную цену на основании догадки.
Особенно легко ошибиться, когда рядом существуют обычная цена товара, цена по акции и сумма, которую видит конкретный покупатель. Я сначала устанавливаю связь между предложением из заявки и будущим начислением продавцу, а уже затем считаю расходы. Подробности этой проверки я разобрал в статье о том, чем отличаются чёрная, белая и красная цена на Ozon и какую сумму получает продавец. Здесь мне достаточно получить понятную исходную величину для расчёта. Складывать скидки механически или считать каждую разницу своей потерей я не буду.
Следом я подбираю расходы именно для товара и предполагаемых условий его продажи. Среднее удержание по магазину годится для общего наблюдения, но плохо защищает от ошибки в отдельной заявке. У другого товара могут отличаться габариты, схема работы, затраты на обработку и частота возвратов. Я беру действующие условия из кабинета и сверяю прогноз с недавними сопоставимыми заказами. Если направление доставки или другая значимая часть расходов заранее неизвестны, считаю несколько возможных исходов и не выбираю самый дешёвый только ради согласия.
Как я считаю остаток с продажи по сниженной цене
Сначала собираю в одной строке товар, цену из заявки, ожидаемое начисление продавцу, закупочную себестоимость и расходы на продажу. Рядом оставляю такую же строку для текущей цены, чтобы видеть разницу между решениями. Себестоимость беру с учётом затрат, которые по моей системе учёта относятся к поступлению товара, а не только из счёта поставщика. Если доставка закупки уже включена в неё, второй раз эту доставку не вычитаю. Для неизвестных расходов оставляю явную пометку, иначе пустая ячейка незаметно превратится в нулевые затраты.
Дальше фиксирую доход от продажи по предложенным условиям до тех расходов, которые собираюсь вычитать отдельно. Подтверждённые компенсации учитываю по их реальному назначению, а не добавляю к выручке всё, что похоже на начисление. Если исходная сумма уже очищена от части удержаний, отмечаю, какие именно расходы в ней учтены. Иначе расчёт станет строгим на вид, но неверным по сути: одни и те же услуги окажутся вычтены повторно. На этом шаге у меня должна получиться понятная отправная сумма без смешения дохода и выплаты на счёт.
Затем вычитаю вознаграждение площадки и услуги, относящиеся к продаже: логистику, обработку и другие применимые удержания по действующим условиям. Расход, зависящий от цены, пересчитываю для новой цены и предусмотренной для него базы. Затраты, которые зависят от габаритов, маршрута или отдельной операции, не уменьшаю вслед за скидкой автоматически. Хранение учитываю по принятому способу распределения, если оцениваю полный результат товара, и явно обозначаю это в расчёте. После такого вычитания получается остаток после услуг площадки, но ещё не моя прибыль.
Из полученного остатка вычитаю себестоимость проданной единицы и собственные расходы на подготовку заказа, которые ещё нигде не учтены. Это могут быть упаковочные материалы, маркировка и другие затраты, возникающие при продаже именно этого товара. Затем учитываю налог по своей системе налогообложения и её правилам определения базы. Налог нельзя надёжно восстановить из суммы банковской выплаты простым предположением, поэтому спорные начисления я сверяю с бухгалтером. Остаток после этих операций уже гораздо ближе к сумме, ради которой я принимаю заявку.
Последним слоем добавляю обоснованно распределённые расходы на рекламу, резерв на возвраты и долю общих расходов, если хочу оценить полный результат продажи. Резерв беру из собственной истории сопоставимых заказов, а при недостатке данных прямо считаю результат предварительным. Итоговая логика такая: доход продавца минус услуги площадки, себестоимость, собственные затраты, налог и остальные учтённые расходы. Для решения о дополнительной продаже отдельно смотрю, какие затраты действительно возникнут из-за неё, а какие уже понесены независимо от заявки. Но временное решение продать остаток с небольшим вкладом в покрытие расходов не превращаю в постоянную ценовую политику.
Где автоматическое согласие начинает съедать деньги
Конкретная ошибка, которую я проверяю прежде всего, — расчёт скидки от наценки на закупку. Продавец видит, что цена после уступки всё ещё выше себестоимости, и считает разницу своим заработком. Однако из этой разницы ещё предстоит оплатить услуги площадки, подготовку, налог и прочие расходы. В деньгах ошибка равна той части затрат, которую не внесли в расчёт: ровно на неё ожидаемый результат завышен. Если такой разрыв больше предполагаемого заработка, продажа, казавшаяся прибыльной, уходит в минус.
Для сравнения с текущей ценой я считаю потерю результата отдельно. Из снижения дохода продавца вычитаю только подтверждённое уменьшение расходов, которые действительно изменятся при скидке. Полученная разница показывает, сколько заработка я отдаю ради возможного заказа. Если упаковка и доставка остаются прежними, они не помогают компенсировать уступку. Поэтому заметное снижение цены может забрать почти весь остаток с продажи, хотя относительно самой цены скидка выглядит скромно.
Минимальная цена в кабинете не заменяет расчёт прибыли. Прежде чем доверять ей автоматическое одобрение, нужно проверить, что именно эта настройка ограничивает заявки покупателей, а не другую механику изменения цены. После изменения себестоимости или расходов старый порог может перестать защищать от убытка. Пока связь настройки с заявками не подтверждена, я оставляю решение ручным.
Автоматика опасна тем, что не задаёт вопросов к однажды сохранённому порогу. Она не знает, почему я согласился на низкую цену: распродавал остаток, освобождал деньги или просто ошибся в расходах. При изменении экономики прежнее правило продолжает выглядеть допустимым, хотя результат продажи уже другой. Если причина уступок — давление конкурентов, я отдельно проверяю, есть ли смысл продолжать ценовую гонку; этот выбор подробнее разобран в статье о том, что делать с демпингом на Ozon и когда лучше выйти из товара. Само наличие более дешёвого предложения рядом не делает мой отрицательный результат приемлемым.
Где искать минимальную цену и что проверить перед сохранением
Настройки работы с такими запросами я ищу в Ozon Seller через раздел «Цены и акции» и страницу «Заявки на скидку». Если в моей версии кабинета доступно автоматическое одобрение, открываю его настройки и проверяю, где для товара задаётся нижняя граница согласования и какую цену использует правило. У меня нет доступа к вашему интерфейсу, поэтому точное название кнопки и расположение поля не выдаю за неизменную инструкцию. Если нужного пункта нет, нахожу заявки через поиск по кабинету или актуальную справку Ozon. Отдельное поле «Минимальная цена» в управлении ценами не считаю защитой для заявок, пока описание настройки прямо не подтверждает такую связь.
Сам порог получаю обратной проверкой: подставляю предполагаемую нижнюю цену в расчёт и смотрю, остаётся ли нужная мне сумма после расходов. Если результат ниже допустимого, поднимаю цену и пересчитываю зависящие от неё удержания и налог. Так я нахожу границу, соответствующую моей экономике, а не удобному размеру скидки. После сохранения проверяю товар, область действия правила и поведение заявок с ценой ниже порога по описанию функции и доступной истории обработки. Порог автоматического согласия не обязательно запрещает покупателю отправить запрос: ниже него заявка может требовать ручного решения, поэтому обещать полное исчезновение таких запросов нельзя.
В нескольких магазинах мне неудобно поддерживать этот расчёт по разрозненным выгрузкам и запоминать, где затраты уже учтены. Поэтому я сделал SellOps, когда не нашёл готового сервиса аналитики, расчётам которого мог бы доверять. Как устроен мой подход к работе с данными, я описал в руководстве по сервису, а проверку спорных сумм всё равно начинаю с исходных начислений и расходов. Само наличие аналитики не освобождает меня от проверки себестоимости и правил распределения затрат. Для порога скидки нужна проверяемая строка расчёта, а не просто итоговая сумма с подписью «прибыль».
Завтра я бы начал с товара, по которому уже есть необработанная заявка, и посчитал его результат при текущей и запрошенной цене. Затем записал бы допустимый остаток с продажи и нашёл нижнюю цену, при которой он сохраняется. После этого проверил бы в кабинете, какая настройка управляет одобрением именно таких заявок, и только тогда сохранил порог или оставил ручную обработку. Если расчёт показывает убыток, отказ не требует оправдания тем, что покупатель мог бы уйти к конкуренту. А после состоявшейся продажи я сверил бы прогноз с фактическими начислениями, чтобы следующую заявку оценивать уже на проверенных расходах.