Делегирование в бизнесе: агентам, партнёрам, подрядчикам

Про делегирование обычно пишут для тех, у кого уже есть штат: кому из сотрудников что отдать, как не микроменеджерить, как научиться отпускать контроль. У меня штата нет ни одного человека. Весь SEO-конвейер — сайты, статьи, отчёты, часть продаж — держат агенты Claude, автоматика на cron и launchd, партнёры на проценте и подрядчики на аутсорсе.

Из-за этого я смотрю на делегирование не как на управленческий навык («научитесь доверять команде»), а как на практический вопрос: кому вообще можно отдать конкретную задачу, если команды в привычном смысле не существует. Ниже — три реальных адресата, на которые я развожу задачи, честный расчёт одного из подрядчиков и место, где вся эта система у меня самого чуть не развалилась.

Три адресата для одной задачи

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

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

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

Модели: делегирую по цене задачи, а не всё подряд

Первая ошибка делегирования моделям — отправлять всё в одну, самую дорогую и умную. Я работаю по-другому: планирование крупной задачи достаётся дорогой модели — она разбивает работу и решает, что кому передать дальше. Часть подзадач уходит моделям среднего уровня. А совсем простую, механическую операцию — например, распознать содержание раскадровки по 400 видеофайлам — можно доверить слабой локальной модели, которая крутится прямо на домашнем ПК с 16 гигабайтами памяти, без обращения к облаку вообще.

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

Этот же принцип я применяю и к людям-подрядчикам, только там переменная не цена модели, а цена часа или цена результата: подробно писал об этом в статье про работу с подрядчиками.

Партнёрка вместо штата: два случая, два разных договора

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

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

Обзвон в одном из моих проектов полностью на аутсорсе — я не набираю номера сам и даже не слушаю каждый звонок. Но я плачу не за количество звонков и не за CPL (цену лида), а по шкале коэффициентов от реальной цены, за которую клиент оплачивает пробное занятие в конкретном месяце.

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

На меньшем окне в несколько дней та же связка давала 391 лид, 36 оплат, конверсию 9,2%, среднюю цену лида 395 ₽ и среднюю цену одной оплаты 4289 ₽ — цифры расходятся день ото дня, но принцип оплаты за результат остаётся тем же независимо от объёма.

Что делегировать в первую очередь

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

Где делегирование не сработало: хаос параллельных проектов

Честная часть. Делегирование не решает проблему внимания само по себе — оно может её создать, если задач становится больше, чем вы способны проверять.

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

Система важнее героики

Делегирование без найма звучит эффектно — «шесть проектов, ноль сотрудников» и всё в этом духе. На практике это не избавление от управленческой работы, а её перевод в другую форму: вместо того чтобы управлять людьми напрямую, я управляю правилами — кому какая задача идёт, по какому критерию считается результат, где стоит контрольная точка. Часть этих правил у меня записана буквально текстом, который выполняют и люди, и агенты одинаково, — про это отдельно в статье про регламенты в компании.

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

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