CRM для рекламного производства

Кейс проектной компании Гвингрейс из Воронежа примерно на 50 человек: тендерный цикл, инженерные изыскания, кадастровые и проектные работы в одной системе, с заранее определёнными ролями и задачами по каждому договору.

О компании

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

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

Что было до проекта

До весны 2025 года компания не использовала CRM или ERP. Общая рабочая коммуникация шла в групповых чатах ВКонтакте. Дальше каждый сотрудник уже сам решал, где хранить детали: в ежедневнике, собственной таблице или переписке.

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

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

Архитектура: тендер и три направления исполнения

В результате в Bitrix24 выстроили четыре основных рабочих контура: тендеры, инженерные изыскания, кадастровые работы и проектные работы. Позже добавилась отдельная воронка для управления счетами компании.

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

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

Что происходит после выигрыша тендера

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

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

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

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

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

Так удалось сохранить подробность крупного проектного процесса, но не перегружать сотрудников действиями, которые к конкретному договору не относятся.

Роли определяются в начале, а не выясняются по ходу работы

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

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

Если проект последовательно переходит в другое направление, исходные роли и данные передаются дальше. Команде не приходится заново вспоминать, кто отвечает за участок и кого нужно подключить. Эти решения принимаются в начале и дальше используются системой при постановке задач.

Как организовали внутреннюю коммуникацию

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

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

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

Без внешних интеграций — сознательно

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

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

Что произошло после передачи системы

Этот проект дал нам ещё один важный вывод — уже не про архитектуру CRM, а про сам запуск.

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

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

После отдельного разговора мы рекомендовали не переводить сразу всю компанию примерно из 50 человек, а начать с одного отдела или фокус-группы, закрепить привычку работы в CRM и затем постепенно подключать остальных. После этого компания начала переходить к работе в системе.

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

Что этот кейс показывает сегодня

Проект длился ориентировочно 2–3 месяца и был индивидуальным по исполнительным процессам. Он хорошо показывает границу между готовой основой и проектной адаптацией.

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

Для нынешней CRM Aitek для кадастра и геодезии этот опыт особенно важен: готовый отраслевой каркас позволяет быстро закрыть типовые процессы, а сложные проектные компании могут использовать его как основу и отдельно доработать те участки, где действительно есть собственная архитектура работы.

Посмотреть готовую CRM Aitek для кадастра и геодезии

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