Антон Дегтярёвбитрикс24 для digital-агентства: проекты, клиенты, часовщик
В digital-агентстве Битрикс24 приходится настраивать не как обычную CRM отдела продаж, а как связку двух разных миров: продажа проекта клиенту и его последующая реализация командой. На 6 из 10 внедрений в агентствах вижу одну и ту же ошибку — CRM настроена под продажи, а сама работа над проектом ведётся в отдельном таск-трекере или вообще в чатах. Разбираю, как собрать это в одном портале.
почему агентству мало одной crm-воронки
Обычный бизнес продаёт товар или разовую услугу — сделка закрылась, деньги пришли, процесс завершён. У digital-агентства сделка закрывается, а дальше начинается второй, более долгий процесс — сама работа: сайт, реклама, SMM-ведение на несколько месяцев вперёд. Если держать всё это в одной воронке продаж, к третьему месяцу воронка забита закрытыми сделками вперемешку с активными проектами, и понять реальную загрузку команды по одному отчёту невозможно.
Рабочая схема — разделить два контура: CRM-воронка для продажи (лид → бриф → предложение → договор → оплата) и отдельный контур для реализации (Группы или Проекты Битрикс24) для самой работы. Переход из одного в другой происходит один раз — при переводе сделки в статус «оплачено» — и дальше это два разных представления одного клиента, а не одна общая свалка карточек.
связка продажи и проекта: что переносить, а что нет
При переходе от продажи к реализации переносить нужно не всё, а конкретный минимальный набор: техническое задание или бриф, согласованный бюджет и сроки, контактное лицо клиента и его предпочтения по связи. Это делается автоматически бизнес-процессом при смене статуса сделки — вручную копировать данные из карточки в карточку не нужно.
Частая ошибка — переносить в проект всю переписку по продаже целиком, включая обсуждение скидок и внутренние комментарии менеджера по продажам. Команде реализации это не нужно и создаёт лишний шум — они должны видеть техническое задание и договорённости, а не то, как шли переговоры о цене.
На моих внедрениях структура проекта строится под конкретную услугу агентства: для веб-разработки — этапы дизайн/вёрстка/бэкенд/тестирование, для SMM-ведения — понедельные циклы контент-план/съёмка/публикация/отчёт. Универсального шаблона проекта на все типы услуг агентства не бывает, и попытка его сделать обычно даёт неудобный компромисс, который не подходит ни одному из направлений.
часовщик: учёт времени, без которого агентство работает в минус
Для агентства, которое хотя бы часть услуг продаёт по модели часов, а не фиксированной цены, учёт времени — не опциональная функция, а обязательная часть контура. Я подробно писал, какие есть подходы к учёту рабочего времени в Битрикс24 — для агентства из трёх описанных подходов практически всегда нужен именно таймер по задачам, привязанный к конкретному клиентскому проекту.
Механика простая: каждая задача внутри проекта клиента ведёт учёт трудозатрат, отчёт по клиенту за месяц строится автоматически суммированием часов по всем задачам его проекта. Без этого агентство узнаёт, что проект «съел» вдвое больше часов, чем заложено в смете, только на этапе, когда деньги уже потрачены, а не в процессе работы.
На одном из моих проектов у агентства с фиксированной абонентской платой за ведение клиента именно почасовой отчёт по факту показал, что три клиента из пятнадцати стабильно выходят за рамки оплаченных часов на 30-40% каждый месяц — без учёта времени это было незаметно, потому что общая выручка агентства росла, а убыточность конкретных клиентов пряталась внутри общей картины.
Отдельная деталь, которую стоит продумать заранее — что считать оплачиваемым временем. Правки по замечаниям клиента, которые выходят за рамки исходного технического задания, и внутренние созвоны команды по проекту — это разные статьи затрат, и если не разделить их отдельными типами задач с самого начала, отчёт по клиенту смешает продуктивные часы с внутренними издержками агентства, и разговор о доплате за передел работ будет держаться на ощущениях, а не на цифрах.
подрядчики и фрилансеры — права доступа отдельным слоем
Digital-агентства почти всегда привлекают внешних исполнителей — дизайнера на аутсорсе, фрилансера-разработчика под конкретный проект. Частая ошибка — заводить их как обычных сотрудников с доступом наравне со штатной командой. Это создаёт риск: временный подрядчик видит клиентскую базу целиком, а не только свой текущий проект.
Правильная настройка — экстранет-пользователь или доступ, ограниченный конкретной группой проекта, без видимости общей CRM и других клиентов агентства. Подрядчик получает задачи своего проекта, может комментировать и отчитываться по часам, но не видит воронку продаж и карточки других клиентов.
Это же решает вопрос при завершении работы с подрядчиком — отключить доступ одному внешнему пользователю несравнимо проще и безопаснее, чем разбираться, к каким разделам портала имел доступ временный человек, заведённый как штатный сотрудник.
отчётность перед клиентом — не путать с внутренней
Клиенту агентства обычно нужен не полный доступ к внутренней кухне проекта, а понятный отчёт: что сделано за период, сколько часов потрачено, что в работе, что дальше. Заводить клиента как полноценного участника рабочей группы с видимостью всех внутренних комментариев команды — плохая практика, которая быстро создаёт неловкие ситуации, когда клиент видит внутреннее обсуждение сложностей проекта.
Рабочий вариант — отдельный ограниченный доступ или регулярный автоматический отчёт, который формируется по расписанию (раз в неделю или в месяц) и присылается клиенту без прямого доступа к рабочему пространству команды. Это разделение работает надёжнее, чем полагаться на дисциплину сотрудников не писать лишнего в общем чате с клиентом внутри.
дашборд руководителя агентства — что реально важно смотреть
Про построение дашборда в целом я писал в статье про дашборд для РОПа — для digital-агентства к типовым метрикам продаж добавляются метрики загрузки команды: сколько часов заложено по всем активным проектам на ближайшую неделю против фактической доступности сотрудников.
Второй специфичный агентский показатель — рентабельность по клиенту, а не только по сделке: сумма оплаты минус реальные часы команды по внутренней ставке. Именно эта метрика в моей практике чаще всего вскрывает клиентов, которые выглядят прибыльными по объёму оплаты, но на деле съедают непропорционально много ресурсов команды.
Без этих двух метрик руководитель агентства обычно видит только «сколько продали в этом месяце» и не видит, что часть проданного объёма фактически убыточна из-за перерасхода часов.
Третий показатель, который стоит выводить на дашборд отдельно — доля проектов, которые вышли за плановый срок сдачи больше чем на неделю. Сам по себе срыв срока не всегда критичен, но если этот показатель растёт из месяца в месяц, а не привязан к конкретным разовым причинам, это обычно сигнал о перегрузке команды раньше, чем сотрудники сами придут с этим разговором к руководителю.
с чего начинать внедрение, если сейчас всё в чатах и таблицах
Не пытайтесь одним заходом перевести и продажи, и все текущие проекты. Сначала настройте воронку продаж и связку с проектами для новых клиентов, которые появятся после запуска — так вы не ломаете уже идущую работу по старым проектам в разгар их выполнения.
Существующие активные проекты переносите постепенно, по одному, начиная с тех, где сейчас больше всего путаницы и споров с клиентом по объёму работ — там выгода от учёта часов и прозрачной отчётности будет заметна быстрее всего, и команда увидит ценность инструмента на конкретном примере, а не в теории.
Отдельно закладывайте время на привыкание команды к таймеру по задачам — на моих внедрениях именно этот шаг встречает наибольшее сопротивление сотрудников, потому что выглядит как дополнительный контроль. Помогает честный разговор о цели: не отслеживать, кто сколько сидит за компьютером, а понимать реальную себестоимость работы по клиенту, от которой зависит, продлевать ли с ним контракт на тех же условиях.