Воркшопы для команды продаж: выявление узких мест и совместное улучшение воронки

Цели воркшопа и рамки: что улучшаем в воронке

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

В этой статье вы настроите две вещи, без которых воркшоп почти всегда превращается в спор:

Цели: какой результат должен появиться после встречи

Рамки: что именно мы улучшаем (и что сознательно не трогаем)

Если вы зададите цели и рамки правильно, команда продаж воспринимает воркшоп как инструмент помощи и влияния, а не как проверку.

!Визуальная подсказка: воркшоп улучшает конкретный участок воронки в заданных рамках

Что такое «воронка» в контексте воркшопа

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

Важно договориться, что воронка здесь — это:

Этапы: понятные состояния сделки (например, «Квалификация», «Встреча», «КП»)

Переходы: что должно произойти, чтобы сделка честно перешла на следующий этап

Потери: где и по каким причинам сделки прекращаются

Скорость: сколько времени в среднем сделка «застаивается» на этапе

Качество входа: какие лиды попадают в воронку и насколько они релевантны

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

Для базового понимания термина можно опираться на определение: Воронка продаж (Wikipedia).

Зачем воркшопу цели и рамки

Цели и рамки защищают воркшоп от трёх типичных провалов:

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

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

Не появляется план действий: все согласны, что «надо улучшать», но никто не знает, что делать завтра.

Цели и рамки переводят разговор в конструктив:

не «кто виноват», а где система ломается

не «давайте стараться», а какой эксперимент запустим

Принцип «команда — союзник»

Чтобы команда воспринимала воркшоп как поддержку, заранее задайте рабочую установку:

Фокус на процессе, а не на людях: обсуждаем шаги, данные, правила перехода, инструменты, входящий поток, контент, офферы.

Общий интерес: цель — больше закрытых сделок с меньшими потерями времени и нервов.

Право голоса: те, кто работает с клиентом, имеют приоритет в описании реальности.

Полезно прямо проговорить правило:

> «Мы ищем причины в системе, а не виноватых в людях»

Это снижает защитную реакцию и повышает качество фактов.

Цели воркшопа: три уровня

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

Бизнес-цель

Это зачем компании улучшение воронки. Примеры:

вырасти в выручке в следующем квартале

повысить предсказуемость продаж

уменьшить стоимость привлечения

На воркшопе бизнес-цель важна как «север», но сама по себе она слишком широкая.

Цель по воронке (измеримый эффект)

Это что именно должно измениться в выбранном месте воронки. Примеры:

увеличить долю перехода из «Квалификация» в «Встреча»

сократить среднее время нахождения в этапе «КП»

снизить долю проигрышей по причине «нет бюджета» за счёт лучшей квалификации

Процессная цель (конкретный результат воркшопа)

Это что вы уносите с встречи. Примеры:

список 3–5 гипотез, почему происходит провал

1–2 приоритетных эксперимента на неделю/две

назначенные владельцы, сроки, и как измеряем результат

Ниже — подсказка, как отличать цели.

| Уровень цели | Как звучит | Пример | Чем измеряем после | |---|---|---|---| | Бизнес | «Зачем» | Увеличить выручку в SMB | План/факт выручки, прогнозируемость | | По воронке | «Где меняем цифры» | Поднять переход из квалификации во встречу | Доля переходов, причины потерь | | Процессная | «Что сделаем» | Запустить 2 эксперимента по квалификации | План экспериментов, факт запуска, результаты |

Рамки воркшопа: что улучшаем (и что не трогаем)

Рамки — это ограничения, которые делают задачу решаемой за 60–120 минут и не дают уйти в бесконечные обсуждения.

Какие рамки нужно зафиксировать заранее

Сегмент клиентов

Например: SMB/Enterprise, новые клиенты/апселл, конкретная отрасль.

Канал

Например: входящие заявки, исходящий аутрич, партнёры.

Конкретный этап (или стык этапов)

Например: «Лид → Квалификация» или «КП → Переговоры».

Период данных

Например: последние 4–8 недель (важно, чтобы данные отражали текущую реальность).

Состав участников и роли

Кто приносит данные, кто принимает решения, кто владелец эксперимента.

Что считаем успехом

Какая метрика должна сдвинуться и в какой срок (пусть даже ориентировочно).

Что стоит явно исключить из рамок

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

Оценка эффективности отдельных сотрудников

Воркшоп — не аттестация. Даже если проблема в навыке, мы формулируем её как «разрыв в процессе/подготовке/инструменте».

Глобальная перестройка всего процесса продаж за одну встречу

Реалистичная цель — выбрать один узкий участок и договориться о первых действиях.

Замена CRM, мотивации и оргструктуры «по пути»

Это отдельные проекты. Их можно зафиксировать в «парковку тем», но не решать в рамках текущего воркшопа.

Как выбрать узкое место, чтобы не спорить

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

Чтобы выбор не превратился в «кто громче», используйте признаки узкого места.

Типовые признаки узкого места в воронке

Резкое падение перехода между этапами

Например, лидов много, но во встречу переходит мало.

Застревание по времени

Сделки копятся на этапе «КП» и не двигаются.

Системная причина проигрыша

В проигрышах повторяется одна формулировка: «дорого», «нет бюджета», «не поняли ценность», «выбрали конкурента».

Проблемный стык команд

Например, маркетинг передаёт лиды без нужной информации, или продавцы и пресейл не согласовали критерии готовности.

Какие данные подготовить к воркшопу

Если данных нет, воркшоп всё равно возможен, но он будет более «гипотезным». Лучше принести минимум фактов.

Сколько сделок вошло в этап и сколько вышло (в следующий этап, в проигрыш)

Топ-3 причины проигрыша (как они фиксируются сейчас)

Среднее время на этапе и где «зависает» дольше всего

3–5 примеров реальных сделок (анонимно), которые иллюстрируют проблему

Как зафиксировать итог воркшопа: «паспорт улучшения»

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

| Поле | Как заполнять | |---|---| | Участок воронки | Один этап или один переход | | Симптом | Что наблюдаем в цифрах/фактах | | Гипотезы причин | 3–5 вариантов, без обвинений | | Выбранные эксперименты | 1–2 действия, которые можно запустить быстро | | Владелец и срок | Кто делает и к какой дате | | Как измеряем | Что должно измениться, где смотрим | | Риски и зависимости | Что может помешать и от кого зависит |

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

Вывод

Цели и рамки — это «контракт» воркшопа: они сохраняют фокус, убирают персональные обвинения и превращают обсуждение в совместный план улучшений.

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

Диагностика узких мест: данные, симптомы, гипотезы

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

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

Задача этой статьи — дать вам понятный способ:

собрать минимально достаточные данные по выбранным рамкам

отделить симптом от причины

сформулировать гипотезы так, чтобы их можно было проверить и превратить в решения на воркшопе

!Логика диагностики: от фактов к проверяемым гипотезам и действиям

Термины: чтобы команда говорила на одном языке

В диагностике легко перепутать наблюдения и объяснения. Договоритесь о трёх понятиях.

Данные — факты, которые можно показать: выгрузка из CRM, список сделок, даты этапов, запись звонка, письма, заметки, причины проигрыша.

Симптом — что не так в воронке, выраженное через наблюдаемое: «переход из квалификации во встречу упал» или «сделки зависают на КП».

Гипотеза — почему так происходит (предположение), которое можно проверить: «критерии квалификации слишком мягкие, поэтому во встречу попадает много нерелевантных лидов».

Ключевой принцип для воркшопа:

> «Симптомы фиксируем по данным. Причины формулируем как гипотезы и проверяем»

Какие данные нужны для диагностики (минимум, который реально собрать)

Собирать всё подряд не нужно. Достаточно того, что помогает увидеть потери и “заторы” именно в выбранных рамках.

Количественные данные из CRM

Минимальный набор, который почти всегда полезен:

количество сделок, вошедших в выбранный этап/переход за период

количество сделок, вышедших в следующий этап

количество сделок, вышедших в проигрыш (и по каким причинам)

сколько в среднем сделки находятся на этапе (и каков “хвост”: те, что стоят очень долго)

Если в CRM этапы настроены неидеально, это нормально: вы фиксируете текущую реальность, а стандартизацию выносите отдельной задачей (в “парковку тем”).

Качественные данные: что стоит за цифрами

Цифры показывают где болит, но не всегда показывают почему. Для диагностики узкого места достаточно небольшого, но репрезентативного набора примеров.

Возьмите:

3–5 сделок, которые “упали” на проблемном переходе

3–5 сделок, которые “зависли” на проблемном этапе

3–5 успешных сделок на том же участке (чтобы увидеть контраст)

По каждой сделке полезно иметь 2–3 артефакта:

краткое описание клиента и запроса

что было сказано/отправлено (письмо, КП, запись звонка)

что стало причиной следующего шага или остановки

Контекстные данные (часто игнорируют, а зря)

Они помогают не свалиться в обвинения “менеджеры плохо продают”, если причина в системе.

Примеры:

изменился ли источник лидов или оффер за период

поменялись ли цены/пакеты/условия

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

какие ограничения есть у команды (нагрузка, SLA на обработку, участие пресейла)

Как собрать “карту симптомов” по участку воронки

Чтобы воркшоп был спокойным и конструктивным, удобно принести не “кучу отчётов”, а один компактный артефакт: таблицу симптомов.

Ниже — шаблон, который можно заполнить даже вручную.

| Что смотрим | Как это выглядит в данных | Зачем это нужно | Типичный симптом | |---|---|---|---| | Вход в этап | Сколько сделок попало на этап за период | Понимаем масштаб | Вход высокий, а дальше “не проходит” | | Выход в следующий этап | Сколько перешло дальше | Видим конверсию перехода | Резкое падение перехода | | Выход в проигрыш | Сколько закрыто и по каким причинам | Видим “дыры” и паттерны | Повторяется 1–2 причины | | Время на этапе | Среднее и сделки-долгожители | Видим “затор” | Сделки копятся и не двигаются | | Качество входа | Признаки fit: сегмент, размер, потребность | Проверяем релевантность | Много лидов “не наш клиент” |

Важно: если команда не доверяет данным CRM, это тоже симптом системы. Тогда вы фиксируете два слоя:

что показывают данные

почему им не верят (например, причины проигрыша заполняются формально)

Типовые симптомы узкого места (и как их распознать)

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

Падение перехода между этапами

Как выглядит:

сделки массово не переходят на следующий этап

при этом вход на этап может быть нормальным

Что проверять в примерах сделок:

выполняются ли условия перехода (что должно случиться, чтобы перейти дальше)

одинаково ли команда понимает “готовность” клиента

не попадает ли на этап слишком много нерелевантных лидов

“Затор” по времени на этапе

Как выглядит:

среднее время на этапе растёт

появляется “склад” сделок, которые висят без движения

Что проверять:

какие обязательные шаги должны происходить на этапе (созвон, демо, согласование)

есть ли понятный следующий шаг, зафиксированный с клиентом

не упирается ли процесс в внешний ресурс (пресейл, юристы, производство)

Повторяющиеся причины проигрыша

Как выглядит:

в проигрышах доминируют 1–2 причины (например, “дорого”, “нет бюджета”, “выбрали конкурента”)

Как не ошибиться:

причина в CRM — это часто ярлык, а не реальная первопричина

“дорого” может означать “не увидели ценность” или “не тот сегмент”

Что проверять:

на каком шаге обычно возникает возражение

что команда говорит/показывает клиенту до появления возражения

отличаются ли выигранные сделки по квалификации и сценарию коммуникации

Как превращать симптомы в гипотезы (без обвинений)

Гипотеза должна быть полезной для команды: её можно проверить и по результатам принять решение.

Правила хорошей гипотезы

Хорошая гипотеза:

привязана к конкретному симптому (этап, переход, сегмент, канал)

объясняет механизм (“из-за чего” возникает провал)

имеет опору на наблюдения (данные или примеры сделок)

проверяема (можно сделать действие и увидеть изменение)

Плохая гипотеза:

слишком общая: “менеджеры плохо продают”, “клиенты сейчас не покупают”

не указывает, что именно менять и как проверить

Техника “от симптома к причинам”

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

Где именно симптом?

Как он проявляется в данных?

В каких сделках это видно?

Что общего у этих сделок?

Какие 3–5 причин могут это объяснить?

Если нужна простая фасилитация причины без давления, помогает техника “5 почему” (последовательно уточнять “почему это происходит”), описанная как базовый метод поиска первопричин в подходе Kaizen и бережливом мышлении: Five whys.

Категории причин: чтобы гипотезы не были “вокруг навыков”

Команда продаж часто автоматически объясняет провалы “навыками продавцов”. Это иногда верно, но в воркшопе полезнее начинать с системных категорий причин.

Ниже — удобная классификация, чтобы расширить поле гипотез.

Качество входа: не тот сегмент, неверные ожидания, некорректный лид-скоринг.

Определение этапов: непонятные критерии перехода, сделки “живут” на этапе не по смыслу.

Процесс и контроль следующего шага: нет договорённости о next step, нет таймлайна, нет фиксации ответственности.

Контент и материалы: КП не отвечает на вопросы клиента, нет кейсов, нет конкурентного сравнения.

Оффер и упаковка: непонятная ценность, пакетирование, условия пилота.

Инструменты и скорость: долго отвечаем, CRM мешает, нет шаблонов, нет автоматизации.

Зависимости: пресейл, продукт, юристы, финансы, сроки поставки.

!Шаблон для группировки причин, чтобы гипотезы не сводились к персоналиям

Примеры: как выглядят гипотезы на практике

Ниже — примеры формулировок, которые обычно хорошо работают на воркшопе.

| Симптом | Гипотеза (почему так) | На что опираемся | |---|---|---| | Мало встреч после квалификации | Критерии квалификации размыты, поэтому менеджер назначает встречу без подтверждения потребности и роли ЛПР | В выборке проигрышей повторяется “не актуально”, в звонках нет вопросов про контекст и приоритет | | Сделки “висят” на КП | КП отправляется без согласованного next step и без привязки к процессу закупки клиента | В карточках сделок нет даты следующего контакта, письма “направляю КП” без вопроса о дедлайне | | “Дорого” в причинах проигрыша | Мы показываем цену до формирования ценности и критериев выбора, поэтому клиент сравнивает только по прайсу | В звонках цена обсуждается раньше, чем задачи/риски/альтернативы клиента | | Высокий процент проигрыша конкуренту | На этапе сравнения у менеджера нет инструмента, чтобы зафиксировать критерии и отличия, поэтому разговор уходит в “мы лучше” | Нет battlecard/таблицы сравнения, в заметках нет критериев выбора |

Как приоритизировать гипотезы перед воркшопом

На воркшопе времени мало, поэтому не стоит приносить 20 гипотез. Лучше 5–7, которые реально обсудить и выбрать 1–2 в работу.

Удобный фильтр — короткая оценка по трём осям:

влияние: если гипотеза верна, насколько заметно улучшится участок воронки

уверенность: насколько это подтверждается данными и примерами

простота проверки: можно ли запустить проверку за 1–2 недели без тяжёлых зависимостей

Сделайте приоритизацию прозрачной: это снижает ощущение “решили наверху”.

Артефакт диагностики: карточка гипотезы

Чтобы воркшоп завершился решениями, а не обсуждением, подготовьте гипотезы в одинаковом формате. Тогда команда сравнивает идеи по сути.

| Поле | Как заполнить | |---|---| | Симптом | Что видно в данных на выбранном участке | | Гипотеза причины | Почему это происходит (без обвинений) | | Доказательства | Какие данные/примеры сделок поддерживают гипотезу | | Что проверяем | Какое изменение в процессе/материалах попробуем | | Метрика наблюдения | Что должно сдвинуться и где смотрим | | Риски/зависимости | Что может помешать, кого подключить |

Эта карточка логически стыкуется с “паспортом улучшения” из предыдущей статьи: вы просто делаете гипотезы более конкретными и готовыми к выбору.

Если данных мало или они “грязные”: что делать

Отсутствие данных — не причина отменять воркшоп, но это влияет на формат.

Действуйте так:

договоритесь, какие данные считаются “достаточно достоверными” для первого шага

опирайтесь на разбор 8–12 реальных сделок вместо больших отчётов

фиксируйте предположения как предположения

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

Это сохраняет доверие: команда видит, что вы не “рисуете цифры”, а честно работаете с ограничениями системы.

Вывод

Диагностика узких мест — это переход от эмоций к совместной реальности:

вы приносите минимальный набор данных в рамках выбранного участка воронки

формулируете симптомы как наблюдаемое поведение системы

превращаете причины в проверяемые гипотезы, которые можно выбрать на воркшопе

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

Facilitation without conflict: trust, rules, roles

A funnel workshop only works when the room feels safe enough to be honest and structured enough to reach decisions. Otherwise, people defend themselves, argue about anecdotes, or quietly disengage.

In the previous articles you:

Defined goals and scope: which segment, channel, funnel step, and period you are improving.

Prepared diagnosis: data, symptoms, and a short list of testable hypotheses.

This article focuses on the missing piece: facilitating the workshop so Sales becomes your ally, not your opponent.

!One-page view of how trust, rules, and roles turn inputs into decisions

What “facilitation” means in this course

Facilitation is not presenting conclusions. It is the skill of:

keeping the group focused on the scoped funnel problem

balancing voices so frontline reality is heard

turning opinions into testable hypotheses and choices

protecting psychological safety so people share facts

A useful mental model is psychological safety: a shared belief that speaking up won’t lead to punishment or humiliation (Psychological safety (Wikipedia)). You don’t need perfect harmony; you need enough safety for real information to surface.

Common conflict patterns in funnel workshops (and what they look like)

These patterns show up even in strong teams. Naming them helps you steer.

Blame shift: “Marketing sends trash leads.” / “Sales can’t handle good leads.”

Metric fight: “CRM numbers are wrong, so we can’t trust anything.”

Anecdote war: loud stories replace representative data.

Role confusion: people debate decisions they don’t own, or owners stay silent.

Solution jumping: tactics appear before the symptom and cause are aligned.

Your job is not to “win” debates. Your job is to create a process where debates become decisions.

Pre-work: set trust before the meeting starts

Trust is easier to build before emotions are triggered.

Send a short “workshop contract” message

Keep it brief and explicit. Example you can adapt:

> “We are not evaluating individual performance. We are improving a specific funnel step within an agreed scope. We will use data + real deal examples to generate and test hypotheses. Output is 1–2 experiments with owners and metrics.”

Share the scope and the artifacts in advance

Share:

the scoped funnel step (or step transition)

the period of data

the “symptom table” and 5–7 hypothesis cards

the decision you want by the end (usually: which experiments to run)

This reduces surprise, which reduces defensiveness.

Decide how you will handle “data distrust”

If CRM quality is a known issue, don’t hide it. Frame it as a system constraint:

“We’ll use CRM numbers to locate where the leak is, and we’ll use deal examples to understand why.”

Opening the workshop: the first 5 minutes decide the tone

Start with clarity and safety.

A simple opening script

Use plain language:

“Today we improve this part of the funnel for this segment/channel.”

“We discuss process and system, not personal competence.”

“We will separate symptoms (what we observe) from hypotheses (why it might happen).”

“We will leave with 1–2 experiments, owners, and how we measure.”

One quick check-in question

Keep it non-therapeutic and work-relevant:

“What is one thing that makes this funnel step hard right now?”

Limit answers to one sentence each. This gives everyone voice early.

Working rules: a lightweight set that prevents escalation

Rules are not bureaucracy; they are a conflict prevention tool.

Suggested “rules of engagement” for a Sales funnel workshop

Use a short list and ask for explicit agreement.

Process over people: we describe behaviors and conditions, not personalities.

Data first, then stories: anecdotes are welcome, but we anchor them to the scoped data.

One conversation: no side-talks; if needed, pause and clarify.

Disagree with specificity: “I disagree because…” plus an example.

Assume positive intent: we challenge ideas, not motives.

Parking lot: out-of-scope items go to a visible list.

If you need a structured way to phrase observations without blame, you can borrow the idea of separating observation and interpretation from Nonviolent Communication (Nonviolent Communication (Wikipedia)). You don’t need the full method—just the discipline of “what happened” vs “what it means.”

The parking lot (non-negotiable)

Create a visible “Parking lot” section in the shared doc/board.

Rules:

add the topic in one line

label the owner who should follow up

decide later if it becomes a separate project

This prevents scope creep without dismissing real problems.

Roles: clarity that removes hidden power struggles

A workshop becomes tense when people don’t know who decides, who provides facts, and who runs the process.

Core roles you need

| Role | What they do in the workshop | What they must not do | |---|---|---| | Facilitator | Keeps structure, manages airtime, enforces rules, summarizes | Argue for a solution as if it’s “the truth” | | Data owner (often RevOps) | Brings numbers, definitions, known data limitations | Defend CRM at all costs | | Sales reps (frontline) | Provide deal reality, patterns, objections, examples | Turn it into personal defense | | Sales manager / leader | Confirms priorities, approves experiments, commits resources | Use the workshop as performance review | | Cross-functional guests (Marketing, Product, Presales) | Clarify dependencies and constraints | Take over the agenda |

Decision authority: make it explicit

Use a simple responsibility model. If your company already uses RACI, align with that language (Responsibility assignment matrix (Wikipedia)). If not, just answer:

Who recommends?

Who decides?

Who executes?

Who must be consulted?

When this is unclear, conflict looks like “debating forever.”

Facilitation tools that keep Sales engaged (and reduce dominance)

Your goal is balanced participation and fast convergence.

Use “start wide, then converge”

A reliable pattern:

Individual thinking (silent)

Small group discussion

Whole group synthesis

Decision

This reduces the advantage of the loudest voice.

A concrete technique is 1-2-4-All from Liberating Structures (1-2-4-All). It is simple to run and works well when the topic is emotionally charged.

Phrase problems as shared constraints

Instead of:

“Reps don’t qualify properly.”

Use:

“Our qualification criteria are not explicit enough, so outcomes vary by person.”

This keeps the room focused on changeable system elements.

Reframe heated statements into testable language

When someone says:

“These leads are garbage.”

You can reframe:

“Let’s define what good looks like for this funnel step: segment, trigger, role, urgency. Then we can test how many current leads match it.”

Reframing is not “politeness”; it is a conversion from emotion to an actionable hypothesis.

Handling conflict in the moment: what to do when tension rises

Conflict is information. The facilitator’s job is to slow it down and extract the signal.

A practical de-escalation sequence

Use this sequence verbatim if needed.

Pause and label: “I’m hearing strong disagreement. Let’s slow down.”

Return to scope: “We’re solving this funnel step for this segment.”

Separate observation vs interpretation: “What did we actually observe in deals/data?”

Ask for one example: “Which deal shows this clearly?”

Convert to a hypothesis: “So a testable hypothesis could be…”

Choose next action: “What is the smallest experiment to validate it?”

When someone feels personally attacked

Intervene fast and neutrally:

“Let’s keep it on process. Can we restate that as a gap in criteria, materials, or steps?”

Then move the group back to shared artifacts: symptom table, deal examples, hypothesis cards.

When the discussion becomes “CRM is wrong”

Treat it as a system issue with a split track:

Track A: make the best decision with available evidence (deal examples + partial data).

Track B: add a parking lot item: “Improve data capture for reasons lost / stage criteria.”

Turning discussion into decisions: how to close without resentment

The end of the workshop is where trust is either earned or destroyed. People watch whether talk becomes fair commitments.

A simple decision method for experiments

Ask the group to rate each hypothesis on:

impact (if true, how much this improves the funnel step)

confidence (how well it matches data and deal evidence)

ease of testing (can we test in 1–2 weeks)

Then select 1–2 experiments. Keep it visible and explicit.

Define “owner” and “definition of done” immediately

For each selected experiment, capture:

owner

start date and check-in date

where the metric will be measured

what behavior/process change is being tested

If you skip ownership, the workshop turns into theater.

Workshop outputs: the minimum artifact set

Leave the workshop with:

a filled “improvement passport” for the scoped funnel step

1–2 experiment cards with owners and metrics

a parking lot with owners

a calendar invite for the follow-up review

This creates the feeling that the workshop was for the team, not about the team.

Summary

Facilitation without conflict is not about avoiding disagreement. It is about making disagreement productive by designing:

trust: psychological safety through clear intent and non-blaming language

rules: lightweight guardrails (data first, one conversation, parking lot)

roles: explicit authority, ownership, and who contributes what

With these in place, your next step is straightforward: run the workshop so the team selects hypotheses and turns them into short experiments that move the funnel.

Совместный разбор этапов: от лидов до оплаты

В предыдущих статьях вы:

зафиксировали цели и рамки воркшопа (какой сегмент, канал и участок воронки улучшаем)

подготовили диагностику узких мест (данные, симптомы, гипотезы)

разобрали фасилитацию без конфликта (доверие, правила, роли)

Теперь нужен формат работы, который помогает команде перестать спорить абстрактно и увидеть процесс одинаково: совместный разбор этапов воронки от лидов до оплаты.

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

!Шаблон доски для совместного разбора этапов и фиксации решений

Зачем делать разбор этапов вместе с командой

Даже сильные команды часто живут в разных версиях процесса:

менеджер считает, что «квалификация пройдена», потому что клиент заинтересован

руководитель считает, что «квалификация пройдена», только если подтверждены роль ЛПР, бюджет и срок

пресейл считает, что «демо назначать рано», потому что нет сценария и данных

финансы считают, что «счёт выставить нельзя», пока не согласованы условия

На таком расхождении возникают типовые эффекты:

сделки «скачут» по этапам

конверсия и причины проигрыша становятся недостоверными

конфликты выглядят как спор людей, хотя причина — в несогласованных правилах

Совместный разбор переводит разговор в плоскость системы:

> «Давайте договоримся, что означает каждый этап, и что должно произойти, чтобы сделка честно двигалась дальше»

Что именно разбираем: этапы и переходы

В воронке важны не только этапы, но и переходы между ними.

Этап — состояние сделки (например, «Квалификация»).

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

Воркшоп обычно эффективнее, если фокусироваться на одном проблемном стыке (например, «Квалификация → Встреча»), но разбор этапов “от лидов до оплаты” нужен, когда:

команда спорит о том, где «на самом деле» возникают потери

данные в CRM не доверяют из-за разных трактовок этапов

есть сильные межфункциональные зависимости (пресейл, юристы, финансы)

Подготовка: минимум артефактов, чтобы обсуждать предметно

Чтобы разбор не превратился в обсуждение «как должно быть в идеале», принесите на воркшоп:

текущий список этапов из CRM (как есть)

8–12 реальных сделок в рамках выбранного сегмента/канала

по каждой сделке короткую хронологию: даты входа/выхода этапов и 1–2 ключевых события

Если данных мало, опирайтесь на реальные примеры сделок и фиксируйте ограничения в «парковку тем».

Формат воркшопа: как пройти путь сделки без конфликта

Ниже — структура на 60–120 минут. Она соответствует принципам фасилитации из прошлой статьи: безопасность, правила, роли.

Открытие: общий контракт

Зафиксируйте вслух:

улучшаем процесс в рамках сегмента и периода

обсуждаем поведение системы, а не личную эффективность

фиксируем решения в одном документе: «паспорт этапа» и список экспериментов

Если нужна опора на терминологию ролей, можно использовать идею матрицы ответственности (кто рекомендует, кто решает, кто делает), близкую к RACI: Responsibility assignment matrix.

Шаг 1: пройти сделку «вперёд» по этапам

Возьмите 1 выигранную сделку и 1 проигранную (похожего типа). И пройдите их по этапам:

где лид появился

что было первым значимым контактом

что подтвердило квалификацию

что стало основанием для КП

где и почему возникли переговоры

что потребовалось для выставления счёта

что реально означало «оплата» (деньги, акт, старт работ)

Правило фасилитации: говорим фактами и артефактами (письмо, запись звонка, документ, событие в календаре), а не оценками.

Шаг 2: для каждого этапа согласовать «паспорт этапа»

Паспорт этапа — это короткое описание того, как этап работает в вашей системе. Он нужен не ради бюрократии, а ради согласованности и измеримости.

Шаблон паспорта этапа:

| Поле | Как договориться на воркшопе | |---|---| | Название этапа | Как в CRM, чтобы не ломать отчётность в моменте | | Цель этапа | Какой результат этап должен дать (не «созвониться», а «подтвердить критерии») | | Входные критерии | По каким условиям сделка попадает на этап | | Выходные критерии | Что должно быть подтверждено/сделано, чтобы перейти дальше | | Обязательные действия | 2–5 шагов, без которых этап считается «не отработан» | | Артефакты | Что должно остаться в системе (поля в CRM, письмо, презентация, ТЗ) | | Типовые стоп-факторы | Что чаще всего блокирует продвижение | | Зависимости | Кто вне продаж должен подключиться и на каком условии | | Метрика здоровья | Что будем смотреть (конверсия, время на этапе, доля без next step) |

Важно: если команда боится, что «критерии — это контроль», помогите рамкой:

> «Критерии нужны не чтобы наказать, а чтобы сделки перестали зависать и чтобы продавцу было проще двигать клиента»

Шаг 3: разобрать переходы и стыки между ролями

Узкие места часто живут не внутри этапа, а на стыке:

маркетинг → продажи (качество входа, ожидания, контекст лида)

менеджер → пресейл (когда подключать и с чем)

продажи → юристы/финансы (какие условия уже согласованы)

Для каждого стыка зафиксируйте:

кто передаёт

что именно передаёт (минимальный пакет информации)

в какой форме (поля CRM, шаблон, письмо)

за какое время (внутренний SLA)

Если вы хотите избежать доминирования самых громких, используйте короткий цикл «сначала подумать индивидуально → обсудить в мини-группах → собрать в общем круге», похожий на 1-2-4-All: 1-2-4-All.

Рекомендуемая «сквозная» карта этапов от лидов до оплаты

Ниже — примерная логика этапов. Это не универсальный стандарт; смысл в том, чтобы команда согласовала свои определения.

| Участок | Что считается «готово» на выходе | Частый симптом проблемы | |---|---|---| | Лид | Понятно, откуда лид, и есть контакт для первого касания | Лиды теряются или обрабатываются слишком долго | | Контакт установлен | Состоялся реальный контакт (ответ/созвон) | Много лидов «в молчании» | | Квалификация | Подтверждены базовые критерии пригодности и следующий шаг | Высокая доля «не актуально» после встречи | | Встреча/Демо | Зафиксирована потребность/сценарий и критерии выбора | «Показали» без привязки к задаче, дальше нет движения | | КП/Оффер | Оффер собран под задачу и согласован следующий шаг по разбору | КП отправляется «в никуда», сделки зависают | | Переговоры | Понятны возражения, критерии, есть план закрытия разрывов | «Дорого», «думаем», бесконечные уточнения | | Согласование | Юр/фин части идут по таймлайну, известны владельцы с обеих сторон | Сделка стоит из-за внутренних процессов клиента/ваших | | Счёт | Счёт выставлен корректно и отправлен нужному контактному лицу | Ошибки в реквизитах, нет основания для счёта | | Оплата | Деньги получены (и понятно, что дальше: старт, акт, отгрузка) | «Оплатит на следующей неделе» без контроля |

Ключ: каждый этап должен иметь измеримый выход, иначе он превращается в «склад ожидания».

Как фиксировать проблемные места так, чтобы не обвинять людей

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

Рабочая схема перефразирования:

вместо «менеджеры не дожимают» → «нет обязательного шага по фиксации next step и даты, поэтому часть сделок остаётся без движения»

вместо «лиды мусорные» → «нет согласованного определения подходящего лида для этого сегмента и канала»

вместо «клиенты тянут с оплатой» → «нет явного шага: кто со стороны клиента владеет оплатой и какой у них процесс согласования»

Если хотите усилить дисциплину «наблюдение vs интерпретация», можно опираться на базовую идею разделения фактов и оценок из подхода ненасильственного общения: Nonviolent Communication.

Выходы воркшопа: что должно остаться после совместного разбора

После разбора этапов важно не уйти с ощущением «мы всё проговорили», а забрать конкретные артефакты.

Минимальный набор:

1 документ с паспортами 3–7 ключевых этапов (обычно достаточно тех, где есть симптомы)

список 5–10 «трений» по этапам и стыкам (что мешает двигать сделки)

1–2 эксперимента на 1–2 недели с владельцем и метрикой

«парковка тем» с владельцами (что важно, но не решаем сейчас)

Как выбрать 1–2 эксперимента по итогам разбора

После того как этапы и стыки описаны, выбор экспериментов становится проще. Хорошие кандидаты:

меняют критерий выхода этапа (делают его яснее)

добавляют обязательный шаг, который убирает зависание (например, next step)

дают команде артефакт, который ускоряет переход (шаблон письма, структура КП)

сокращают потери на стыке (минимальный пакет для передачи пресейлу/юристам)

Пример формулировки эксперимента:

«На этапе КП: перед отправкой КП фиксируем в CRM дату и формат следующего шага, подтверждённые клиентом. Проверяем, снизится ли доля сделок без активности 7 дней».

Итог

Совместный разбор этапов от лидов до оплаты — это способ синхронизировать команду вокруг реального процесса:

этапы получают понятные входы/выходы и обязательные шаги

стыки между ролями превращаются из конфликтов в договорённости

«проблемы людей» переформулируются в «проблемы системы», которые можно проверить через эксперименты

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

Приоритизация решений: ICE, impact-effort и быстрые победы

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

В предыдущих статьях курса вы:

задали цели и рамки воркшопа (чтобы не уйти в спор и расплывчатость)

сделали диагностику узких мест (данные → симптомы → гипотезы)

настроили фасилитацию без конфликта (доверие, правила, роли)

провели совместный разбор этапов и зафиксировали «паспорт этапа» и трения на стыках

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

Что именно мы приоритизируем

На воркшопе легко перепутать три сущности:

Гипотеза: предположение, почему возникает симптом.

Решение: изменение в процессе, материалах, правилах этапа или стыка.

Эксперимент: ограниченная по времени проверка решения с метрикой и владельцем.

Приоритизировать удобнее не абстрактные «решения вообще», а эксперименты, потому что у них есть:

владелец

срок

измерение

чёткий объём работ

Принципы приоритизации, которые сохраняют союз с командой продаж

Чтобы приоритизация не воспринималась как «руководитель выбрал, что вам делать», держите правила простыми.

Сравниваем идеи по одинаковым критериям: влияние, уверенность, усилие.

Начинаем с маленьких ставок: лучше 1–2 быстрых эксперимента, чем «реформа продаж».

Не спорим о вкусах: если нет согласия — переводим в формат проверки.

Не наказываем сложные темы: сложное не равно ненужное; просто сложному нужен план.

Метод impact-effort: быстро отсекаем очевидное

Impact-effort (влияние-усилие) — это простая матрица, которая помогает группе увидеть баланс между ожидаемым эффектом и затратами.

Impact (влияние): насколько идея может улучшить выбранный участок воронки.

Effort (усилие): сколько времени, координации и зависимости нужно, чтобы запустить.

Обычно достаточно шкалы 1–5.

| Оценка | Impact (влияние) | Effort (усилие) | |---|---|---| | 1 | Почти не повлияет на метрику | Можно сделать за час без зависимостей | | 3 | Умеренно сдвинет конверсию/скорость | Нужны согласования и 2–5 дней работы | | 5 | Существенно сдвинет метрику участка | Нужны другие команды, изменения в процессах, 2+ недели |

Как использовать матрицу в воркшопе:

Запишите 8–15 кандидатных экспериментов на карточках (по одному на карточку).

Команда совместно ставит каждой карточке две оценки: impact и effort.

Разложите карточки по четырём зонам.

Зоны интерпретируются так:

Высокое влияние + низкое усилие: приоритет №1.

Высокое влияние + высокое усилие: важные инициативы, но их дробят на этапы или готовят отдельный проект.

Низкое влияние + низкое усилие: можно делать только если это поддерживает дисциплину (например, шаблон письма), но не вместо ключевых.

Низкое влияние + высокое усилие: почти всегда в «парковку».

!Матрица помогает команде визуально договориться, что делаем в первую очередь

Метод ICE: когда нужно сравнить близкие по смыслу идеи

Если после impact-effort у вас осталось 4–6 сильных кандидатов в «верхнем правом/левом» секторе, часто нужно выбрать 1–2. Тут помогает ICE.

ICE — это способ оценить идею по трём параметрам:

I (Impact): насколько сильный эффект ожидаем на выбранной метрике участка воронки.

C (Confidence): насколько вы уверены, что именно это причина (опора на данные, сделки, повторяемость).

E (Ease): насколько легко запустить проверку (ресурсы, зависимости, скорость).

Оценки обычно ставят по шкале 1–10, где 10 — максимум.

Как считать ICE без усложнений

Чтобы не спорить о математике, используйте простое правило:

ставим три оценки

считаем итоговый балл как произведение

Формула:

Где:

— оценка влияния

— оценка уверенности

— оценка простоты запуска

Важная договорённость: ICE — это не «истина», а способ структурировать групповое решение одинаковым языком.

Шкалы, которые подходят именно для воркшопов продаж

Чтобы оценки не превратились в политику, заранее зафиксируйте смысл крайних значений.

| Параметр | 3–4 балла | 7–8 баллов | 10 баллов | |---|---|---|---| | Impact | Косметика, повлияет на единичные сделки | Повлияет на заметную долю сделок в рамке | Меняет правило/артефакт на этапе и затрагивает большинство сделок | | Confidence | В основном мнения, мало примеров | Есть повторяемые паттерны в сделках и частичные данные | Есть сильная связка: данные + несколько явных примеров + согласие фронта | | Ease | Нужны другие команды, долго, много рисков | Нужны 1–2 согласования, но реально за 1–2 недели | Можно запустить силами продаж за 2–5 дней |

Как проводить оценку, чтобы не было доминирования

Практика для фасилитатора:

Каждый участник ставит оценки I/C/E молча (например, в таблице или стикерами).

Вы собираете медиану или среднее (не идеальная точность важна, а согласованность).

Обсуждаете только сильные расхождения.

Правило, которое снижает конфликт:

спорим не «правда/неправда», а «каких данных не хватает, чтобы повысить confidence»

Быстрые победы: что это на самом деле (и чем опасны)

Быстрая победа — это эксперимент, который даёт эффект быстро и заметно, при минимальном внедрении.

В продажах быстрые победы часто связаны не с «новой стратегией», а с дисциплиной этапов:

ясный критерий выхода этапа

обязательный шаг, который убирает зависание

стандартный артефакт (шаблон письма, структура КП)

минимальный SLA и контроль next step

Критерии хорошей быстрой победы

запускается без реорганизации и без изменений продукта

измеряется в пределах 1–2 недель

улучшает один конкретный симптом в рамках выбранного участка

не требует «сделать идеально», достаточно сделать одинаково

Чем быстрые победы опасны

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

1 быстрая победа, которая улучшает симптом сейчас

1 ставка, которая закрывает корневую причину (возможно, в несколько шагов)

Практический сценарий приоритизации в конце воркшопа

Ниже — компактный сценарий на 20–35 минут, который хорошо встраивается в воркшопы по узкому месту.

Шаг: привести все идеи к одному формату

Сначала убедитесь, что вы сравниваете сравнимое. Каждая идея должна быть записана как эксперимент:

что меняем (правило/шаг/артефакт)

где в воронке (этап или переход)

на какой срок тест (обычно 1–2 недели)

какая метрика и где смотрим

кто владелец

Шаг: impact-effort для первичного отсечения

Цель — быстро убрать «не делаем сейчас» и подсветить «быстрые победы».

Результат шага — 3–6 кандидатов.

Шаг: ICE для выбора 1–2 запусков

Цель — выбрать 1–2 эксперимента, которые команда реально потянет, и по которым высока уверенность.

Фиксация результата:

победители ICE идут в работу

проигравшие, но важные — в бэклог (с пометкой, что повысит confidence или ease)

Шаг: определить definition of done и дату обзора

Чтобы решение не стало «намерением», зафиксируйте:

что считается выполнением (например, «в 100% сделок на этапе КП заполнено поле next step и дата»)

когда смотрим результат (например, через 10 рабочих дней)

Пример: приоритизация решений для узкого места «КП зависают»

Симптом из диагностики: сделки на этапе «КП» стоят 10+ дней, много исходов «пропали/думают».

Кандидатные эксперименты:

добавить обязательный шаг: перед отправкой КП согласовать с клиентом дату разбора

ввести шаблон письма «КП + next step»

добавить в CRM обязательное поле next_step_date

сделать библиотеку кейсов по сегментам для приложений к КП

внедрить правило: не отправляем КП без подтверждённых критериев выбора

Как это обычно раскладывается:

быстрые победы: шаблон письма, обязательный next_step_date

большие ставки: библиотека кейсов, изменение правил квалификации критериев выбора

Выбор 1–2 экспериментов на две недели может выглядеть так:

Эксперимент A: next_step_date обязателен + контроль руководителя 2 раза в неделю

Эксперимент B: шаблон письма «КП + календарное предложение слота»

А «большую ставку» вы оставляете как следующую итерацию: собрать кейсы, если быстрые победы подтвердят, что проблема действительно в отсутствии управляемого next step.

Частые ошибки приоритизации (и как их нейтрализовать)

Сравнивают идеи разного масштаба: «сделать шаблон» vs «поменять процесс продаж».

- Решение: привести к формату эксперимента на 1–2 недели.

Путают уверенность с авторитетом: «я 10 лет в продажах, значит confidence = 10».

- Решение: confidence привязывать к данным и повторам в сделках.

Занижают effort, чтобы идея победила.

- Решение: отдельно проговорить зависимости и минимальный объём внедрения.

Выбирают слишком много.

- Решение: лимит 1–2 эксперимента на цикл, остальное в бэклог.

Не назначают владельца и дату обзора.

- Решение: без владельца и ревью эксперимент не считается выбранным.

Итог

Приоритизация — это мост между «мы всё обсудили» и «мы реально улучшили участок воронки».

impact-effort помогает быстро выделить быстрые победы и убрать лишнее

ICE помогает честно выбрать 1–2 эксперимента, учитывая влияние, уверенность и простоту запуска

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

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

План внедрения: процессы, скрипты, инструменты, обучение

После воркшопа у вас уже есть самое ценное: согласованная проблема, выбранные 1–2 эксперимента, владельцы, метрики и понятные рамки (сегмент, канал, участок воронки). Теперь главный риск — «мы договорились, но ничего не изменилось».

Внедрение в продажах — это не разослать документ. Это добиться повторяемого поведения в реальных сделках. Почти всегда для этого нужно одновременно подкрутить четыре слоя:

процесс (что считается сделанным и когда сделка двигается дальше)

скрипты и формулировки (как именно мы ведём разговор)

инструменты (CRM, шаблоны, автоматизация)

обучение и менеджерский контур (чтобы новая практика закрепилась)

!Четыре слоя внедрения, которые переводят решения воркшопа в устойчивое поведение

Что считаем внедрением: критерий, который снимает споры

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

Удобное правило:

эксперимент считается внедрённым, если выполнены условия применения (adoption) и вы получили первые наблюдения по метрикам (effect)

Примеры условий применения:

в 90% новых сделок на этапе «КП» заполнено поле next_step_date

в 80% звонков по квалификации заданы 5 обязательных вопросов

в 100% передач пресейлу заполнен минимальный пакет информации

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

доля сделок без активности 7 дней на этапе «КП» снизилась

среднее время этапа стало меньше

вырос переход на следующий этап

Каркас внедрения: один план на одну итерацию

Не пытайтесь внедрять «всё сразу». Рабочая единица — итерация внедрения на 1–2 недели вокруг выбранного узкого места.

Шаблон плана внедрения (на 1–2 недели)

| Блок | Что фиксируем | Выходной артефакт | |---|---|---| | Цель | Какой симптом уменьшаем | 1 строка с симптомом и метрикой | | Изменение поведения | Что продавец должен делать иначе | 2–4 конкретных действия | | Процесс | Какие критерии/шаги/стыки меняем | Обновлённый «паспорт этапа» или чек-лист | | Скрипты/материалы | Какие формулировки и шаблоны добавляем | Скрипт, письмо, структура КП | | Инструменты | Что меняем в CRM/автоматизации | Поле, обязательность, дашборд | | Обучение | Как доводим до навыка | 30–60 минут + 1–2 ролевые | | Контроль и поддержка | Как менеджер проверяет применение | Правило ревью + частота | | Ревью результата | Когда смотрим эффект | Дата + кто присутствует |

Этот план удобно заполнять тем же составом, что участвовал в воркшопе: это сохраняет доверие и чувство справедливости.

Процессы: меняем правила этапа, а не «настроение команды»

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

Что именно подкручивать в процессе

критерии выхода этапа

- что должно быть подтверждено, чтобы сделка двигалась дальше

обязательные действия

- 2–5 шагов, без которых этап «не отработан»

минимальные артефакты

- что должно остаться в системе: поля CRM, письмо, документ

стыки и передачи

- кто кому передаёт, какой минимальный пакет информации, внутренний SLA

Как внедрять процесс без сопротивления

Оставьте названия этапов CRM как есть на первой итерации

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

Формулируйте изменения как помощь продавцу

> «Мы не добавляем бюрократию. Мы убираем зависания и размытые ожидания, чтобы сделки двигались предсказуемо»

Мини-чек-лист «процесс готов к внедрению»

критерий выхода можно проверить по факту (не «клиент заинтересован», а «согласован следующий шаг с датой»)

шаги выполнимы при текущей нагрузке

зависимости от других команд описаны (кто и когда подключается)

есть владелец процесса (обычно руководитель продаж или enablement)

Скрипты и материалы: стандартизируем минимум, который даёт эффект

Скрипт в этом курсе — не «прочитай по бумажке», а стандарт полезных формулировок и вопросов, которые повышают качество этапа.

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

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

- например, для квалификации: цель, контекст, роль ЛПР, критерии выбора, срок

подготовьте формулировки next step

- как переводить разговор в конкретный шаг и дату

сделайте шаблоны писем под стык этапов

- например, «КП + договорённость о разборе»

Правило качества для скрипта

Скрипт считается готовым, если он отвечает на три вопроса:

когда применять (этап, ситуация)

что обязательно сказать/спросить (3–7 пунктов)

какой артефакт должен остаться (заметка, поле, письмо)

Как не превратить скрипты в контроль

оставьте «вариативную часть»

- обязательны вопросы и цели, а не дословный текст

используйте примеры из реальных выигранных сделок

- это снижает сопротивление: «так у нас уже работает»

Инструменты: убираем трение и делаем поведение «по умолчанию»

Инструменты нужны не ради автоматизации, а чтобы правильное действие стало самым простым.

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

обязательные поля на этапе

- next_step_date, next_step_type, decision_criteria

шаблоны активностей

- «КП отправлено → назначить разбор», «после демо → письмо с итогами»

быстрые шаблоны писем и документов

- структура КП, письмо-резюме встречи

дашборд здоровья этапа

- доля сделок без активности N дней, среднее время этапа, конверсия перехода

интеграции, которые уменьшают ручной труд

- запись звонков, автологирование писем (в зависимости от стека)

Принцип внедрения инструментов

сначала минимальное изменение, которое поддерживает эксперимент

потом масштабирование и «красота»

Если данных в CRM не хватает, зафиксируйте это как отдельную задачу из «парковки тем» и не смешивайте с текущей итерацией.

Обучение: переводим изменения в навык, а не в презентацию

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

Формат обучения для внедрения эксперимента

Короткий бриф (15–20 минут)

- что меняем, зачем, где в воронке, как измеряем

Разбор примеров (10–15 минут)

- 1–2 фрагмента звонка или письма: как было и как должно быть

Ролевые (20–30 минут)

- отработка нового поведения на типовом кейсе

Применение в реальных сделках (1–2 недели)

Коучинг менеджера

- выборочно: 2–3 сделки на человека, фокус на новом шаге

Кто должен учить

владелец эксперимента отвечает за смысл и правила

руководитель продаж отвечает за применение и коучинг

RevOps или администратор CRM отвечает за поля, шаблоны и отчёты

Если менеджерский контур отсутствует, внедрение почти всегда «растворяется». Тогда лучше уменьшить масштаб эксперимента.

Контроль без токсичности: как проверять применение и не разрушить доверие

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

Рабочие механики контроля

ежедневный или через день быстрый просмотр этапа в CRM

- 10 минут: сделки без next_step_date, сделки без активности

выборочная проверка качества

- 2–3 звонка/письма в неделю на команду, только по новому стандарту

общая доска внедрения

- что запущено, где стоп-факторы, что в парковке

Язык контроля

вместо «почему не сделал?» → «что помешало применить и как убрать препятствие?»

вместо «у тебя плохо» → «в системе нет условия, чтобы это делалось по умолчанию»

Масштабирование: пилот, затем расширение

Чтобы не взорвать процесс, применяйте простую стратегию масштабирования.

Пилот на небольшой группе или на одном сегменте

Сбор обратной связи и исправление трения

Масштабирование на всю команду

Признаки, что можно масштабировать:

понятно, как измерять применение

инструменты не ломают работу

продавцы признают, что новая практика экономит время или повышает качество

!Простой роадмап внедрения от пилота до решения по закреплению

Как проводить ревью: закрепляем, повторяем или откатываем

Ревью — это встреча на 30–45 минут через 1–2 недели после старта. Она нужна, чтобы честно закрыть цикл эксперимента.

Повестка ревью

Применение

- делали ли мы то, о чём договорились (по данным CRM и примерам сделок)

Эффект

- что стало с симптомом на выбранном участке

Трение и корректировки

- что мешало применять

Решение

- закрепляем как стандарт, повторяем с правками или откатываем

Решение фиксируйте письменно: это экономит время и снижает повторные споры.

Пример плана внедрения: «КП отправляем только с согласованным разбором»

Ниже пример, как один эксперимент раскладывается на четыре слоя.

| Слой | Что делаем | Как проверяем | |---|---|---| | Процесс | На этапе «КП» выходной критерий: согласован next_step и дата разбора КП | Доля сделок на «КП» с заполненными полями | | Скрипт/материалы | Шаблон письма «КП + предложение слота + вопрос о критериях выбора» | Выборка писем и исходов | | Инструменты | В CRM обязательные поля next_step_date и next_step_type на этапе «КП» | Отчёт по незаполненным | | Обучение | 30 минут: разбор примеров + 2 ролевые «отправка КП» | Менеджерский коучинг по 2 сделкам |

Ключевой момент: команда видит, что вы не «давите» на людей, а проектируете систему, которая делает правильное действие естественным.

Итог

Воркшопы дают решения, но союз с командой закрепляет именно внедрение: спокойное, измеримое и ограниченное рамками.

Если вы после каждого воркшопа проводите одну итерацию внедрения на 1–2 недели и закрываете её ревью, у команды формируется доверие к процессу:

обсуждение превращается в изменения в сделках

изменения измеряются и корректируются, а не навязываются

продавцы становятся соавторами улучшений, а не объектом контроля

Закрепление результата: метрики, ретро, культура улучшений

После воркшопа и итерации внедрения (процесс, скрипты, инструменты, обучение) самая частая ошибка — считать, что улучшение само закрепится. В продажах новые практики «растворяются», если их не поддержать:

метриками, которые показывают применение и эффект

регулярным разбором результатов (ретро)

культурой улучшений, где команда чувствует себя соавтором системы, а не объектом контроля

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

!Цикл, который превращает воркшоп в устойчивое улучшение

Что значит «закрепить результат»

Закрепление — это не «всем понравилось» и не «разослали регламент». Закрепление — это когда выполняются три условия:

Применение стало стабильным: команда реально использует новую практику в большинстве подходящих сделок.

Эффект измерим: симптом на выбранном участке воронки изменился (или честно не изменился).

Знание стало стандартом: есть короткое описание правила и артефактов, встроенное в работу (CRM, шаблоны, чек-листы, коучинг).

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

Метрики закрепления: что измерять, чтобы не ругаться

Чтобы метрики не превращались в конфликт, разделите их на три слоя.

Метрики применения

Они отвечают на вопрос: делаем ли мы то, о чём договорились.

Примеры:

доля сделок на этапе, где заполнено поле next_step_date

доля сделок, где отправлено письмо-шаблон (или прикреплён нужный артефакт)

доля звонков, где зафиксированы обязательные вопросы квалификации (через чек-лист или заметку)

Почему это важно: без применения невозможно честно судить об эффекте. И наоборот — проверка применения воспринимается спокойнее, чем «почему конверсии нет».

Метрики эффекта на участке воронки

Они отвечают на вопрос: стал ли выбранный участок работать лучше.

Примеры:

конверсия перехода между этапами

среднее время на этапе

доля сделок без активности N дней

доля проигрышей по конкретной повторяющейся причине (если причина фиксируется достаточно качественно)

Метрики устойчивости

Они отвечают на вопрос: не откатились ли мы через 3–6 недель.

Примеры:

применение держится на уровне X% без «ручного подталкивания»

новый стандарт встроен в CRM (поля, обязательность, шаблоны активностей)

менеджерский контур поддерживает практику в регулярном коучинге

Как выбрать 1–3 метрики, чтобы они помогали, а не душили

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

Критерии хорошей метрики в воркшопах по воронке:

привязана к рамкам: сегмент, канал, конкретный этап или переход

измеряется одинаково: минимально зависит от трактовок

управляема командой: на неё можно повлиять действиями продавцов и руководителя

Практический шаблон выбора набора метрик:

| Тип | Выберите по 1 | Пример | Риск, если нет | |---|---|---|---| | Применение | 1 метрика | % сделок с next_step_date | Спор «не работает», хотя никто не делал | | Эффект | 1 метрика | доля сделок без активности 7 дней | Непонятно, стало ли лучше | | Устойчивость | 1 метрика (по желанию) | применение через 4 недели | Откат после пилота |

Лидирующие и запаздывающие метрики: зачем обе

В продажах «итоговые» цифры часто меняются медленно и с шумом.

Запаздывающие метрики показывают результат с задержкой (например, конверсия в оплату).

Лидирующие метрики показывают поведение, которое должно привести к результату (например, наличие согласованного next step, скорость реакции на лид).

Для закрепления берите минимум одну лидирующую метрику применения и одну метрику эффекта.

Мини-дашборд узкого места: один экран, который снижает споры

Чтобы не превращать ревью в «войну Excel», соберите один простой дашборд (или таблицу), где видно:

рамки: сегмент, канал, участок воронки, период

применение: одна метрика

эффект: одна метрика

список сделок-исключений: 5–15 примеров, которые объясняют цифры

Правило: дашборд нужен не для контроля людей, а для контроля узкого места.

Ретро: как закрывать цикл улучшений без токсичности

Ретро (retrospective) — это короткая встреча, которая отвечает на вопрос: что мы узнали и что делаем дальше.

Если вам нужен внешний ориентир по формату, можно посмотреть понятие ретроспективы в Scrum: Sprint retrospective#Sprint_retrospective).

Когда проводить ретро

Рабочий ритм для продаж:

первое ретро через 1–2 недели после старта эксперимента

второе ретро через 3–6 недель (проверка устойчивости)

Если цикл сделки длинный, на первом ретро вы чаще оцениваете применение и промежуточные эффекты (скорость, зависания, качество next step), а не финальную оплату.

Состав участников

Минимально:

владелец эксперимента

руководитель продаж (или тимлид)

2–4 представителя фронта (кто реально применял)

владелец данных/CRM (если были изменения в полях/отчётах)

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

Структура ретро на 30–45 минут

Напомнить рамки и стандарт

Применение

Эффект

Разбор примеров сделок

Решение

Следующие шаги и владельцы

Ключ: ретро — это не «отчёт» и не «разбор полётов», а управленческое завершение эксперимента.

Протокол ретро: вопросы, которые держат фокус на системе

Чтобы обсуждение не ушло в персоналии, используйте одинаковые вопросы каждый раз.

Блок «Применение»

В скольких сделках стандарт реально применили?

Где не применили и почему: не успели, не поняли, не было условий, сопротивлялся клиент?

Какие препятствия в системе мешали применять (CRM, нехватка шаблонов, сложный стык, нагрузка)?

Блок «Эффект»

Что стало с симптомом на участке (метрика эффекта)?

Какие сделки подтверждают улучшение?

Какие сделки противоречат гипотезе?

Блок «Решение»

Закрепляем как стандарт?

Повторяем с правками?

Откатываем и берём следующую гипотезу?

Решение по итогам ретро: три исхода, которые сохраняют доверие

Чтобы команда не чувствовала «нас погоняли и забыли», фиксируйте один из трёх исходов.

| Исход | Когда выбирать | Что фиксируем | |---|---|---| | Закрепить | Применение высокое и эффект есть | Новый стандарт этапа, обновление CRM/шаблонов, правило контроля | | Повторить с правками | Применение частичное или эффект неоднозначный | Что меняем в эксперименте, ещё 1 цикл, новая дата ретро | | Откатить | Применение было, эффекта нет | Что выучили, какую гипотезу закрыли, что пробуем дальше |

Откат — не поражение. Это сигнал, что причина была другой или изменение было недостаточным.

Как превратить «эксперимент» в стандарт

Стандарт в этом курсе — это не «регламент на 20 страниц». Это минимальный набор, который делает поведение повторяемым.

Минимальный пакет стандарта

обновлённый паспорт этапа (цель, вход/выход, обязательные шаги)

1–2 шаблона (письмо, структура КП, чек-лист звонка)

поддержка в CRM (поля, обязательность, шаблоны активностей, отчёт)

правило менеджерского контроля (частота и формат)

Где стандарт должен «жить»

в CRM: чтобы действие было «по умолчанию»

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

в рутине менеджера: разбор 2–3 сделок в неделю с фокусом на стандарт

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

Культура улучшений появляется не от лозунгов, а от повторяющегося опыта:

обсуждение безопасно

решения выбираются прозрачно

внедрение поддерживается инструментами

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

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

Принципы культуры улучшений в продажах

Система важнее героизма: ценится повторяемость, а не «дожали чудом».

Данные и примеры сделок важнее мнений: спор превращается в проверку.

Маленькие циклы лучше больших реформ: 1–2 эксперимента за цикл.

Продавец — соавтор: лучший источник улучшений — фронт.

Ритуалы, которые делают улучшения привычкой

Достаточно 2–3 ритуалов, чтобы процесс не умер:

еженедельный 15-минутный просмотр метрики применения и списка исключений

раз в 2 недели ретро по эксперименту

раз в месяц «карта узких мест» на уровне команды: что улучшили, что болит дальше

Типовые ловушки закрепления (и как их обходить)

Смотрим только на итоговую выручку

- Лекарство: добавьте метрику применения и метрику эффекта на участке.

Стандарт существует в документе, но не в CRM

- Лекарство: встроить минимум в поля/шаблоны/дашборд.

Ретро превращается в оценку людей

- Лекарство: обсуждать только применение стандарта и препятствия в системе.

Слишком много изменений одновременно

- Лекарство: лимит 1–2 эксперимента на цикл и короткий пакет стандарта.

Итог

Закрепление результата — это третий компонент союза с командой после воркшопа и внедрения:

метрики показывают применение, эффект и устойчивость

ретро закрывает цикл без обвинений и превращает спор в обучение

культура улучшений делает изменения инициативой команды, а не «оптимизацией сверху»

Если вы повторяете цикл «воркшоп → внедрение → метрики и ретро → стандартизация», воронка начинает улучшаться как система, а команда продаж становится вашим постоянным партнёром в этих улучшениях.