Готовый сценарий
Правило demo
Показывайте не всё, что умеет продукт, а минимальный набор capabilities, который доказывает решение важной проблемы.
Пример сцены
«Вы говорили, что forecast обновляется только раз в неделю. Представим понедельник: система уже собрала изменения из CRM и звонков, выделила сделки с высоким risk и объяснила причины. Что из этого сейчас вы делаете вручную?»
После demo
- Зафиксировать confirmed value.
- Записать новые objections.
- Обновить opportunity qualification.
- Отправить agreed proof.
- Согласовать следующий decision milestone.
Когда шаблон особенно полезен
Используйте шаблон, когда сделка требует нескольких согласующих, business case, расчётов, procurement или передачи контекста между Sales, Solutions и руководством. Для простой транзакционной продажи достаточно минимальной версии. Чем выше ACV, длиннее sales cycle и сложнее buying committee, тем важнее фиксировать evidence, assumptions и decision process.
Как внедрить шаблон в рабочий процесс
- Используйте шаблон на реальной сделке, opportunity или коммерческом кейсе, а не на абстрактном «среднем клиенте».
- Согласуйте определения с CRM и sales stages, чтобы данные в документе совпадали с тем, что видят Sales, RevOps и руководство.
- Проверяйте ключевые цифры и assumptions вместе с владельцем данных: Finance, Sales Ops, Solutions, Customer Success или самим клиентом.
- Отделяйте доказанный факт от sales hypothesis. Если значение не подтверждено, укажите диапазон, источник и уровень уверенности.
- После закрытия сделки, проигрыша или изменения процесса переносите новые знания обратно в шаблон, чтобы он не оставался статичным.
Практический пример
Перед demo продавец фиксирует use case и success criteria. Вместо экскурсии по меню он показывает три сцены, каждая из которых доказывает конкретный outcome, затем проверяет relevance вопросом.
Что должно получиться на выходе
Результат работы с шаблоном «Сценарий демонстрации продукта» — не заполненная форма сама по себе, а согласованный рабочий артефакт, который можно использовать для решения, передачи контекста и последующей проверки результата. У документа должны быть понятны владелец, исходные данные, допущения, дата актуальности и следующий шаг. Если эти элементы невозможно определить, полезнее сократить документ до минимальной версии и вернуть недостающие данные, чем заполнять поля формально.
Проверка качества перед использованием
- Документ применим к конкретной opportunity, а не написан «для всех».
- Финансовые цифры и assumptions можно проверить.
- Следующий шаг, owner и decision milestone однозначны.
- Не скрываются ограничения, gaps и зависимости.
- Информация обновляется после win/loss, procurement или изменения commercial terms.
Как поддерживать шаблон в актуальном состоянии
Обновляйте артефакт при изменении sales process, pricing, procurement, конкурентной среды и после накопления новых win/loss данных. Для часто используемых материалов разумен ежемесячный или квартальный review.
Частые вопросы (FAQ)
Нужно ли показывать документ клиенту?
Не всегда. Часть шаблонов — внутренняя рабочая модель, а часть может стать customer-facing deliverable. Главное — не переносить внутренние assumptions в внешний документ как доказанный факт.
Как избежать ложной точности?
Используйте диапазоны, sensitivity и ссылки на источник. Если цифра основана на предположении, это должно быть видно.
Когда шаблон считается устаревшим?
Когда изменились pricing, sales stages, procurement, product scope или типичная buying process, а документ продолжает использовать старую логику.