Внедрение Sales Cloud: Правильный процесс от лида до прогноза

Краткий ответ

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

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

Где это ломается на практике

В типичной B2B-организации до вмешательства картина выглядит так: 40% сделок в пайплайне с уже истекшей датой закрытия, стадия "Negotiation", включающая как первые переговоры, так и контракты на подписи, и руководитель отдела продаж, ведущий свой прогноз в отдельной таблице, потому что он не доверяет системе. Ни одна из этих проблем не является технической неисправностью – все они результат неопределенных настроек.

Стадии продаж: критерий выхода для каждой стадии

Простое правило: стадия определяется тем, что сделал покупатель, а не тем, что чувствует продавец. "Клиент заинтересован" не является критерием. "Определен лицо, принимающее решение, и выделен бюджет" – является.

Вероятность — это не чувство представителя, а производная от стадии. Как только представителю разрешается вручную ее переопределять, прогноз снова становится субъективным.

Lead против Opportunity: граница, определяющая качество пайплайна

Самая распространенная ошибка – автоматическое преобразование каждого обращения в Opportunity, обычно для того, чтобы "пайплайн выглядел полным". Результатом является увеличение пайплайна в три раза и резкое падение процента закрытия, что делает любой исторический анализ бесполезным.

Рабочее определение: лид остается лидом до тех пор, пока не будут выполнены три условия – определен контакт с полномочиями, потребность сформулирована словами клиента, и есть некий временной горизонт. Обращение, не соответствующее этим условиям, обрабатывается как лид в стадии взращивания (Nurture), а не как сделка. Это также позволяет реально измерять коэффициент конверсии между маркетингом и продажами вместо измерения "щедрости" конверсии.

Тем, кто занимается построением базовой модели данных, будет полезно ознакомиться с проектированием модели данных в Salesforce.

Activities: требовать минимум там, где это важно

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

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

Forecast: что должно быть готово до запуска

Надежный прогноз требует четырех предварительных условий, и все они ведут себя как цепь – недостающее звено обнуляет остальные:

1. Корректная иерархия пользователей – прогноз в Salesforce строится в соответствии с иерархией ролей (Role Hierarchy), а не по организационной структуре в таблице.
2. Чистые даты закрытия – операционное правило, не позволяющее сделке оставаться с просроченной датой более недели.
3. Определенные категории прогноза – Pipeline, Best Case, Commit, Closed – с согласованным определением, кто и когда переводит сделку в категорию Commit.
4. Регулярный цикл проверки – еженедельное совещание по пайплайну, которое проводится на основе данных из системы, а не из параллельной таблицы.

Последний пункт является решающим. Пока существует "теневая" таблица, представители знают, что система не является источником истины, и обновляют ее с опозданием.

Что измерять после запуска

Более глубокие показатели внедрения подробно описаны в разделе Показатели внедрения Salesforce.

Чего не стоит делать на первом этапе

Сложное управление территориями (Territory Management), множественные модели прогнозирования, полноценный CPQ и автоматическое скоринг – все это возможности, которые следует добавлять после того, как базовый процесс стабилизировался и прошли два цикла продаж. Добавление их на первом этапе закрепляет еще не проверенные гипотезы и значительно удорожает любые будущие изменения.

Заключение

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