Как настроить телеграм-бота для продавца Озон без лишних уведомлений

Сообщение «остаток заканчивается» бесполезно для меня, если из него непонятно, в каком магазине проблема и успею ли я довезти товар. У меня несколько магазинов на Ozon, поэтому одинаковые предупреждения без контекста заставляют открывать кабинеты по очереди. Формально бот сработал, а работу оставил мне. Я хочу получать не пересказ таблицы, а сигнал о ситуации, в которой нужно что-то решить. Иначе мессенджер просто становится ещё одним отчётом, только неудобным.

Телеграм-бот для селлера Озон нужен мне как диспетчер, а не как управляющий магазином. Он должен заметить отклонение, объяснить причину сообщения и привести к данным, которые можно проверить. Закупку, изменение цены или остановку рекламы я не готов поручать ему по одному сигналу. Поэтому настройку начинаю с вопроса: какое действие последует после уведомления. Если ответа нет, такое событие обычно оставляю в отчёте, а не отправляю себе в карман.

Падение остатка заслуживает сообщения, когда появляется риск дефицита

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

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

Изменение комиссии и скачок возвратов нужно сначала правильно распознать

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

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

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

Проблема с синхронизацией важнее спокойной сводки

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

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

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

Как посчитать денежный смысл уведомления об изменении комиссии

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

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

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

Как настроить уведомления Озон продавцу и не получить спам

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

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

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

Что я проверяю глазами, даже если бот молчит

По запросу «аналитика Озон — телеграм-бот» легко ожидать полноценный финансовый учёт внутри переписки. Но мессенджер показывает выбранный фрагмент, а качество вывода определяется данными и расчётом за ним. Я отдельно сверяю начисления, возвраты, расходы и состав выплаты с источником. Порядок такой проверки описал в статье про отчёты Ozon Seller и цифры для проверки магазина, где можно выбрать нужный отчёт под конкретный вопрос. Сообщение помогает найти отклонение, но не заменяет расшифровку операций. Особенно когда расход появился позже самой продажи.

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

SellOps я сделал для своих магазинов, потому что не нашёл готового сервиса, расчётам которого мог бы доверять. Для меня аналитика Озон в боте начинается с понятного источника цифры, а не с аккуратного текста сообщения. Логику работы сервиса можно посмотреть в описании того, как устроен SellOps, а наличие нужного канала уведомлений и конкретных правил стоит проверять отдельно при выборе решения. Сам факт подключения к API ещё не гарантирует правильного расчёта прибыли или полноты данных. Поэтому на проверке я прошу показать путь от исходной операции до итогового показателя. Этот подход подробнее разобран в статье о том, как проверить расчёт прибыли в сервисе аналитики.

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