CRM или система управления проектами: где хранить сделки, задачи и релизы

Когда всё смешивается: сделки в чате, задачи в почте, релизы в голове

Знакомая картина: менеджер по продажам ведёт клиента в CRM, потом «передаёт» его команде голосовым сообщением в Telegram. Проджект-менеджер заводит задачу в трекере, но обещания, которые дал продавец, нигде не записаны. Через месяц клиент звонит и говорит: «Вы же договорились сделать интеграцию к пятнице». Никто не помнит. Хаос.

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

Короткий ответ: разделите по вопросу

Прежде чем разбирать детали — простое правило:

• CRM отвечает на вопрос «кто?» — кто клиент, на каком этапе сделка, что обещали, когда последний контакт.
• PM-система отвечает на вопрос «что делать?» — какие задачи, кто отвечает, дедлайн, статус выполнения.

Если вы пытаетесь ответить на оба вопроса в одном месте — это и есть источник хаоса.

Что живёт в CRM

CRM — это база знаний о клиентах и воронка продаж. Здесь хранится:

• Контакты: имя, должность, компания, история общения
• Сделки: на каком этапе, сумма, вероятность закрытия
• Коммуникация: звонки, письма, встречи с привязкой к контакту
• Обещания продавца: что именно было оговорено до подписания договора
• История отношений: как давно клиент, были ли проблемы, что покупал раньше

Главный критерий: если информация описывает отношения с человеком или компанией — она в CRM.

Что живёт в PM-системе

Трекер задач — это операционная машина команды. Здесь хранится:

• Задачи с исполнителями и дедлайнами
• Проекты и спринты
• Технические требования и спецификации
• Статусы: в работе, на проверке, готово
• Зависимости между задачами
• Внутренние обсуждения по реализации

Главный критерий: если информация описывает работу команды — она в трекере.

Пограничные случаи: где система ломается

Самые болезненные точки — переходы между продажей и исполнением.

Onboarding после продажи. Сделка закрыта, клиент подписал договор. Теперь нужно запустить его в работу. Это момент, когда данные должны перейти из CRM в трекер. Частая ошибка: продолжать вести onboarding в CRM как «этап воронки». В результате задачи нигде нет, исполнитель не назначен.

Upsell и расширение. Действующий клиент хочет купить дополнительный модуль. Это новая сделка — она начинается в CRM. Но параллельно идёт текущий проект в трекере. Нужно хранить обе ветки, не смешивая.

Клиентский feature request. Клиент просит добавить функцию. Запрос приходит через менеджера в CRM. Но само решение — принять или нет, когда, как реализовать — живёт в трекере. Связь между запросом и задачей должна быть явной: ссылка из задачи обратно на карточку клиента.

Поддержка и инциденты. Если есть хелпдеск — это третья система. Если нет — инциденты по клиентам фиксируются в CRM (история контакта), а задачи по исправлению — в трекере.

Схема передачи: от сделки к проекту

Чёткий алгоритм из пяти шагов:

• Шаг 1. Фиксация обещаний. Перед закрытием сделки менеджер заполняет поле «Что обещано клиенту» в CRM. Это обязательное поле, не опциональное.
• Шаг 2. Создание проекта в трекере. При переходе сделки в статус «Закрыта / Выиграна» автоматически или вручную создаётся проект в PM-системе с названием клиента.
• Шаг 3. Перенос ключевых данных. В описание проекта копируются: контакты клиента, обещанные сроки, объём работ, особые условия из договора.
• Шаг 4. Назначение ответственного. В трекере назначается проджект-менеджер, который с этого момента владеет клиентом в операционном смысле.
• Шаг 5. Перекрёстная ссылка. В карточке сделки в CRM — ссылка на проект в трекере. В проекте в трекере — ссылка на карточку в CRM. Это единственная точка связи двух систем.

Антипаттерны: как не надо

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

Трекер как CRM. Обратная ситуация: команда заводит карточку на каждого клиента в трекере и ведёт там переписку. Через полгода трекер превращается в кладбище «проектов» без задач и непонятно с каким статусом.

Данные в мессенджере. «Я написал в чате» — это не фиксация данных. Telegram и Slack — инструменты коммуникации, не хранилища. Всё важное из переписки должно переноситься в соответствующую систему до конца рабочего дня.

Дублирование без синхронизации. Одни и те же данные вносятся и в CRM, и в трекер вручную. Через неделю они расходятся, и никто не знает, какая версия актуальная.

Мини-чеклист: настройка за одну сессию

• Определить: какие данные — зона CRM, какие — зона трекера (письменно, не в голове)
• Договориться: что является триггером перехода из CRM в трекер (например, статус «Договор подписан»)
• Создать шаблон передачи: что именно копируется из CRM в трекер при открытии проекта
• Поставить перекрёстные ссылки: в CRM — ссылка на проект, в трекере — ссылка на клиента
• Проверить через месяц: где реально хранятся данные, совпадает ли с договорённостью

Кому хватит одной системы

Не всем нужны обе системы. Одна система достаточна, если:

• У вас один-два клиента, и все в команде знают их лично
• Вы фрилансер или работаете в паре — накладные расходы на две системы выше пользы
• Нет разделения на «продажи» и «исполнение» — один человек ведёт клиента от первого контакта до сдачи

В этих случаях достаточно PM-системы с тегом «клиент» или простой CRM с кастомными полями для задач. Усложнение ради усложнения — отдельный антипаттерн.

Вывод

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

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

Начните с одного шага: запишите, что является триггером перехода сделки в проект. Это решит половину проблем.

---

Источник: Shtab — блог