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