CRM-аналитика
Сделка зависла на согласовании: как помочь без ежедневных напоминаний
Время чтения: 4 мин
Уровень материала: Для экспертов
Содержание
Менеджер каждую неделю пишет: «Удалось посмотреть предложение?» Клиент отвечает всё реже. В CRM стоит стадия «Согласование», но никто не знает, что именно согласуется: цена, безопасность, договор или место проекта в бюджете. Напоминание не помогает, потому что адресовано неизвестной проблеме.
Зависшая сделка — процесс без подтверждённого движения к следующему решению. Долгое пребывание на стадии само по себе не доказывает, что клиент потерял интерес: крупная закупка может иметь объективные сроки. Задача CRM — сделать видимыми препятствие, владельца решения и полезное действие, которое способно приблизить ответ.
Восстановите последнее согласованное действие
Начните с истории: что клиент обещал проверить, кто должен был участвовать и на какую дату договорились вернуться. Отправленное коммерческое предложение — действие продавца, но не обязательство клиента его рассмотреть. Если следующего шага не согласовали, сначала нужно восстановить договорённость.
В публичном проекте руководства GitLab по проверке ценности продукта отдельно задаются условия и участники оценки. Этот подход полезен и после пилота: подтверждённая техническая пригодность закрывает только соответствующий вопрос. Согласование бюджета или договора остаётся самостоятельной частью решения.
Спросите, что сейчас мешает перейти к следующему шагу и какой материал или участник мог бы помочь. Формулировка должна допускать честный ответ «проект больше не приоритетен». Без такой возможности CRM будет бесконечно хранить нереалистичные ожидания.
Разберите препятствие по его природе
| Препятствие | Что уточнить | Полезное действие |
|---|---|---|
| Безопасность или интеграция | Какой конкретный вопрос остался открытым? | Ответ профильного специалиста и проверяемые документы |
| Договор | Какое условие не согласовано и кто его рассматривает? | Разбор конкретной редакции с ответственными |
| Бюджет | Есть ли окно решения и допустимый объём затрат? | Сценарии объёма и полная стоимость без скрытых допущений |
| Внутренний приоритет | Сохранилась ли задача и что конкурирует за ресурс? | Обновлённое обоснование либо согласованная пауза |
| Ушёл инициатор | Кто теперь отвечает за задачу? | Проверка нового владельца и контекста |
Ответ «заняты» может быть правдой, но для управления его недостаточно. Уточните, когда уместно вернуться и что должно произойти к этому моменту. Не требуйте точной даты, если клиент её не знает; можно договориться об условии возобновления.
Подготовьте материал под решение
Для финансового вопроса нужен расчёт с допущениями, для ИТ — описание ограничений, для руководителя — связь задачи с бизнес-приоритетом. Повторная отправка полного презентационного файла редко заменяет такой материал.
Условный пример. После успешного пилота закупка платформы остановилась на интеграции с учётной системой. Выясняется, что клиенту непонятно, кто поддерживает обмен данными после запуска. Следующим действием становится встреча технических владельцев и короткая таблица ответственности: что поддерживает поставщик, что — клиент, как обнаруживается сбой и куда он передаётся.
CRM фиксирует не «напомнить через три дня», а «получить подтверждение схемы поддержки от технического владельца». После подтверждения меняется следующий шаг. Если ответа нет, менеджер возвращается к согласованной дате, а не запускает ежедневные письма автоматически.
Состав закупочной группы помогает найти нужного участника, но подключение нового контакта лучше согласовать с текущим владельцем разговора. Обход человека ради ускорения способен усложнить согласование.
Ограничьте обещания и давление
Скидка полезна только тогда, когда цена действительно является препятствием и экономика предложения это допускает. Она не закрывает недостающий сертификат, отсутствие бюджета в текущем периоде или неопределённую ответственность за внедрение.
Не создавайте ложный срок решения. Если цена действительно действует до определённой даты, объясните условие и последствия. Если срок придуман только для давления, он снижает доверие и искажает обратную связь: клиент обсуждает искусственную срочность вместо своей задачи.
Сервисная проблема, открытая жалоба или изменение предложения должны приостанавливать обычную цепочку напоминаний. Менеджер видит все параллельные контакты, чтобы маркетинг не отправлял агрессивное промо во время сложного согласования.
Признайте допустимые исходы
У процесса есть несколько честных результатов: следующий шаг подтверждён, решение отложено с условием возвращения, проект закрыт или связь потеряна после согласованного числа попыток. Отложенный проект не следует бесконечно держать в ближайшем прогнозе продаж.
Длительность стадии сравнивайте с похожими сделками, учитывая размер, продукт и процедуру закупки. Универсальное правило «всё старше 30 дней плохое» способно исключить нормальные крупные проекты и оставить небольшие зависшие сделки.
В отчёте полезны доля записей с известным препятствием, подтверждённым следующим шагом и ответственным со стороны клиента. Их задача — сделать прогноз честнее и помощь точнее. Количество отправленных напоминаний не показывает, насколько приблизилось решение.
Источники
GitLab. Proof of Value (POV). The GitLab Handbook. Проект руководства (Working draft). Проверено 23.09.2026.