Демо продукта для клиента: сценарий и чек-лист
Что такое демо продукта для клиента?
Демо продукта для клиента — это показ одного значимого рабочего сценария в заранее проверенной среде. У каждого утверждения о клиенте есть основание: наблюдение, датированная заметка discovery или прямое подтверждение. Гипотезы остаются вопросами, а после встречи фиксируются поправки, неизвестные данные и согласованный следующий шаг.
TL;DR
- -Покажите одну задачу клиента целиком вместо экскурсии по всем функциям
- -Отделите наблюдения и слова клиента от гипотез и неизвестных данных
- -Проверьте версию продукта, аккаунт, права, данные, интеграции и запасной вариант
- -Остановите заготовленный сценарий, если клиент поправил вводные или среда изменилась
- -До обновления CRM запишите подтверждения, поправки, вопросы, ответственных и даты
Плохое демо продукта начинается не с зависшего экрана. Оно начинается раньше, когда продавец превращает несколько заметок discovery в уверенный рассказ о клиенте. В заметках было «часть заявок приходит по почте», а в сценарии уже появляется «команда теряет часы на ручной обработке и срочно ищет автоматизацию».
Первая же поправка клиента ломает весь подготовленный маршрут. Если поправки не прозвучало, риск ещё выше: встреча проходит гладко, но участники расходятся с разным пониманием проблемы, возможностей продукта и следующего шага.
Надёжный сценарий устроен проще. Возьмите одну задачу клиента, проверьте основания для каждого утверждения, отрепетируйте реальную среду и сохраните все поправки. Для этого можно скачать run sheet демо продукта с чек-листом и отдельно отмеченным вымышленным примером.
Сначала определите результат встречи
Одна встреча редко может одновременно заменить продажную презентацию, обучение, техническую проверку и воркшоп по внедрению. До подготовки экранов запишите, какое решение она действительно способна поддержать.
В начале run sheet нужны:
- компания клиента, участники и их роли;
- решение или следующий шаг, для которого проводится встреча;
- один рабочий сценарий;
- темы, сознательно оставленные за рамками;
- ведущий и человек, который фиксирует вопросы.
Если специалист по безопасности проверяет разграничение доступа, обзор красивого дашборда не отвечает его задаче. Если руководителю операций важно увидеть обработку исключения, идеальный happy path не даст ему нужных оснований для решения.
Не обещайте, что показ «докажет ценность». Демо способно показать наблюдаемое поведение известной версии продукта. Коммерческий результат зависит от процесса, данных, ограничений и внедрения на стороне клиента. На момент встречи часть этих условий может оставаться неизвестной.
Разберите discovery на факты и гипотезы
В одной заметке могут лежать точная цитата, наблюдение автора и его догадка. Если склеить их в один абзац, догадка быстро превращается в «подтверждённую боль».
Удобно использовать четыре статуса:
| Статус | Что за ним стоит | Как использовать на встрече |
|---|---|---|
наблюдение | Проверенный документ, настройка, запись продукта или согласованный пример | Говорить только то, что видно в источнике |
слова клиента | Фраза конкретного участника с датой и ссылкой на заметку | Повторить и спросить, актуально ли это сейчас |
гипотеза | Вывод из неполного контекста | Переформулировать в вопрос |
неизвестно | Подходящего источника нет | Не произносить как факт; при необходимости назначить проверку |
Источником может быть датированная заметка со встречи, согласованный фрагмент процесса или release note продукта. Фраза «модель нашла» источником не является. Память продавца тоже недостаточна, если от точной формулировки зависит весь сценарий.
Строка реестра выглядит так:
Утверждение: заявки выше заданного порога согласуют финансы
Источник: согласованный фрагмент policy, 29 августа 2026
Статус: наблюдение
Формулировка: «В этом примере заявка выше настроенного порога уходит финансовому
согласующему. Для процесса, который мы сегодня разбираем, действует то же правило?»
Документ подтверждает правило маршрутизации. Он ничего не говорит об экономии времени, скорости согласования или готовности команды внедрить процесс.
Сделайте из предположения нормальный вопрос
Гипотезы не обязательно выбрасывать. Они помогают обнаружить пробелы, если не маскировать их под факты.
- Вместо «ваша команда тратит часы на сверку» спросите, какие шаги сейчас требуют ручной сверки.
- Вместо «интеграция уберёт двойной ввод» уточните, где данные вводятся повторно и как клиент собирается проверить изменение.
- Вместо «решение нужно запустить в этом квартале» спросите, какое событие или зависимость определяет график оценки.
Вопрос оставляет место для точного ответа. Категоричное утверждение вынуждает клиента сначала опровергнуть сценарий и только потом вернуться к продукту.
Выберите одну задачу и доведите её до результата
В интерфейсе есть меню, настройки, роли, отчёты, интеграции и десятки крайних случаев. Для одной встречи они не равноценны. Выберите задачу, которую клиент хочет проверить, и покажите путь от знакомого исходного состояния до результата, который можно посмотреть самому.
До подготовки слайдов заполните шесть строк:
- Исходная ситуация: что клиент уже подтвердил.
- Задача: какое действие должен выполнить пользователь.
- Шаги: что будет сделано в продукте.
- Конечное состояние: что изменится на экране.
- Проверяемое свидетельство: что клиент сможет открыть или сверить.
- Неподтверждённая гипотеза: какой вопрос пока остаётся открытым.
В примере с закупками можно создать синтетическую заявку, направить её по тестовому правилу, согласовать и открыть историю решения. Наблюдаемый результат здесь — статус, согласующий, время и запись решения. Фраза «компания станет работать быстрее» из этого показа не следует.
В пакете есть вымышленный заполненный пример. Он объясняет механику шаблона, но не изображает реального клиента и не доказывает бизнес-эффект.
Репетируйте состояние продукта, а не речь
Хорошо выученный текст не спасёт среду с неправильной ролью или устаревшими данными. Перед встречей зафиксируйте:
- версию продукта или релиз;
- аккаунт и набор прав;
- синтетические, обезличенные или согласованные данные;
- доступные интеграции и их конфигурацию;
- ограничения, важные для текущего сценария;
- данные, которые не должны попасть на экран.
По возможности используйте отдельный браузерный профиль. История, превью уведомлений, вывод терминала и карточка другого клиента могут появиться вне основного окна. Это не досадная деталь, а утечка данных.
Пройдите сценарий из чистого исходного состояния. Если он работает только после того, как предыдущая репетиция создала нужную запись, результат нельзя воспроизвести. Проверяйте роль, которую будете показывать. Администраторский аккаунт часто скрывает проблемы с правами, ради которых клиент и пришёл на встречу.
Перед звонком пройдите чек-лист демо: он отдельно проверяет данные, ограничения, запасную среду и формулировки следующего шага.
Соберите одностраничный сценарий показа
Для каждого этапа достаточно пяти колонок:
| Этап | Экран или действие | Подтверждённое утверждение | Вопрос клиенту | Запасной вариант |
|---|---|---|---|---|
| Сверить контекст | Короткая выжимка discovery | Исходная ситуация со слов клиента | «Это по-прежнему так?» | Исправить вводные |
| Показать начало | Синтетическая заявка | Состояние demo-аккаунта | «Что здесь отличается от вашего процесса?» | Согласованный пример |
| Выполнить задачу | Маршрутизация и согласование | Текущее поведение продукта | «Кому нужно проверить это решение?» | Заранее проверенная запись |
| Проверить результат | История решения | Видимый статус и журнал | «Какого свидетельства здесь не хватает?» | Сохранённая синтетическая запись |
| Обсудить границы | Известное ограничение | Текущее ограничение продукта | «Помешает ли это оценке?» | Назначить проверку |
| Зафиксировать шаг | Записи встречи | Подтверждения с текущего звонка | «Кто и к какой дате проверяет дальше?» | Оставить вопрос открытым |
Это не текст для чтения по бумаге. Таблица держит рядом утверждение, вопрос и запасной вариант, чтобы ведущий не начинал импровизировать уверенность при первом сбое.
Заранее определите условия остановки:
- клиент исправил исходные данные;
- нужной интеграции или права нет;
- среда отличается от обещанной версии;
- результат требует неподтверждённой цифры ROI, срока или внедрения;
- на экране появились несогласованные данные.
Остановить заготовку — не значит потерять управление встречей. Продолжить с неверными вводными намного хуже.
Не прячьте сбой live-демо
Запасной вариант нужен, чтобы сохранить разговор, а не создать видимость исправной работы. Подготовьте его для шагов, зависящих от сети, внешнего сервиса, интеграции или хрупкого набора данных.
Подойдут:
- тот же сценарий в проверенном синтетическом аккаунте;
- короткая запись из указанной версии продукта;
- скриншоты с явной подписью;
- сохранённый результат, который можно изучить без недоступной интеграции.
Формулировка может быть такой:
Live-коннектор не вернул ожидаемый результат. Я могу показать репетицию на синтетических данных, но она не подтвердит работу коннектора в вашей среде. Запишем отдельную проверку, ответственного и дату.
Не списывайте сбой на сеть клиента без доказательства. Не переключайтесь молча на видео, продолжая говорить о нём как о текущем результате. Ограничение — важная часть оценки продукта.
Поручите модели разбор, а не вывод
Модель может разобрать длинные разрешённые заметки, если задать узкую задачу и сохранить неопределённость:
Используй только переданные заметки по указанному рабочему сценарию.
Для каждого относящегося к нему утверждения верни:
- короткую точную цитату;
- исходную заметку и дату;
- статус: слова клиента, гипотеза или неизвестно;
- нейтральный вопрос для подтверждения или исправления.
Не исследуй компанию во внешних источниках.
Не придумывай боль, срочность, бюджет, ROI, внедрение и процесс решения.
Не рекомендуй функцию продукта или следующий шаг.
Если точной цитаты нет, поставь статус «неизвестно».
Каждую цитату нужно сверить с исходником. Правдоподобная фраза может оказаться выдуманной, обрезанной или приписанной не тому участнику. Приватные заметки и данные клиента нельзя переносить в инструмент, который не разрешён для их обработки.
После встречи действует та же граница. Модель может предложить структуру записи, но человек проверяет её до отправки письма и обновления CRM. В материале про валидацию action items показано, почему извлечение и внешняя запись должны оставаться разными этапами.
Останавливайтесь после поправки клиента
Фраза «у нас процесс устроен иначе» полезнее первоначальной гипотезы. Остановите показ, запишите поправку словами клиента и только после этого решите, остался ли релевантный подготовленный маршрут.
Хороший ответ состоит из трёх действий:
- признать ошибку во вводных;
- повторить исправление без дополнительных выводов;
- спросить, стоит ли адаптировать текущую встречу или вынести вопрос отдельно.
Не защищайте проведённый ресерч. Не просите модель угадывать настроение собеседника во время звонка. Сохраняйте точную формулировку: она станет основанием для следующей версии сценария.
С возражениями работает тот же принцип. Сначала отделите вопрос о функции продукта от опасения по поводу риска, усилий или внутреннего согласования. Гайд про работу с возражениями через проверяемые данные поможет не генерировать красивый ответ на неправильно понятую проблему.
Завершите встречу точной записью
Следующий шаг полезен только тогда, когда участники его действительно согласовали. Не создавайте искусственную срочность и не назначайте дату за клиента.
Перед завершением вслух проверьте:
- что клиент подтвердил;
- какие вводные он исправил;
- какие технические и коммерческие вопросы остались;
- кто и когда отвечает на каждый обещанный вопрос;
- какой следующий шаг согласован, кто его делает и к какой дате;
- какие материалы нужно отправить после встречи.
Если следующий шаг не появился, так и запишите. Честное «решение не принято» полезнее, чем стадия в CRM, основанная на надежде продавца.
После звонка сравните run sheet с реальной встречей. Удалите утверждения, которые потеряли основание. Запросы на функции перенесите в product process, а не обещайте в follow-up письме. Если сценарий становится командным шаблоном, храните дату и версию.
Цель не в безупречной подаче. Клиент должен ясно видеть, что показал продукт, что пока не проверено и о каком действии стороны договорились на самом деле.