Передача дел при увольнении сотрудника: как автоматизировать

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

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

Для селлера на Wildberries, Ozon и Я.Маркете это особенно чувствительно: дела - это не только "текущие задачи", а доступы к личным кабинетам, API-ключи, договорённости с поставщиками и байерами, шаблоны карточек и статус активных поставок. Один забытый пункт - и через месяц кто-то долго ищет, кто вёл переговоры по конкретной позиции или на кого зарегистрирован токен для выгрузки остатков.

Почему передача дел срывается, если держится на честном слове

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

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

Что нужно передать при увольнении сотрудника на маркетплейсе

Список зависит от роли, но у большинства сотрудников селлера есть общий костяк дел, которые нельзя терять:

• доступы к личным кабинетам WB, Ozon, Я.Маркет и API-токены;
• контакты и договорённости с поставщиками, байерами, подрядчиками;
• статус текущих задач: что в работе, что на паузе, что просрочено;
• шаблоны и заготовки - карточки товаров, ответы на отзывы, рекламные кампании;
• документы и переписка по незакрытым спорам, претензиям, возвратам;
• пароли от вспомогательных сервисов - аналитики, планировщиков поставок, чатов с покупателями.

Если сотрудник отвечал за смежные процессы - например, вёл часть приёмки товара или считал юнит-экономику по своим SKU - эти пункты тоже должны попасть в список отдельными строками, а не общей фразой "передал всё, что знал".

Хотите навести порядок в задачах и процессах команды? Посмотреть →

Автоматизация вместо инструкции: почему процесс, а не документ

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

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

Автоматизация здесь не про сложную систему, а про то, чтобы передача дел перестала зависеть от памяти двух людей в последнюю неделю работы.

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

Процесс передачи дел при увольнении сотрудника обычно строится из нескольких блоков.

1. Триггер запуска - HR или руководитель фиксирует дату увольнения, и с этого момента в системе автоматически создаётся процесс с чек-листом и сроками по каждому пункту.
2. Назначение получателя - до старта процесса определяется, кто принимает дела: конкретный человек, а не "коллектив отдела". Без назначенного получателя пункты чек-листа зависают неизвестно на ком.
3. Пофункциональный список задач - для менеджера маркетплейса, контент-менеджера, байера или бухгалтера список пунктов свой, привязанный к его реальным обязанностям, а не общий шаблон на всю компанию.
4. Двустороннее подтверждение - пункт закрывается не тогда, когда увольняющийся написал "передал", а когда получатель подтвердил, что реально получил доступ, контакт или файл.
5. Контрольная точка для руководителя - если часть пунктов не закрыта к оговорённому сроку, руководитель видит это в системе, а не узнаёт постфактум.

Такой процесс запускается один раз при настройке и дальше повторяется при каждом увольнении без ручной сборки чек-листа заново.

Во что обходится компании передача дел без автоматизации

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

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

Как это видно руководителю в системе

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

Дополнительный эффект - процесс не завязан на конкретного человека. Если завтра уволится HR, который обычно "следил за увольнениями руками", чек-лист передачи дел всё равно запустится и доведёт себя до конца, потому что логика зашита в систему, а не в голову одного сотрудника.

Пример чек-листа передачи дел для менеджера маркетплейса

Пример для роли менеджера по работе с маркетплейсами:

• смена паролей и передача API-токенов от кабинетов WB, Ozon, Я.Маркет;
• список поставщиков и байеров с контактами и статусом последних переговоров;
• реестр активных задач: что в очереди на приёмку, что в рекламации, что на согласовании цены;
• шаблоны карточек товаров и последние версии контента;
• доступ к таблицам с юнит-экономикой и текущей маржинальностью по ключевым SKU;
• список незакрытых обращений покупателей и статус по каждому.

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