Несколько проектов клиента в CRM: как разделять сделки

В условной компании один менеджер продаёт клиенту поставку на новый объект, другой обсуждает сервис действующего оборудования. В CRM одна большая сделка с бодрым названием «Работаем». Срок нового проекта стал сроком ремонта, а скидка на закупку неожиданно отправилась в обслуживание. Клиент один, последствия уже несколько.

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

Один покупатель может одновременно покупать разное

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

Я бы различал отношения с компанией и решение по конкретной потребности. Можно знать клиента хорошо и не знать ничего о новом проекте. Можно проиграть одну закупку и продолжать другую. Эти факты должны сосуществовать без борьбы за единственное поле «статус клиента».

Новая сделка появляется по смыслу, а не по каждому сообщению

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

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

Общие знания и условия проекта имеют разную область

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

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

Передача между проектами не означает автоматическую подмену

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

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

Как провести границу между отношениями с клиентом и отдельной покупкой

У клиентской истории и у коммерческой возможности разные часы. Отношения могут продолжаться годами, а конкретная закупка — завершиться, отмениться или перейти в обслуживание. Если обе истории запереть в одной записи, компания начнёт путать знакомство с текущей работой. Запись «с клиентом всё хорошо» не объясняет, какой из двух документов он сегодня ждёт.

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

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

В проектной модели важно заранее определить смысл связи. Записи могут быть продолжением, отдельной возможностью, сервисным обязательством или уточнением. Одного универсального «связано с» бывает недостаточно для автоматического действия. Агенту требуется понять, можно ли переносить условие, использовать документ как основание и считать работу исполненной. Если правила нет, он должен оставить вопрос человеку.

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

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

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

Практические ситуации: не смешиваем условия и продолжение разных возможностей

Далее — условные примеры для проверки метода. Они не описывают внедрения клиентов и не доказывают готовность всех настроек продукта.

Новое сообщение о старом

Покупатель уточняет адрес доставки по текущему заказу.

Что исказит результат. Создать вторую продажу из нового обращения.

Полезное действие. Связать вопрос с действующим проектом.

Что проверить в источнике. Предмет сообщения и идентификатор заказа.

Достаточный результат. Коммерческая возможность не удваивается.

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

Другой объект

Клиент обсуждает отдельную закупку для новой площадки.

Что исказит результат. Переписать условия старой сделки.

Полезное действие. Создать самостоятельный предмет с доступной связью отношений.

Что проверить в источнике. Подтверждённая новая потребность и область поставки.

Достаточный результат. У проекта свой состав, этап и продолжение.

Существенное исключение. Не требуется заново собирать уже достоверные общие сведения.

Сервис и продажа

Во время обслуживания возник вопрос о расширении.

Что исказит результат. Считать новую продажу исполнением сервиса.

Полезное действие. Развести обязательство обслуживания и новую возможность.

Что проверить в источнике. Два разных результата из разговора.

Достаточный результат. Ни одна задача не исчезла за статусом другой.

Существенное исключение. Платная новая потребность отличается от выполнения прежних обязательств.

Условие чужого проекта

Агент нашёл скидку в старой карточке.

Что исказит результат. Применить её к новому предложению автоматически.

Полезное действие. Проверить область и актуальность разрешения.

Что проверить в источнике. Согласованные условия конкретного проекта.

Достаточный результат. Предложение не расширяет частное исключение.

Существенное исключение. Общее правило клиента может существовать, но его нужно подтвердить.

Один контакт в разных ролях

Человек согласует спецификацию здесь и только получает информацию в другом проекте.

Что исказит результат. Перенести полномочия между карточками.

Полезное действие. Хранить роль в контексте решения.

Что проверить в источнике. Подтверждение участия в соответствующей задаче.

Достаточный результат. Вопрос направлен стороне с нужной ролью.

Существенное исключение. Должность сама по себе не устанавливает все полномочия.

Две суммы одного заказа

Один заказ отражён в нескольких связанных представлениях.

Что исказит результат. Сложить отображения как разные продажи.

Полезное действие. Считать по уникальной выбранной единице.

Что проверить в источнике. Связь записей и финансовое определение показателя.

Достаточный результат. В сводке нет повторного включения.

Существенное исключение. Оплаты, заказы и отгрузки могут быть разными мерами.

Матрица решений: несколько проектов клиента в crm

Условный эпизод: один заказчик, две площадки и отдельное обслуживание

Возьмём вымышленную компанию, которая оснащает помещения мебелью. Один заказчик обсуждает переговорную в головном офисе, рабочие места на новой площадке и ремонт ранее установленного шкафа. За всем стоит один бренд, в переписке встречаются одни и те же люди. Это учебный пример структуры работы, без привязки к реальному внедрению или возможностям конкретной версии Цифры.

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

Сначала отделяет сервисное обязательство. Ремонт нельзя считать закрытым потому, что отправлена новая коммерческая презентация. У него свой предмет: выяснить проблему, согласовать допустимый способ исправления, получить результат. Возможность дополнительной продажи может возникнуть позже, но не заменяет обязанности ответить на уже открытый вопрос.

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

В общий чат приходит сообщение: «Можно тот же цвет, как обсуждали?» Без контекста автоматизация легко привяжет ответ к последней открытой карточке. Правильный разбор сначала проверяет, о какой площадке идёт речь и на какое обсуждение ссылается заказчик. Если по сообщениям это не определяется, короткое уточнение полезнее уверенного переноса характеристики в оба проекта.

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

Разделение, объединение и контроль суммы без размножения продаж

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

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

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

Для финансового итога нужна договорённость о единице счёта. Возможность, предложение, заказ, отгрузка и оплата отражают разные события. Их нельзя складывать как одинаковую выручку. В клиентской сводке могут показываться несколько показателей, но каждое число должно иметь подпись и основание. Удобный общий итог без определения особенно опасен: выглядит солидно и спорить с ним психологически трудно.

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

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

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

Учебный разбор: не смешиваем условия и продолжение разных возможностей

Условный клиент имеет закупку на 200 000 рублей и отдельное обслуживание на 30 000. В чате появилось три уточнения закупки. Если каждое стало сделкой на ту же сумму, отчёт начнёт показывать лишний объём. Если обслуживание влили в закупку, потеряется отдельный срок и предмет работы.

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

Ограничения: несколько сделок одного клиента

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

Применение в продукте: Цифра

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

Подробнее: Цифра — сценарии и условия. О проверке результата — подход 404ai к задаче компании.

Связанные вопросы

• Обязательные поля CRM: что нужно на каждом этапе: убираем выдуманное заполнение и сохраняем нужные сведения.

• Приоритет обращений в CRM: что делать менеджеру первым: отличаем срочный вопрос от громкого и большого.

Первичные материалы: несколько сделок одного клиента

Источники проверены 2 ноября 2026. Они описывают указанные возможности и принципы. Сценарии приёмки, условные расчёты и рекомендации статьи — авторская методика, а не обещание результатов.

• Microsoft: лиды и связанные записи. Пример различения сущностей; конкретную модель проектов определяет компания.

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

• Microsoft: аудит изменений. История помогает проследить перенос условий и исправления.