битрикс24 для event-агентства — заявки, смета и чек-лист события

почему обычная воронка сделок не держит специфику события

Стандартная воронка «Лид → Переговоры → Оплата» рассчитана на сделки, где дата закрытия примерно предсказуема и зависит в основном от готовности клиента. У event-агентства всё наоборот: дата мероприятия фиксирована заранее и практически не двигается, а вот количество параллельных задач между брифом и самим событием — десятки, и решаются они одновременно: бронь площадки, согласование сметы, подрядчики, закрывающие документы.

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

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

смарт-процесс под мероприятие

Под event настраиваю отдельный смарт-процесс, а не донастраиваю обычную воронку сделок. Стадии обычно такие:

1. Бриф — зафиксированы формат, дата, бюджет, пожелания заказчика.
2. Смета — собран список позиций и их стоимость, черновой расчёт.
3. Согласование — смета отправлена заказчику, ожидаем подтверждение или правки.
4. Бронь площадки и подрядчиков — дата зафиксирована, задачи подрядчикам поставлены.
5. Подготовка — контрольные точки чек-листа, документы в работе.
6. Проведение — событие идёт, ответственный на месте.
7. Закрытие — акты подписаны, оплата получена, ретроспектива по бюджету.

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

смета как список позиций, а не единая сумма

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

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

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

чек-лист события и роботы-напоминания

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

Роботы Битрикс24 ставят задачи ответственным автоматически при переходе события на стадию «Подготовка» и эскалируют руководителю, если задача не закрыта к контрольному сроку. Это критично для event — в отличие от обычной сделки, где просроченная задача просто откладывает закрытие, здесь дата не двигается, и просроченная задача на день события означает реальный срыв.

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

работа с подрядчиками

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

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

документы без ручного набора реквизитов

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

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

типовые ошибки внедрения

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

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

Не переносят переписку с подрядчиками в задачи с привязкой к карточке — договорённости остаются в личных чатах менеджеров, и при передаче события или смене ответственного часть информации теряется. Общий разбор механики смарт-процессов — в статье о смарт-процессах в Битрикс24, похожий по логике кейс с обязательными полями под отраслевую специфику — в материале про CRM для тендеров, а как быстро находить узкое место в воронке — в статье про аналитику воронки. Обсудить настройку под ваше агентство можно на странице услуг.

частые вопросы