Управление digital-агентством — это не контроль задач в трекере, а согласованная работа семи контуров: привлечения клиентов, экономики, производства, команды, договорной защиты, управления владельцами и технологической инфраструктуры. Если хотя бы один контур не управляется, сбой проявляется сразу в нескольких местах: лиды не превращаются в деньги, загрузка не даёт маржи, правки съедают сроки, а фаундер остаётся единственной точкой принятия решений.
Этот вывод основан на анализе Telegram-экспорта профессионального сообщества об управлении агентством: 6 968 записей за период с 1 января по 3 сентября 2026 года, из них 6 966 обычных сообщений и 6 731 запись с непустым текстом. В данных обнаружены 413 уникальных идентификаторов отправителей; подготовленная вместе с экспортом аналитическая витрина выделяет 396 активных участников, семь тематических кластеров и 34 глубоких дискуссионных ветки. Разницу между сырым экспортом и витриной мы не скрываем: это разные правила подсчёта, поэтому цифры нельзя механически смешивать.
Короткий ответ: устойчивое агентство управляет не занятостью людей, а потоком ценности и риска. Оно квалифицирует спрос до пресейла, считает вклад проекта в покрытие постоянных затрат, принимает работу по артефактам, документирует права и изменения, устраняет зависимость от фаундера и автоматизирует только проверяемые операции.
Материал предназначен для владельцев, партнёров, COO и руководителей направлений российских digital-агентств, веб-студий и продакшенов. Он охватывает операционную модель и управленческие решения, но не заменяет индивидуальную налоговую, юридическую или кадровую консультацию и не является рейтингом программных продуктов.
Главное за минуту
- Продажи: экспертность фаундера полезна на сложной сделке, но квалификация, discovery и follow-up должны стать воспроизводимым процессом.
- Экономика: оборот и загрузка не равны прибыли; нужен вклад по клиенту, денежный календарь и сценарии налоговой нагрузки.
- Производство: единицей контроля служит принятый результат с критериями готовности, а не число часов в трекере.
- Команда: прозрачная нагрузка, границы подработок, грейды и база знаний уменьшают конфликт между доверием и контролем.
- Договоры: права на контент, порядок приёмки, каналы уведомлений и change request должны соответствовать реальному процессу.
- Фаундер: его участие следует переводить из ручного диспетчерства в правила, decision rights и разбор исключений.
- ИИ и инструменты: начинать стоит с ограниченной операции, baseline, разрешённых данных, тестового набора и человеческого подтверждения.
Содержание
- Как проводилось исследование
- Что изменилось в управлении агентством
- Модель 7К агентства
- Контур 1. Клиенты
- Контур 2. Касса
- Контур 3. Конвейер
- Контур 4. Команда
- Контур 5. Контракты
- Контур 6. Капитан
- Контур 7. Код и ИИ
- Единая панель показателей
- Матрица управленческих рисков
- План изменений на 90 дней
- Частые вопросы
- Как AI рассвет помогает собрать управляемый контур
- Вывод
Как проводилось исследование
Источником стал предоставленный пользователем экспорт публичного профессионального Telegram-чата. Сырой файл содержит сообщения, служебные события, даты, отправителей и составной Telegram-текст. Рядом с ним находилась аналитическая HTML-витрина с категориями, кейсами, бенчмарками и выводами. Мы использовали витрину как интерпретацию, а не как бесспорную базу фактов, и сверили основные счётчики с исходным JSON.
Что измерено напрямую
| Показатель | Значение | Тип доказательства | Ограничение |
|---|---|---|---|
| записи в экспорте | 6 968 | Measured | включает два служебных события |
| обычные сообщения | 6 966 | Measured | тип message в Telegram JSON |
| сообщения с непустым текстом | 6 731 | Measured | учитывает строковый и составной текст |
| уникальные идентификаторы отправителей | 413 | Measured | не равно числу регулярно активных участников |
| активные участники в витрине | 396 | User-provided | критерий отбора не описан полностью |
| период наблюдения | 01.01–03.09.2026 | Measured | неполный календарный год |
| тематические кластеры | 7 | User-provided + review | категории заданы аналитической витриной |
Качественный анализ строился в четыре прохода. Сначала сообщения были сгруппированы по проблемам: продажи, право, финансы, команда, ИИ, роль владельца и инфраструктура. Затем из длинных веток выделялись конфликтующие позиции, повторяющиеся решения и условия, при которых совет перестаёт работать. После этого цифры и правовые утверждения отделялись от мнений. Наконец, выводы сверялись с текущими официальными или первичными источниками там, где ошибка могла повлиять на деньги, договоры или данные.
Что исследование не доказывает
Корпус не является репрезентативной выборкой всех российских агентств. Активные участники пишут чаще, проблемные ситуации обсуждаются охотнее спокойной рутины, а некоторые цифры отражают личный опыт или позицию в споре. Поэтому диапазоны вроде «80–90% выручки на ретейнерах» или «70–75% утилизации» ниже названы ориентирами сообщества, а не универсальными отраслевыми нормативами.
Мы также не публикуем имена и дословные частные реплики. Для управленческого вывода важнее повторяемая проблема и условия решения, чем узнаваемость участника. Налоговые и юридические разделы опираются на актуальные открытые источники; конкретную схему всё равно следует проверять с профильным специалистом по документам самой компании.
Что изменилось в управлении агентством
В дискуссиях 2026 года заметен переход от роста любой ценой к управляемости под давлением ограничений. Руководители одновременно сталкиваются с удлинением сделки, ростом стоимости пресейла, изменением налоговых правил, повышенным вниманием к правам на контент, нестабильностью каналов связи и желанием внедрить ИИ без утечки клиентских данных.
Это меняет объект управления. Раньше небольшая студия могла держаться на трёх неформальных механизмах: сарафане, личной памяти фаундера и доверии внутри команды. При росте каждый из них превращается в риск:
- сарафан не даёт управляемого объёма спроса;
- память фаундера создаёт очередь решений и зависимость от одного человека;
- доверие без критериев готовности не показывает, где возникли потери;
- разрозненные чаты не сохраняют договорённости и контекст;
- автоматизация ускоряет не только полезную работу, но и плохо определённые ошибки.
Поэтому правильный вопрос звучит не «какую CRM купить», а «какой результат должен проходить через компанию, кто отвечает за переходы и где мы видим отклонение». Инструмент выбирают после описания потока, а не вместо него.
Модель 7К агентства
7К агентства — авторская диагностическая модель, которая соединяет семь наблюдаемых групп проблем в один управленческий цикл.
| Контур | Главный вопрос | Базовый артефакт | Ранний сигнал сбоя |
|---|---|---|---|
| Клиенты | кого и почему мы берём в работу | ICP и карточка квалификации | много встреч, мало следующих шагов |
| Касса | создаёт ли портфель денежный запас | экономика клиента и ДДС | оборот растёт, денег не хватает |
| Конвейер | как обещание превращается в принятый результат | карта delivery и Definition of Done | правки и ожидание маскируются загрузкой |
| Команда | кто способен воспроизводить качество | матрица ролей и грейдов | фаундер перепроверяет всё |
| Контракты | где закреплены границы и доказательства | договорная карта процесса | спор решают по истории чата |
| Капитан | кто и как принимает решения | decision-rights matrix | каждый вопрос ждёт владельца |
| Код и ИИ | какие действия можно делегировать системам | реестр автоматизаций и eval | красивые демо не переживают реальный поток |
Контуры связаны причинно. Слабая квалификация приводит к неподходящим проектам; неподходящие проекты разрушают план загрузки; перегруз увеличивает ошибки; ошибки создают бесплатные правки и споры; споры замораживают оплату; кассовый разрыв снова толкает агентство брать любой лид. Локальная оптимизация одного отдела не разрывает этот круг.
Быстрая самодиагностика
Поставьте каждому контуру один из трёх статусов:
- управляется: есть владелец, правило, источник данных и регулярный разбор;
- наблюдается: данные собираются, но отклонения не приводят к решению;
- держится на человеке: правило существует только в голове конкретного сотрудника.
Начинать стоит не с самого модного контура, а с узкого места, которое влияет минимум на два соседних. Например, формализация входа в производство одновременно улучшает продажи, планирование команды и договорную приёмку.
Контур 1. Клиенты
Почему входящий поток перестаёт быть системой
В корпусе регулярно повторяется сценарий: агентство долго жило на рекомендациях, затем поток ослаб, а попытка поставить «холодного продажника» не дала ожидаемого результата. Это не доказывает смерть холодных продаж как канала. Скорее, сложная услуга плохо продаётся человеком, который не умеет диагностировать бизнес-проблему, ограничить обещание и объяснить логику сметы.
Для сложной разработки, SEO, performance или AI-интеграции продавец передаёт не каталог функций, а уверенность в способе решения. Отсюда практичная модель разделения ролей:
- SDR находит сигнал и проверяет базовое соответствие;
- эксперт ведёт discovery и формирует гипотезу;
- пресейл переводит гипотезу в границы, риски и оценку;
- аккаунт фиксирует следующий шаг, ответственность и дату решения.
Фаундер может оставаться экспертом на ключевых сделках, но не должен вручную искать каждый контакт, собирать каждое КП и помнить все follow-up.
Карточка квалификации до бесплатной работы
Минимальная карточка лида должна отвечать на восемь вопросов:
- какое событие заставило клиента искать решение сейчас;
- какой измеримый процесс или результат неудовлетворителен;
- кто владеет бюджетом и кто принимает работу;
- какие данные и системы входят в задачу;
- какие сроки продиктованы реальным событием, а не желанием;
- что клиент уже пробовал;
- по какому критерию он сравнит предложения;
- какой следующий шаг согласован обеими сторонами.
Если половина полей неизвестна, подробный бесплатный аудит часто становится неоплачиваемым консалтингом. Следующий шаг лучше делать малым и двусторонним: короткий diagnostic, демонстрация подхода на ограниченном фрагменте или платное обследование.
Почему КП «замерзает» после встречи
Проблема не всегда в цене. Документ без совместного разбора оставляет клиенту задачу самостоятельно восстановить причинную цепочку: проблема → подход → объём → риск → цена → решение. Чем сложнее услуга, тем выше вероятность, что предложение будут сравнивать по последней колонке таблицы.
Рабочий процесс выглядит так:
- на discovery согласовать проблему, границы и критерий решения;
- до подготовки сметы подтвердить состав принимающих решение;
- назначить встречу разбора ещё до отправки документа;
- показывать варианты как различие в охвате, риске и ответственности;
- завершать встречу конкретным решением: согласовать, уточнить, отложить до события или закрыть;
- фиксировать причину проигрыша в CRM, а не в памяти менеджера.
Ретейнер или проект
В аналитической витрине 80–90% ретейнерной выручки названо ориентиром устойчивых студий. Без независимой отраслевой выборки это community benchmark, а не стандарт. Важнее логика: повторяющаяся работа лучше финансируется повторяющимся договором, а проектная неопределённость — отдельным discovery и change budget.
| Ситуация | Подходящая модель | Почему |
|---|---|---|
| стабильный объём поддержки и оптимизации | ретейнер с лимитами и SLA | планируемая мощность и приоритеты |
| новый продукт с высокой неопределённостью | discovery → этапы | оценка уточняется по мере доказательств |
| media spend и управление рекламой | раздельные бюджет и fee | прозрачнее налоговая и маржинальная логика |
| бонус за бизнес-результат | фикс + условный бонус | агентство не несёт риски чужого отдела продаж целиком |
| разовая типовая поставка | фиксированный scope | результат можно описать и принять заранее |
Правило: переменная часть допустима, когда агентство видит данные, влияет на результат, согласовало атрибуцию и фикс покрывает контролируемую работу. Чистый процент от продаж без доступа к CRM, продукту, цене и работе менеджеров превращает услугу в ставку на чужую систему.
Контур 2. Касса
Почему загрузка не равна прибыли
Команда может быть занята на 100%, а агентство — терять деньги. Загрузка показывает использование фонда времени, но не отвечает, оплачены ли часы, соответствует ли ставка полной себестоимости, сколько съели переделки и когда деньги поступят на счёт.
Для каждого клиента нужен минимальный управленческий P&L:
- признанная выручка за период;
- прямой труд по полной стоимости;
- подрядчики и лицензии;
- переменные платформенные и платёжные расходы;
- стоимость пресейла и аккаунтинга, если она существенна;
- вклад в покрытие постоянных расходов;
- срок оплаты и фактическая дебиторка.
Не обязательно распределять аренду и зарплату бухгалтера на каждый тикет с псевдоточностью. Но руководитель должен видеть, какие клиенты создают вклад, а какие лишь увеличивают оборот.
Утилизация как диапазон, а не культ
В обсуждениях ориентир 70–75% оплачиваемой проектной загрузки противопоставлялся двум крайностям: постоянному перегрузу и хроническому недогрузу. Такой диапазон полезен как стартовая гипотеза, но зависит от роли. У разработчика, арт-директора, аккаунта и руководителя разные доли production, коммуникаций, обучения и внутренней работы.
Считайте минимум четыре показателя:
| Показатель | Формула | Что показывает |
|---|---|---|
| доступный фонд | рабочее время минус отпуска и отсутствие | реальную мощность периода |
| billable utilization | оплачиваемые часы / доступный фонд | коммерческую загрузку |
| delivery utilization | всё время на клиентский delivery / фонд | фактическую занятость клиентами |
| rework ratio | время переделок / время delivery | скрытую потерю качества и scope |
Разница между delivery и billable показывает неоплаченную работу. Рост rework объясняет, почему «все заняты», а план не выполняется. Медиана по команде тоже может скрывать одного перегруженного архитектора, через которого проходят все проекты.
НДС при УСН в 2026 году
Налоговый блок из чата потребовал отдельной проверки, потому что правила изменились. По актуальной странице ФНС, если доход за 2025 год не превысил 20 млн рублей, с 1 января 2026 года действует автоматическое освобождение от исчисления и уплаты НДС до превышения порога в течение 2026 года. После утраты освобождения возможен выбор общеустановленной ставки 22% с вычетами или специальных ставок 5%/7% без вычета входного НДС при выполнении условий. Разъяснения ФНС по НДС при УСН обновлены 5 августа 2026 года.
Это не сводится к вопросу «какая ставка меньше». Агентству нужно смоделировать минимум три сценария:
- структура клиентов: кто принимает входной НДС к вычету;
- структура затрат: сколько входного НДС действительно возникает;
- договорная цена: включает ли она налог и как меняется при переходе;
- переходящие авансы и этапы;
- влияние ставки на валовую маржу и денежный поток.
Решение принимают с бухгалтером или налоговым консультантом на реальных оборотах и договорах. Статья фиксирует управленческий контур, а не выбирает режим за компанию.
Обязательные отчисления с интернет-рекламы
В сообществе 3% часто называли «налогом с рекламного бюджета», но юридическая конструкция точнее. Статья 18.2 закона «О рекламе» устанавливает обязательные отчисления для названных участников распространения интернет-рекламы в размере 3% от базы расчёта, связанной с доходом от соответствующих услуг. Текст статьи 18.2 и Федеральный закон № 479-ФЗ позволяют проверить норму и происхождение изменений.
Практический вывод для агентства — не «добавить 3% ко всему», а составить карту ролей в цепочке: рекламодатель, агент, распространитель, оператор рекламной системы, подрядчик. Затем бухгалтер и юрист определяют базу, обязанное лицо, первичные документы и формулировки договора. Рекламный бюджет, вознаграждение агентства и сторонние расходы лучше показывать раздельно, чтобы управленческий P&L не маскировал их одной суммой.
Денежный календарь
Еженедельный денежный календарь должен показывать остаток, подтверждённые поступления, обязательные выплаты, налоговый резерв и минимальный запас. Особенно важны три списка:
- счета, которые должны быть выставлены на этой неделе;
- акты или результаты, от которых зависит право на оплату;
- дебиторка с владельцем следующего действия и датой.
Просроченный платёж — не только задача бухгалтера. Он может быть следствием несогласованной приёмки, незафиксированного изменения, слабой коммуникации аккаунта или спорного результата. Поэтому дебиторку разбирают вместе с delivery и client service.
Контур 3. Конвейер
Единица производства — принятый артефакт
Главный конфликт в операционном блоке можно сформулировать так: тайм-трекер показывает активность, но клиент покупает результат. Отказ от учёта времени полностью тоже опасен: без него сложно понимать себестоимость, перегруз и переделки. Решение — развести два уровня.
- На уровне поставки управлять артефактом: макетом, кампанией, релизом, отчётом, интеграцией или решением.
- На уровне экономики измерять время и стоимость, затраченные на создание и исправление артефакта.
У каждой единицы работы должны быть вход, владелец, критерий готовности, проверяющий, срок, зависимости и правило изменения. Тогда часы объясняют стоимость, но не заменяют результат.
Карта delivery от обещания до приёмки
Минимальная карта включает девять переходов:
- квалифицированный запрос;
- зафиксированные границы и допущения;
- оценка и риски;
- согласованный план;
- готовые входные данные;
- производство;
- внутренняя проверка;
- клиентская приёмка;
- оплата, ретроспектива и обновление знаний.
Для каждого перехода задайте условие. «Передали в разработку» не является условием, если не определены макеты, состояния, контент, доступы и критерии ошибки. «Отправили клиенту» не равно приёмке, если договор и рабочий процесс не определяют срок и формат мотивированного замечания.
Управление изменениями
Большинство разрушающих маржу правок маскируется словами «небольшое уточнение». Change request нужен не для конфликта, а для честного выбора между сроком, бюджетом и объёмом.
Карточка изменения содержит:
- исходное согласованное требование;
- новую формулировку;
- причину изменения;
- влияние на результат, сроки, стоимость и зависимости;
- варианты: заменить объём, добавить бюджет, перенести этап или отказаться;
- решение и того, кто его принял.
Если команда боится показывать влияние изменения, проблема часто начинается ещё на продаже: клиенту обещали фиксированную определённость там, где её не было.
Контроль качества до клиента
Проверка должна быть встроена в поток, а не зависеть от свободного времени фаундера. Для типовых артефактов создайте три уровня:
- самопроверка исполнителя по короткому чек-листу;
- peer review для ошибок профессии;
- acceptance review по обещанию клиенту.
Нельзя объединять их в одно «посмотрел руководитель». Код-ревью, редактура, проверка медиаплана и юридическая вычитка ищут разные классы дефектов.
Метрики потока
Измеряйте не только срок проекта:
- lead time от принятого запроса до результата;
- cycle time активной стадии;
- время ожидания между стадиями;
- work in progress по команде;
- долю возвратов;
- first-pass acceptance;
- число и стоимость изменений scope;
- возраст заблокированных задач.
Среднее скрывает длинный хвост, поэтому используйте медиану и перцентили. Если пять быстрых задач маскируют одну критическую, среднее создаёт ложное спокойствие.
Контур 4. Команда
Подработки: не мораль, а конфликт обязательств
В чате столкнулись две позиции. Одна защищает свободу сотрудника вне оплачиваемого времени, другая считает любой внешний проект угрозой срокам и лояльности. Универсальный запрет не решает проблему, если компания не определила, что именно она покупает и какой конфликт недопустим.
Политика должна различать:
- работу вне согласованного времени без пересечения клиентов и ресурсов;
- использование рабочего времени или оборудования компании;
- работу с прямым конкурентом или клиентом агентства;
- перенос конфиденциальных материалов, кода, шаблонов и контактов;
- влияние на доступность, качество и срок основной роли.
Правила нужно закреплять в документах, согласованных с юристом и применимым трудовым правом. Тотальный скрытый мониторинг ухудшает доверие и может создавать дополнительные правовые риски. Более надёжный операционный сигнал — сорванные обязательства, неготовые артефакты, необъяснимые очереди и нарушение режима доступа.
ИБД: почему тайм-трекер не спасает
Имитация бурной деятельности возникает там, где руководитель видит только присутствие. Восемь записанных часов не доказывают восемь часов ценности; ноль записанных часов не доказывает отсутствие работы. Нужна цепочка «обязательство → наблюдаемый артефакт → критерий качества → срок → обратная связь».
Еженедельный контур команды может быть коротким:
- что должно стать готовым к концу недели;
- какой критерий приёмки;
- что блокирует результат;
- где нужна помощь или решение;
- что изменилось относительно плана.
Это не отменяет доверие. Наоборот, убирает необходимость доказывать занятость постоянными сообщениями и созвонами.
Грейды вместо титулов
Грейд полезен, когда описывает не годы и не уверенность на интервью, а масштаб самостоятельного результата:
| Уровень | Тип задачи | Неопределённость | Проверка | Организационный вклад |
|---|---|---|---|---|
| junior | ограниченная типовая | низкая | частая | обновляет инструкцию по ходу работы |
| middle | законченный участок | средняя | по контрольным точкам | предупреждает риски и помогает коллегам |
| senior | система или сложный проект | высокая | по решениям и результату | создаёт стандарты и развивает людей |
| lead | портфель и качество направления | высокая межкомандная | по метрикам контура | управляет мощностью, качеством и развитием |
Такая модель отвечает на спор «нужны ли джуны». Джун без учебного контура дорог, но отказ от начальных ролей создаёт будущий дефицит. Экономика сходится, если обучение встроено в типовые задачи, review ограничено, база знаний обновляется, а рост подтверждается повторяемой самостоятельностью.
Выгорание и мощность
Выгорание нельзя диагностировать одной загрузкой, но устойчивый перегруз — важный сигнал. Смотрите совместно на overtime, число переключений, незапланированную работу, очередь review, отпуска, текучесть и качество. Если один специалист постоянно «спасает» проекты, система награждает героизм и сохраняет причину аварий.
Практический резерв нужен для багов, консультаций, развития и изменений. Его размер зависит от роли и типа работ. Ориентир сообщества 25–30% непроектного фонда можно использовать как гипотезу для собственного измерения, а не как обязательную норму.
Контур 5. Контракты
Авторские права на изображения
Одна из самых острых веток касалась претензий за изображения на клиентских сайтах. Точные суммы из дискуссии нельзя превращать в прогноз риска для любого агентства. Но правовая основа реальна: статья 1301 ГК РФ предусматривает компенсацию при нарушении исключительного права на произведение. Актуальный текст статьи 1301 ГК РФ следует проверять вместе с обстоятельствами использования и судебной практикой.
Операционная защита начинается раньше претензии:
- для каждого изображения хранить источник, лицензию, инвойс и дату;
- различать контент заказчика и контент, подобранный агентством;
- запретить копирование из поисковой выдачи без проверки прав;
- проверять, разрешает ли лицензия нужный способ использования;
- сохранять доказательства дольше активной фазы проекта по сроку, определённому юристом;
- включить права и ответственность в договор и акт передачи.
Сгенерированное изображение не является автоматической гарантией юридической чистоты: остаются условия сервиса, сходство с охраняемыми объектами, товарные знаки и права на входные материалы. Генерацию нужно включать в тот же реестр происхождения контента.
Приёмка и дебиторка
Автоматическая приёмка при отсутствии мотивированных замечаний может быть полезным договорным механизмом, но она работает только вместе с реальным процессом доставки: понятным каналом, доказуемой датой, описанным результатом и разумным сроком реакции. Формулировку должен готовить юрист под тип договора и практику компании.
Управленческая карта приёмки включает:
- что именно передаётся;
- где лежит результат;
- кто уполномочен принять;
- какой перечень критериев применяется;
- что считается мотивированным замечанием;
- как обрабатываются дефекты и изменения;
- когда выставляется счёт или закрывается этап.
Без этой карты спор «клиент не подписывает акт» часто является не только юридическим, но и процессным: стороны по-разному понимают готовность.
Трудовые решения
В чате обсуждались «шесть окладов» и вероятность восстановления сотрудника, но эти числа не подтверждены репрезентативной статистикой и не должны служить правилом. Законодательный факт уже: статья 78 ТК РФ позволяет расторгнуть трудовой договор в любое время по соглашению сторон. Текст статьи 78 ТК РФ не означает, что этот путь всегда оптимален или что работодатель может игнорировать другие требования.
Для руководителя безопасная последовательность — зафиксировать наблюдаемые факты, отделить проблему результата от личного конфликта, проверить документы и процедуру с трудовым юристом, ограничить доступы по согласованному сценарию и сохранить деловую коммуникацию. Самодельное увольнение «по статье» на эмоциях увеличивает риск ошибки.
Договор должен отражать систему
Невозможно защитить договором процесс, которого нет. Если задачи ставятся в пяти чатах, критерии меняются устно, а доступы общие, красивый шаблон не восстановит доказательства. Поэтому юридическая карта следует за фактической картой delivery и одновременно исправляет её.
Контур 6. Капитан
Фаундер как очередь
На раннем этапе фаундер соединяет продажи, качество и культуру. При росте его центральность создаёт скрытую очередь: менеджеры ждут цену, дизайнеры — финальный взгляд, клиент — решение, партнёр — согласование. Проблема не в занятости владельца, а в том, что организация не знает, какие решения может принять без него.
Составьте decision-rights matrix:
| Решение | Кто предлагает | Кто принимает | Кого консультируют | Кого уведомляют |
|---|---|---|---|---|
| взять клиента вне ICP | sales lead | фаундер/комитет | delivery, finance | account |
| изменить scope | PM/account | владелец P&L проекта | эксперт, клиент | команда |
| выпустить рискованный релиз | tech lead | назначенный owner | QA/security | клиентский owner |
| дать скидку | sales | владелец маржи | finance | delivery |
| заменить ключевого сотрудника | lead | функциональный руководитель | HR, PM | фаундер по порогу риска |
Матрица не должна отправлять всё «на согласование генеральному». Укажите пороги: сумма, влияние на срок, юридический класс, уровень доступа или репутационный риск.
Партнёры и deadlock
Доля в компании, операционная роль и зарплата — три разные сущности. Равные доли не означают одинаковые обязанности каждый месяц. Партнёрское соглашение должно заранее описывать вклад, информационные права, стратегические решения, найм ключевых лиц, распределение прибыли, выход, оценку доли и разрешение тупика.
Конкретные механизмы — вестинг, buy-sell, медиатор и другие — имеют юридические и финансовые последствия. Их выбирают с корпоративным юристом и налоговым консультантом, а не копируют из дискуссии.
Как выйти из операционки без потери качества
Выход — не одномоментная передача всех задач COO. Он идёт по лестнице:
- фаундер выполняет и объясняет;
- сотрудник выполняет, фаундер проверяет каждый результат;
- сотрудник выполняет по стандарту, фаундер проверяет выборку;
- руководитель управляет метрикой и исключениями;
- фаундер видит портфель показателей и принимает только решения выше порога.
Каждый переход требует артефакта: инструкции, критерия, журнала решений, метрики качества и маршрута эскалации. Найм сильного человека без этой инфраструктуры просто переносит зависимость.
Контур 7. Код и ИИ
От промпта к производственному процессу
В сообществе хорошо видна трезвость после первой волны экспериментов: одиночный промпт может сделать впечатляющий черновик, но ценность появляется, когда результат встроен в повторяемый процесс и проверяется. Для агентства особенно полезны операции с большим количеством текста, частыми повторами и понятным человеческим контролем.
Кандидаты первого уровня:
- транскрибация созвона и черновик meeting report;
- извлечение обязательств, сроков и вопросов из переписки;
- первичная классификация лида по утверждённым полям;
- черновик КП из структурированного discovery;
- поиск по внутренней базе знаний с показом источника;
- проверка контента или кода по детерминированному чек-листу;
- подготовка сводки рисков перед человеческим review.
Опасный кандидат — действие с необратимым внешним эффектом, неясным критерием и чувствительными данными: отправка цены клиенту, публикация, изменение рекламного бюджета, удаление данных, merge в production или юридически значимый ответ без подтверждения.
Модель «Данные — Решение — Действие»
Перед автоматизацией классифицируйте три слоя:
| Слой | Вопрос | Минимальный контроль |
|---|---|---|
| данные | что система может читать | классификация, ACL, маскирование, журнал |
| решение | что она может рекомендовать | источник, тестовый набор, порог уверенности |
| действие | что она может изменить или отправить | allowlist, лимит, подтверждение, rollback |
Чем выше цена ошибки, тем уже полномочия. NIST рассматривает управление рисками ИИ как цикл включения trustworthiness в проектирование, использование и оценку систем; Generative AI Profile отдельно охватывает риски генеративных моделей. NIST AI Risk Management Framework — добровольная рамка, а не готовая политика для любого агентства.
Конфиденциальность клиентских данных
Нельзя принимать решение по логотипу «enterprise» или фразе «данные не используются для обучения». Нужно проверить договор, retention, регион обработки, sub-processors, доступ поддержки, журналирование, удаление, обучение, права администратора и возможность исключить чувствительные поля.
Рабочая политика делит данные минимум на четыре класса:
- публичные — допускаются в одобренных инструментах;
- внутренние — только в корпоративных аккаунтах по правилам;
- конфиденциальные клиентские — после договорной и security-проверки;
- особо чувствительные — локальный/VPC-контур либо запрет до отдельного решения.
RAG не исправляет плохие источники и сам по себе не гарантирует конфиденциальность. Нужны права до поиска, версии, журнал, тесты retrieval и отказ от ответа, когда оснований недостаточно. Подробнее об архитектуре можно прочитать в материале «RAG-система для бизнеса», а о распределении автономности — в статье «Управление автономностью ИИ-агентов».
Как измерять ИИ-процесс
Не начинайте с обещания «сэкономить X% времени». Зафиксируйте baseline на выборке реальных кейсов:
- время человека до и после;
- first-pass acceptance;
- точность обязательных полей;
- долю неподтверждённых утверждений;
- число эскалаций;
- стоимость вызовов и инфраструктуры;
- критические нарушения доступа или действия;
- долю кейсов, где человек переписал результат полностью.
Разделите качество поиска, генерации и действия. Иначе плохой ответ невозможно отнести к отсутствующему документу, ошибке retrieval, инструкции модели или интеграции.
Единая панель показателей
Панель нужна не для максимального числа графиков, а для еженедельного разговора о причинной цепочке. Ниже — минимальный cockpit.
| Контур | Показатель | Определение | Решение при отклонении |
|---|---|---|---|
| Клиенты | qualified pipeline | сумма возможностей, прошедших критерии | проверить канал, ICP и следующий шаг |
| Клиенты | proposal-to-decision time | время от разбора предложения до решения | устранить неопределённость и зависшие роли |
| Касса | contribution margin | выручка минус контролируемые прямые затраты | пересмотреть scope, ставку или delivery |
| Касса | cash runway | доступный остаток / обязательный месячный отток | ускорить приёмку, сократить риск, планировать резерв |
| Конвейер | lead time | от принятого запроса до принятого результата | найти очередь и ограничить WIP |
| Конвейер | rework ratio | переделка / всё delivery-время | исправить вход, DoD или review |
| Команда | load distribution | распределение загрузки по людям и ролям | разгрузить узкое место, передать знания |
| Команда | key-person exposure | процессы без дублёра и артефактов | план преемственности и документация |
| Контракты | acceptance aging | дни ожидания принятия этапа | синхронизировать доказательства и договор |
| Капитан | founder decision queue | решения, ожидающие владельца сверх SLA | делегировать право по порогу |
| Код и ИИ | automation acceptance | принятые без полной переделки результаты | улучшить входы/eval или остановить сценарий |
Правила хорошей метрики
У каждого показателя должны быть owner, формула, источник, частота, окно, порог и действие. «Маржа» без определения может означать валовую, вклад или чистую; «лид» может быть любой формой или только квалифицированной возможностью. Разные определения создают управленческий спор, который выглядит как спор о цифрах.
Не ставьте красно-зелёный порог до baseline. Сначала наблюдайте несколько периодов, найдите сезонность и распределение, затем установите границу, связанную с решением. Метрика без действия становится отчётностью ради отчётности.
Еженедельный ритм
Разбор укладывается в 45–60 минут, если данные готовятся заранее:
- изменения спроса и решения по крупным сделкам;
- деньги на 13 недель, дебиторка и налоговый резерв;
- риски сроков, WIP и приёмка;
- перегруз, дефицит навыка и key-person risk;
- один системный эксперимент с владельцем и критерием.
Статус отдельных задач остаётся в трекере. Встреча нужна для решения исключений, а не чтения списка.
Матрица управленческих рисков
HTML-витрина ранжировала восемь рисков по частоте и ущербу. Для публикации мы не переносим субъективные ярлыки «катастрофический» как измеренный факт, а превращаем их в воспроизводимую матрицу.
Как оценивать
Для каждого риска определите:
- событие и наблюдаемый триггер;
- вероятность на выбранном горизонте;
- финансовый, правовой, операционный и репутационный эффект;
- скорость обнаружения;
- существующие controls;
- owner реакции;
- резервный сценарий и время восстановления.
Используйте шкалу 1–4 только с письменными определениями. Итоговый балл не заменяет сценарий: редкий спор за права и частая просрочка задачи могут требовать разных ресурсов, даже если сумма одинакова.
| Риск из корпуса | Ранний сигнал | Профилактика | Реакция |
|---|---|---|---|
| претензия по контенту | нет реестра лицензий | provenance, договорные роли, аудит | сохранить доказательства, привлечь юриста |
| иссякание входящего спроса | pipeline ниже мощности | несколько каналов, экспертный контент, партнёры | сократить пресейл вне ICP, активировать базу |
| кассовый разрыв | платежи позже обязательств | 13-недельный ДДС, авансы, резерв | приоритизировать сбор и обязательства |
| скрытая переделка | растёт delivery, не billable | DoD, входной контроль, change request | разобрать причины и пересогласовать scope |
| конфликт партнёров | решения зависают | соглашение, роли, пороги | медиатор и предусмотренная процедура |
| трудовой спор | обратная связь не документируется | ясные обязанности и регулярный review | трудовой юрист и корректная процедура |
| утечка через ИИ | сотрудники используют неутверждённые аккаунты | политика данных, gateway/DLP, обучение | отзыв доступов, расследование, уведомления по правилам |
| сбой мессенджера | критичный процесс живёт в одном чате | system of record и резервный канал | перейти на резерв, восстановить журнал |
Антихрупкость вместо списка страхов
Один control может снижать несколько рисков. Реестр решений помогает при приёмке, трудовом споре и уходе ключевого человека. Классификация данных защищает ИИ, доступы и передачу проекта. Ограничение WIP уменьшает просрочки, выгорание и ошибки качества. Ищите такие controls раньше локальных заплаток.
План изменений на 90 дней
Дни 1–30: увидеть систему
Цель первого месяца — согласовать язык и baseline, не покупать новую платформу.
- Выберите по одному владельцу семи контуров.
- Опишите ICP и обязательные поля квалификации.
- Соберите P&L по активным клиентам и 13-недельный ДДС.
- Нарисуйте один типовой delivery-поток от продажи до оплаты.
- Найдите все точки обязательного решения фаундера.
- Создайте реестр договорных и правовых разрывов.
- Инвентаризируйте используемые ИИ-инструменты и классы данных.
Результат 30-го дня: карта 7К, список неизвестных, baseline и три узких места с доказательствами.
Дни 31–60: стандартизировать переходы
- Введите карточку квалификации и правило отказа.
- Зафиксируйте Definition of Done для трёх частых артефактов.
- Запустите change request и журнал решений.
- Разведите billable, delivery и rework в учёте времени.
- Опишите грейды одной ключевой функции по самостоятельному результату.
- Синхронизируйте договорные формулировки с реальной передачей и приёмкой.
- Выберите одну read-only или draft-only AI-автоматизацию.
Результат 60-го дня: новые проекты входят и выходят через одинаковые контрольные точки, а отклонения видны до финансового результата месяца.
Дни 61–90: делегировать и проверить
- Передайте три решения фаундера по ясным порогам.
- Проведите выборочный аудит качества без его участия в каждом кейсе.
- Пересмотрите убыточные или непредсказуемые договоры.
- Проверьте резервный канал коммуникации и процедуру инцидента.
- Сравните AI-пилот с baseline на frozen-наборе кейсов.
- Решите
scale / revise / stop, не подменяя решение впечатлением от демо. - Зафиксируйте следующий квартальный эксперимент.
Результат 90-го дня: система способна принять часть решений без владельца, а автоматизация имеет измеренное качество, границы и маршрут отката.
Чек-лист приёмки трансформации
- [ ] семь контуров имеют владельцев;
- [ ] определения ключевых метрик записаны;
- [ ] данные собираются из названных источников;
- [ ] новые лиды проходят единый фильтр;
- [ ] scope и изменения оставляют доказуемый след;
- [ ] три частых результата имеют DoD и review;
- [ ] загрузка отделена от маржи и переделок;
- [ ] критические процессы имеют дублёра или инструкцию;
- [ ] договор отражает реальный канал и приёмку;
- [ ] действия ИИ ограничены по данным и полномочиям;
- [ ] у каждого красного сигнала есть заранее согласованное действие.
Типичные ошибки при перестройке
Купить систему до описания процесса
Команда начинает спорить о полях и статусах уже внутри дорогого внедрения. Сначала опишите события, роли и решения на простом носителе; затем выбирайте инструмент, который поддерживает процесс и интеграции.
Автоматизировать исключение вместо основного потока
Яркий редкий кейс привлекает внимание, но не создаёт достаточно данных для обучения и эффекта. Первый кандидат должен быть частым, ограниченным, проверяемым и обратимым.
Сделать фаундера владельцем каждой метрики
Панель становится ещё одним личным отчётом. Owner метрики должен иметь полномочие изменить процесс, а фаундер — получать эскалацию выше порога.
Назвать мнение benchmark
Совет «держать 90% на ретейнере» может быть полезен, но без методологии это чужой опыт. Правильный шаг — проверить собственный churn, маржу, cash conversion и способность команды резервировать мощность.
Смешать юридическую оговорку и реальный control
Пункт договора не заменяет хранение лицензии, а NDA не заменяет ACL. Правовой, процессный и технический уровни должны подтверждать друг друга.
Измерять ИИ только временем
Быстрый неверный ответ увеличивает стоимость проверки и риск. Вместе со временем измеряйте acceptance, ошибки, неподтверждённые утверждения, эскалации и инциденты.
Частые вопросы
С чего начать управление digital-агентством, если всё держится на фаундере?
С одного сквозного потока — например, от квалифицированного лида до принятого и оплаченного первого этапа. Зафиксируйте роли, решения, критерии, данные и исключения. Затем передайте одно решение по порогу и проверяйте результат выборочно.
Какие KPI нужны digital-агентству?
Минимальный набор: qualified pipeline, время до решения по КП, contribution margin, 13-недельный денежный прогноз, lead time, rework ratio, распределение загрузки, возраст приёмки и очередь решений фаундера. Формула и действие важнее количества KPI.
Какая загрузка сотрудников считается нормальной?
Универсального процента нет. Ориентир 70–75% billable utilization из исследованного сообщества можно использовать как гипотезу, но роли различаются. Смотрите одновременно на delivery, rework, ожидание review, overtime и качество.
Нужно ли стремиться к 80–90% ретейнерной выручки?
Не обязательно. Это ориентир из обсуждений, а не проверенный отраслевой норматив. Ретейнер подходит для повторяющейся ценности и планируемой мощности; проектная модель лучше для ограниченного результата или discovery. Оценивайте маржу, churn, риск scope и денежный цикл.
Можно ли продавать услуги агентства за процент от продаж клиента?
Да, но безопаснее гибрид: фикс покрывает контролируемую работу, бонус зависит от согласованной метрики. Нужны доступ к данным, правила атрибуции и влияние на результат. Без этого агентство принимает риск продукта, цены и отдела продаж клиента.
Как снизить число бесплатных правок?
Согласовать входные данные, Definition of Done, число итераций, владельца приёмки и change request. Каждое изменение должно показывать влияние на объём, срок и бюджет. Большинство споров начинается до производства — в расплывчатом обещании.
Как контролировать удалённую команду без тотальной слежки?
Управлять обязательствами и артефактами: ожидаемый результат, критерий качества, срок, блокер и review. Время оставлять для экономики и планирования, а не использовать как единственное доказательство ценности.
Что автоматизировать с ИИ первым?
Частую ограниченную операцию с понятным входом и человеческой проверкой: meeting report, извлечение задач, классификацию лида или поиск по базе знаний. До пилота зафиксируйте baseline, разрешённые данные, тестовые кейсы, acceptance и условия остановки.
Можно ли загружать клиентские данные в публичную LLM?
Не по умолчанию. Решение зависит от договора, типа данных, retention, региона обработки, субподрядчиков, настроек аккаунта и требований клиента. Введите классификацию данных и список одобренных инструментов; особо чувствительные данные изолируйте или не передавайте модели.
Заменит ли CRM операционную систему агентства?
Нет. CRM может хранить часть событий и правил, но не определяет ICP, экономику, критерии готовности, права решений и юридическую ответственность. Сначала нужна управленческая модель, затем — подходящий набор систем.
Как понять, что агентство готово к масштабированию?
Рост не должен увеличивать зависимость от фаундера и долю скрытой переделки. Признаки готовности: воспроизводимая квалификация, положительный вклад клиентов, ограниченный WIP, видимая приёмка, владельцы метрик, дублёры критических ролей и контролируемые автоматизации.
Источники и границы интерпретации
- Первичный корпус: предоставленный Telegram JSON и аналитическая HTML-витрина, наблюдение 3 сентября 2026 года; публичный чат, агрегированная и обезличенная публикация.
- ФНС: НДС при УСН в 2026 году — порог освобождения, ставки и переходные вопросы.
- Федеральный закон № 479-ФЗ и статья 18.2 закона «О рекламе» — обязательные отчисления за интернет-рекламу.
- Статья 1301 ГК РФ — ответственность за нарушение исключительного права.
- Статья 78 ТК РФ — расторжение договора по соглашению сторон.
- NIST AI RMF — рамка управления рисками ИИ и ссылка на профиль генеративного ИИ.
Точные выводы о налогах, увольнении, компенсации, договорах и обработке данных зависят от фактов, юрисдикции и актуальной редакции норм. Все показатели спроса, поискового объёма, сложности ключевых слов, трафика, рейтингов и AI-цитирования для этой публикации остаются Unknown: подходящие данные не предоставлены и не моделировались.
Как AI рассвет помогает собрать управляемый контур
AI рассвет может связать операционную модель агентства с конкретной автоматизацией: провести аудит одного процесса и данных, спроектировать RAG или корпоративное AI‑рабочее пространство, интегрировать ИИ‑агента с CRM, ERP, 1С или браузерным контуром, а также подготовить проверку, запуск, обучение команды и поддержку. Эти действия соответствуют проблемам из контуров «Конвейер», «Команда» и «Код и ИИ» и не требуют обещать заранее экономический эффект.
Безопасный первый шаг — выбрать один процесс, зафиксировать его текущий baseline, источники данных, ограничения и проверяемый критерий приёмки. После этого можно сравнивать варианты автоматизации на одних и тех же кейсах. Обсудить задачу.
Вывод
Управление digital-агентством в 2026 году начинается не с контроля людей и не с покупки очередного сервиса. Оно начинается с видимого потока: кто приносит подходящий спрос, как обещание превращается в принятый результат, где создаётся маржа, кто принимает решение и какие доказательства остаются после действия.
Модель 7К помогает не лечить симптомы по отдельности. Клиенты без квалификации разрушают кассу; касса без экономики заставляет перегружать конвейер; конвейер без критериев выжигает команду; команда без знаний возвращает всё капитану; контракты без процесса не защищают; ИИ без границ ускоряет ошибку. Выберите один узкий поток, измерьте baseline, исправьте переходы и только затем масштабируйте людей или автоматизацию.