Взаимоисключающие сделки в CRM: одна закупка и два маршрута

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

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

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

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

Одна потребность покупателя и два способа её закрыть

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

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

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

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

Общий предмет закупки: как отличить одну закупку от двух

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

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

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

Рабочий объект группы альтернатив

Свободная заметка «тут вроде одна закупка» не годится: через месяц никто не вспомнит, почему две сделки связаны. Нужен отдельный объект или строго определённый набор полей, который переживёт смену менеджера и пересмотр прогноза.

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

Потенциал на группу, а не на каждую ветку

Главное правило: в прогнозе группа даёт одну сумму, а не сумму веток. Дальше вопрос, какую именно сумму показывать, пока группа открыта. Здесь помогает простая логика состояний.

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

Первый эпизод: обе ветки оценили на полную сумму

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

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

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

Выигравшая ветка и судьба проигравшей

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

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

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

Дополнительная закупка не отменяет выигранную

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

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

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

Изменился предмет — группа распадается

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

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

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

Когда неизвестно, общая ли закупка

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

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

Второй эпизод: двойная передача поручений одному клиенту

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

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

Решение — не запрет на второй звонок, а сигнал в интерфейсе: «по этому клиенту и предмету есть другая ветка, статус такой-то, ответственный такой-то». Дальше сотрудник решает сам, но решает информированно.

Интерфейс сотрудника: карточка группы и её сигналы

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

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

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

Трудные исключения

Исключения стоит описать заранее, иначе их начнут решать по-разному в разных отделах.

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

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

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

Четвёртое: смена ответственного. При передаче ветки группа не пересоздаётся, меняется только ответственный, а основание связи остаётся прежним.

Пятое: согласование изменения группы. Если группа влияет на прогноз, изменение её состояния стоит проводить через согласование. Документация Power Automate по принятию и отклонению запросов описывает механику таких запросов; в проектных требованиях это ориентир, а не готовая функция.

Тесты перед запуском

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

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

Практикум на другом примере

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

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

Если на каком-то шаге данных не хватает, группа уходит в неопределённость с ответственным и сроком проверки. Это лучше, чем тихо удвоить прогноз.

С чего начать поиск двойного потенциала в прогнозе

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

Проверить общую потребность по основаниям, а не по похожему названию

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

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

Соседний вопрос разобран отдельно: Дубли лидов в CRM: каналы, повторы и правила слияния. Здесь основной предмет — прямая и конкурсная возможности на одну покупку: общий потенциальный объём и единственный выигрыш; не дубли лидов.