Демонстрация продукта клиенту: сценарий и критерии проверки
Демонстрацию продукта строй вокруг вопроса покупателя и наблюдаемого сценария. После показа участники должны понимать, что именно увидели, в каких условиях и что ещё предстоит проверить. Перечень всех кнопок и положительная реакция зрителей этого результата не заменяют.
В рекомендациях Salesforce по демо предложено выбрать главный вопрос, сфокусировать цель и показать последовательность от задачи к результату. Ниже — собственный рабочий сценарий для B2B-встречи с протоколом. Он не обещает роста продаж и не подтверждает возможности конкретного решения.
Согласуй вопрос до встречи
Вместо «покажем нашу систему» сформулируй: «Как сотрудник передаст обращение нужному специалисту и увидит, что произошло дальше?». Такой вопрос определяет начальное состояние, действия и наблюдаемый результат.
Проверь, что вопрос относится к задаче клиента. Уточни участников: пользователь оценит маршрут работы, руководитель — связь с процессом, технический специалист — ограничения среды. Не обещай ответить за одну встречу на все вопросы покупки. Спорное требование можно вынести на отдельную техническую проверку.
Реплика перед подготовкой: «Чтобы показ был полезен, предлагаем разобрать один согласованный сценарий. Подскажите, кто у вас выполняет эту работу, какие исключения важны и какой результат вы хотите увидеть?».
Подготовь условия и границу показа
Опиши продукт и версию, среду, учебные данные, роли, подготовленные настройки и действия, которые будут выполнены. Если часть маршрута имитируется, объяви это до показа. Презентация, запись и работающая функция должны быть различимы для зрителя.
Не используй реальные персональные или закрытые данные клиента без согласованного основания и способа передачи. Для обычного объяснения маршрута достаточно учебных записей. Если требуется проверка на данных покупателя, это отдельный согласованный сценарий с условиями и критериями.
Прогони маршрут заранее. Подготовь резервную запись или снимки как запасное объяснение, но подпиши их. Если живой сценарий не выполнился, запись не превращает его в выполненный. В протоколе останутся сбой и то, что удалось показать другим способом.
Учебная повестка на 35 минут
Это пример распределения времени, а не универсальная норма.
| Время | Содержание | Проверяемый выход |
|---|---|---|
| 0–5 минут | Уточнение задачи, участников и границ стенда | Все понимают главный вопрос |
| 5–8 минут | Исходная учебная запись и роли | Видны входные условия |
| 8–20 минут | Основной маршрут | Участники наблюдают действия и результат |
| 20–25 минут | Одно значимое исключение | Понятно, как выглядит разбор ошибки |
| 25–30 минут | Вопросы и непроверенные требования | Открытые вопросы записаны |
| 30–35 минут | Сверка вывода и следующего шага | Согласованы дальнейшие действия |
На встрече поясняй переходы: что видит пользователь, какое действие делает и как проверяется результат. Не перескакивай от исходной записи к финальному экрану так, чтобы ключевая операция осталась за кадром.
Полный учебный маршрут
Представим вымышленный интерфейс обработки запросов. Он описан для упражнения и не является заявлением о существующих функциях какого-либо продукта. Все результаты ниже — условные.
- Показать учебный запрос с темой, описанием и назначенным подразделением. Зрители видят, что данные подготовлены заранее.
- Изменить подразделение по согласованному правилу и сохранить запись. Проверить новое значение и доступную историю изменения.
- Открыть запись от имени второй учебной роли. Проверить, что видит получатель; не объявлять проверку всей модели доступа.
- Разобрать исключение: запрос без обязательного для сценария поля. Показать предусмотренную реакцию или честно зафиксировать отсутствие проверки.
- Вернуться к главному вопросу. Сопоставить наблюдение с задачей и выписать оставшиеся условия.
Пример пояснения клиенту: «Сейчас вы видите передачу одной учебной записи между двумя ролями. Реальную интеграцию, права всех пользователей и работу под нагрузкой сегодня не проверяем; эти вопросы записаны отдельно». Это помогает зрителю правильно интерпретировать увиденное.
Протокол: наблюдение, вопрос и предел вывода
| Пункт | Условное наблюдение | Что остаётся открытым |
|---|---|---|
| Изменение назначения | В учебном маршруте значение изменилось после сохранения | Все ли реальные правила клиента учтены |
| Работа второй роли | Запись показана в подготовленной роли | Полная модель прав и безопасность среды |
| Исключение | Реакция разобрана на одной учебной записи | Остальные ошибки и восстановление |
| Передача в другую систему | Не выполнялась | Формат, доступы, ответственность, повторная передача |
| Нагрузка | Не измерялась | Пиковый поток и методика испытания |
Если клиент задаёт вопрос, которого не было в подготовке, не угадывай ответ. Зафиксируй его, определи нужные данные и владельца проверки. Ответ «уточним по документации и вернёмся к согласованной дате» полезнее неподтверждённого обещания.
Чем завершить демонстрацию
Сверь главный вопрос: что понятно, что вызвало сомнение, что не проверено. Следующий шаг может быть техническим разбором, согласованным испытанием, уточнением задачи или отказом от дальнейшего рассмотрения. Посещение демо само по себе не подтверждает покупку.
Скачать повестку, маршрут и протокол демо. Отправляя итог, попроси сверить факты: «Пожалуйста, проверьте, верно ли зафиксированы наблюдения и открытые вопросы». Новые обещания после встречи должны опираться на подтверждённый ответ, а не на впечатление от показа.
Источники и документация
- 5 Simple Steps To Delivering Better Product Demos · проверено 18.10.2026