Адаптум CRM для проектных и оптовых B2B продаж

Где директор теряет управляемость

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

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

Третья проблема возникает после отправки предложения. Клиент меняет объем, валюту, адреса поставки и условия оплаты. Несколько файлов с названием «КП финал» расходятся между отделами. Утвержденная цена подменяется новой, а объяснить разницу с договором уже трудно.

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

Три контура управления B2B-продажами

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

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

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

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

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

Модель данных вокруг коммерческого обязательства

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

Предлагаемая структура включает следующие объекты.

• Компания. Юридическое название, регистрационный идентификатор, группа компаний, сегмент, менеджер, согласованный кредитный лимит, идентификатор учетной системы. Холдинг связывается с дочерними юридическими лицами; плательщик и грузополучатель могут различаться.
• Контакт и участие в сделке. Контакт хранит человека и способы связи. Отдельная связь «Участник сделки» содержит роль, влияние, отношение к предложению и дату последней проверки. Так один человек может быть экспертом в одном проекте и инициатором в другом.
• Сделка. Конкретная потребность: объект, источник, план закупки, предполагаемый срок решения, конкурент, ответственный, следующий шаг и его дата. Повторная закупка создает новую сделку либо новый заказ по рамочному договору согласно принятому правилу.
• Спецификация и строки спецификации. Требование заказчика с ревизией, статусом согласования, артикулом, количеством, единицей измерения, допустимой заменой и адресом поставки. Техническое требование отделяется от коммерческой цены.
• Коммерческое предложение и его версии. Номер, версия, связанная ревизия спецификации, валюта, срок действия, цены строк, скидки, закупочная оценка, доставка, условия оплаты и согласовавший сотрудник. Отправленная версия сохраняется неизменной; правки создают следующую.
• Договор и заказ. Договор хранит юридические условия и приложения. Заказ фиксирует принятое обязательство: выбранную версию предложения, суммы, сроки, позиции и порядок исполнения. Один договор может обслуживать несколько заказов.
• Отгрузка, счет и платеж. Отгрузка учитывает фактически переданные количества; счет содержит требование оплаты; платеж отражает подтвержденное поступление. Отдельное распределение платежа позволяет закрыть несколько счетов одним переводом или оплатить один счет частями.

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

Сквозной сценарий продажи оборудования

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

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

Инженер выпускает спецификацию S-03. На ее основе менеджер готовит предложение Q-02: две партии поставки, аванс и окончательный платеж после приемки. Снабжение подтверждает закупочные цены и сроки; коммерческий директор согласует скидку. Заказчик получает конкретную зафиксированную версию.

Позже клиент меняет 12 позиций. Возникают спецификация S-04 и предложение Q-03. Предыдущие документы сохраняются. Система должна показывать, какие строки изменились, как это повлияло на цену и срок и кто согласовал замену. Нельзя обновить цену в старом предложении так, будто клиент изначально видел новые условия.

После принятия Q-03 оформляются договор и заказ. Аванс подтверждает финансовая система. Логист создает две отгрузки, каждая со своими количествами и адресом. Частичная отгрузка не переводит весь заказ в состояние «исполнен». После приемки второй партии остающийся платеж привязывается к счету; только затем заказ удовлетворяет правилам финансового закрытия.

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

Стадии с проверяемыми условиями перехода

Название стадии должно объяснять завершенный результат работы. Для проектного маршрута можно принять такие ворота:

1. Квалифицировано. Менеджер указал компанию, потребность, ориентир закупки, участников и следующий шаг. Неизвестный бюджет допускается с явным признаком неопределенности, а не с выдуманной цифрой.
2. Требования согласованы. Инженер приложил утвержденную ревизию спецификации; менеджер указал подтверждение заказчика. Без этого расчет остается предварительным.
3. Предложение подготовлено. Снабжение подтвердило стоимость и срок, финансовый сотрудник проверил условия оплаты, руководитель одобрил исключения по скидке. Срок действия закупочной оценки не истек.
4. Предложение отправлено. Сохранены неизменная версия, дата отправки, получатель и договоренность о следующем контакте. Сам факт создания PDF эту стадию не подтверждает.
5. Коммерческие условия приняты. Есть доказательство выбора конкретной версии. Юрист и менеджер завершили необходимые договорные согласования.
6. Заказ подтвержден. Сформированы позиции и график исполнения, указаны условия запуска. Если требуется аванс, его поступление подтверждено либо оформлено разрешенное исключение.

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

Исключения которые стоит проверить до запуска

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

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

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

Восемь показателей для руководителя

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

1. Конверсия закрытых сделок: выигранные / (выигранные + проигранные) × 100%. Когорта определяется датой закрытия за месяц; паузы и дубли исключаются. Проектные и оптовые продажи показываются раздельно.
2. Длительность продажи: медиана календарных дней от первой квалификации до выигрыша по выигранным сделкам месяца. Дополнительно полезен 75-й процентиль, чтобы длинные проекты не исчезали за средним значением.
3. Скорость первого предложения: медиана рабочих часов от получения полного запроса до первой отправленной версии. Время ожидания уточнений отражается отдельно и не вычитается задним числом без истории причин.
4. Доля сделок без следующего шага: открытые активные сделки без будущей задачи с ответственным и датой / все открытые активные сделки на момент снимка × 100%. Контроль проводится ежедневно.
5. Плановая маржа подтвержденных заказов: (сумма принятых заказов − согласованные прямые затраты) / сумма заказов × 100%. Берутся заказы, подтвержденные за месяц; это расчетная маржа, не бухгалтерская прибыль.
6. OTIF исполнения: заказы с датой поставки в месяце, полностью исполненные к согласованной дате / все заказы, подлежащие исполнению в месяце × 100%. Частичные и еще не завершенные просроченные заказы остаются в знаменателе. Переносы срока сохраняются в истории; отдельно сравнивается исходное обещание.
7. Просроченная дебиторская задолженность: сумма неоплаченных остатков счетов с наступившим сроком на конец дня. Рядом выводится доля просрочки в общей дебиторской задолженности и интервалы 1–30, 31–60, свыше 60 дней.
8. Ошибка прогноза новых заказов: абсолютная разница между прогнозом на начало месяца и фактом подтвержденных заказов / факт × 100%. При нулевом факте показывается абсолютное отклонение. Прогноз фиксируется снимком; его нельзя улучшать после завершения месяца.

Шесть конкретных запросов к AI

AI полезен как помощник проектировщика и аналитика. Возможность выполнить запрос зависит от инструментов, прав и версии Адаптум; неподдерживаемые изменения оформляются как проверяемое задание на настройку.

1. «Спроектируй сущность “Участник сделки” со связями на контакт и сделку, полями “Роль”, “Влияние”, “Дата проверки”. Покажи существующие дубли и план миграции. Не объединяй контакты автоматически». Результат проверяет владелец CRM.
2. «Предложи поля “Полный запрос получен”, “Первое КП отправлено” и отчет по времени подготовки КП за квартал. Используй рабочий календарь компании, неизвестные даты вынеси отдельно». Это защищает показатель от фиктивного заполнения задним числом.
3. «Сравни Q-02 и Q-03 по строкам, количеству, цене, сроку и оплате. Покажи источник каждого отличия и список изменений, требующих согласования». AI не меняет действующее предложение и не отправляет его клиенту.
4. «Построй отчет по открытым сделкам без следующего шага и с просроченной задачей, сгруппируй по менеджеру. Используй состояние на текущий момент; не включай приостановленные сделки». Руководитель получает ссылки на исходные карточки, а не только оценочное резюме.
5. «Создай проект отчета по марже заказов с учетом закупки, доставки и скидок. Покажи строки, где отсутствует стоимость, курс или дата закупочной оценки». Неизвестные затраты запрещено подменять нулем.
6. «Найди счета с просроченным остатком и подготовь менеджерам список для проверки, учитывая распределение платежей и время последней синхронизации». AI не делает вывод о неплатежеспособности клиента и не рассылает требования без разрешения.

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

Как внедрять без перегрузки отдела продаж

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

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

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

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

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