Демо продукта нейросеть помогает подготовить за один вечер: сценарий под боли клиента, вероятные вопросы и план на случай технического сбоя. Модель под задачу стоит подбирать по типу клиента вместо личных предпочтений менеджера.
Этапы подготовки
Подготовка демо держится на пяти этапах: контекст о клиенте, сценарий по болям, заготовленные ответы на вероятные вопросы, тайминг и план на случай технического сбоя. Модель закрывает черновик всех пяти за один заход, если получает контекст о клиенте заранее.
- Сбор контекста о клиенте — отрасль, размер команды, что уже пробовали до вас.
- Сценарий демо, выстроенный вокруг болей клиента вместо полного списка функций продукта.
- Заготовленные ответы на три-четыре вероятных вопроса про цену, интеграции и сроки.
- План по времени — сколько минут отводится на каждый блок демо.
- План на случай технического сбоя — что показать, если платформа клиента недоступна.
Контекст о клиенте стоит собирать из брифа отдела продаж и вдобавок из открытых источников — сайта компании, вакансий, недавних новостей: это даёт модели материал для более точных примеров в сценарии демо, привязанных к реальной ситуации клиента вместо абстрактного описания отрасли.
План на случай технического сбоя стоит готовить заранее вместо того, чтобы придумывать его во время самого демо: короткая запись экрана, несколько скриншотов ключевых шагов и заготовленная фраза о переносе живого показа на другое время снимают панику у всей команды на встрече.
Заготовленные ответы на вероятные вопросы стоит формулировать с конкретными цифрами там, где это возможно — сроком внедрения в конкретных неделях вместо расплывчатого «быстро», и ценой диапазоном по тарифу вместо общей фразы «обсуждается индивидуально» для всех подряд.
Модель под клиента
- Для крупного корпоративного клиента со сложным продуктом — Claude или ChatGPT: они точнее держат структуру сценария на несколько блоков подряд.
- Для небольшой компании с типовым запросом — GigaChat или YandexGPT: черновик сценария готов быстрее и обходится дешевле по токенам.
- Для отраслевого клиента со специфичной терминологией — модель, которой заранее передали глоссарий отрасли вместо общего промпта без контекста.
Отдельный случай — демо для клиента, который уже пользуется похожим продуктом конкурента: здесь модели полезно заранее назвать конкретные отличия от конкурента вместо того, чтобы просить её самой догадываться о рынке.
Разница между моделями заметнее всего на этапе адаптации одного и того же базового сценария под несколько демо подряд за один день — здесь на первом месте скорость, с которой модель перестраивает уже готовый сценарий под нового клиента без потери структуры, а мощность модели тут вторична.
Ещё один практический приём — держать одну и ту же базовую версию сценария в двух вариантах длины: полную на сорок минут и сокращённую на пятнадцать, если у клиента внезапно осталось меньше времени. Модель готовит оба варианта параллельно почти без дополнительных затрат по токенам.
Репетиция
- Прогоните сценарий вслух и засеките реальное время каждого блока.
- Попросите модель раскритиковать сценарий по ролям — как скептичный технический директор и как экономящий бюджет финансист.
- Сократите блок, если он выходит за отведённое время больше чем на треть.
- Подготовьте короткий запасной сценарий на пять минут — на случай, если у клиента останется меньше времени, чем планировалось.
- Запишите репетицию на видео и пересмотрите её на следующий день свежим взглядом — за один прогон легко пропустить лишние паузы и слова-паразиты, которые видны только со стороны.
Разобрать сценарий вашего следующего демо?
Отдельная репетиция нужна и для перехода между блоками демо — именно на стыках менеджеры чаще всего теряют темп, повторяются или забывают, к какому пункту вернуться после ответа на внезапный вопрос клиента.
Что проверять руками
- Реальные цифры и кейсы, которые приводит сценарий — модель может опять взять устаревшую версию.
- Соответствие сценария тому продукту, который клиент увидит в демо-доступе именно сегодня.
- Формулировки про сроки внедрения — сверить с текущей загрузкой команды внедрения.
- Естественность переходов между блоками при чтении вслух.
- Список участников со стороны клиента — сценарий стоит в первую очередь адресовать роли, которая реально принимает решение, а технического специалиста держать во внимании отдельно.
Список актуальных цен и скидок стоит держать в одном источнике, синхронизированном с отделом продаж, — модель без доступа к этому источнику использует те цифры, что были в последнем переданном ей документе, даже если с тех пор прайс уже менялся несколько раз.
Полезно держать отдельный список вопросов, на которые сценарий пока честно отвечает «уточним и вернёмся» вместо выдуманного ответа, — клиенты обычно относятся к такому ответу спокойнее, чем к красивой, но позже опровергнутой формулировке.
Отдельно стоит сверять терминологию продукта с той, которой пользуется сам клиент в своих внутренних документах и переписке, — модель по умолчанию использует термины из общей презентации компании, и разница в словах иногда мешает клиенту опознать в демо решение именно его задачи.
Граница ответственности
Условный пример, знакомый многим командам: сценарий демо обещает интеграцию, которая всё ещё в разработке, потому что модель взяла список функций из презентации шестимесячной давности.
Разберём случай, который обычно упускают из виду до самого демо: сценарий ссылается на интеграцию, доступную только в версии для энтерпрайз-тарифа, а у конкретного клиента на встрече — базовый тариф; клиент фиксирует в блокноте функцию, которая ему недоступна, и на следующей встрече с закупкой всплывает несостыковка условий.
Актуальность списка функций и интеграций проверяет менеджер вместе с продуктовой командой перед каждым крупным демо — у модели нет доступа к изменениям в дорожной карте продукта между релизами.
Второй частый случай — сценарий демо ссылается на кейс другого клиента отрасли, который по факту остаётся пилотом, ещё далёким от завершённого внедрения; такие ссылки стоит помечать точным статусом вместо того, чтобы выдавать пилот за готовый результат.
Как обучить команду такой проверке — в разделе про обучение сотрудников работе с ИИ.
Похожая подготовка к встрече с клиентом — в статье про подготовку к переговорам о скидке и в материале про план работы с ключевым клиентом. Общий разбор роли нейросетей в отделе продаж — в статье про нейросети для отдела продаж.
Третий момент — вопросы про совместимость с незнакомыми модели системами клиента: список конкретных интеграций стоит сверять с инженерной командой до демо вместо обещания совместимости на основе общих предположений о рынке.