Срок действия КП в CRM: когда старое предложение требует пересчёта

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

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

Предложение истекло, а сделка ещё не закончилась

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

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

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

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

Четыре даты отвечают на четыре разных вопроса

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

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

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

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

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

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

Версия предложения включает больше, чем итоговую сумму

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

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

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

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

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

Истечение запускает проверку, а не готовое коммерческое решение

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

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

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

Формальные календарные значения описывает RFC 5545. Для нашего процесса полезно различать дату и точный момент, когда это имеет значение. Стандарт не выбирает срок КП и не назначает действие после него. Он помогает представить уже согласованный смысл, не заменяя операционное решение команды.

Не создавайте искусственную срочность в сообщении покупателю. Если требуется пересмотр условий, объясните именно это. Фраза «предложение исчезнет через час» без предметного основания превращает технический таймер в давление. CRM должна помогать поддерживать точность, а не автоматически генерировать драматургию вокруг каждой календарной отметки.

Учебный маршрут возврата к старому КП

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

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

Иллюстративная структура ниже — не API Цифры и не юридическая форма. Она показывает предметные поля, которые помогают передать решение между ролями.

{
  "opportunity": "Учебная сделка",
  "quote": {
    "version": "КП-02",
    "sent_at": "Дата фактической передачи",
    "review_boundary": "Принятая граница проверки условий",
    "scope": "Зафиксированный состав предложения",
    "pricing_source": "Версия исходных условий"
  },
  "customer_reply": {
    "refers_to": "Требуется подтвердить версию",
    "subject": "Продолжение обсуждения"
  },
  "review": {
    "status": "Нужна проверка применимости",
    "owner": "Уполномоченная роль",
    "not_inferred": "Проигрыш или принятие сделки"
  },
  "next_step": "Подтвердить состав и условия перед новым действием"
}

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

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

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

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

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

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

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

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

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

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

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

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

Отчёт по предложениям и прогноз воронки не подменяют друг друга

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

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

В экономике полезно учитывать время повторного расчёта и разборов по старым версиям. Если новая модель позволяет быстро восстановить состав и источник, часть работы стала удобнее. Это можно проверить на сопоставимых примерах. Вывод о росте выручки потребует отдельного анализа, а не только уменьшения красных дат в CRM.

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

Срок помогает вовремя проверить условия, сохраняя историю

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

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