SaaS 产品演示视频不是把功能菜单依次录下来，而是让目标客户看懂：自己要完成什么任务、在哪个界面采取什么动作、最终能看到什么结果。脚本从客户任务出发，才能同时约束产品事实、销售重点和录屏范围。
下面的模板适用于官网产品演示、销售跟进视频、单功能答疑和 onboarding 片段。示例只说明写法；实际功能名称、界面路径、数据与限制条件必须由产品负责人确认。
先定义客户任务，再决定镜头里出现什么
把 Brief 的第一句写成一个可以观察的任务，例如“销售经理从活动报名中筛出需要跟进的线索”，而不是“介绍平台能力”。随后补齐三个边界：
- 起点：用户进入任务前处于什么页面或状态；
- 动作：用户必须完成哪些点击、输入、筛选或确认；
- 结果：画面中能直接看见什么变化，哪些结论仍需旁白解释。
不能服务同一任务的功能不要硬塞进主片，可以留给答疑短片、销售定制版或帮助中心内容。
用功能筛选表决定哪些内容进入主线
| 判断项 | 脚本必须回答 | 不通过时的处理 |
|---|---|---|
| 客户任务 | 该功能是否推动同一个具体目标？ | 移到另一条专题视频。 |
| 完整动作 | 入口、操作和结果能否在镜头中连续呈现？ | 补录路径，或改为静态说明。 |
| 可见证据 | 结果是画面可见，还是只能靠旁白声称？ | 补状态变化、来源或限制条件。 |
| 异议价值 | 它是否回答客户真实的使用疑问？ | 放入销售跟进版或 FAQ。 |
| 版本复用 | 裁成短版或静音版后是否仍能看懂？ | 补首帧、字幕或独立结果镜头。 |
筛选表的作用是控制信息密度：功能数量不是完成度，能让观众理解任务路径才是。
把任务写成“界面—动作—证据”分镜卡
| 栏位 | 示例写法 | 确认人 |
|---|---|---|
| 目标角色 | 负责活动线索跟进的销售经理 | 销售负责人 |
| 界面入口 | 活动列表中的筛选入口 | 产品经理 |
| 操作动作 | 按已确认的条件筛选并保存视图 | 产品经理与录屏执行 |
| 可见结果 | 结果列表、数量与下一步动作同时出现 | 产品经理 |
| 旁白或字幕 | 解释该动作解决哪一步判断 | 品牌或销售 |
| 限制条件 | 演示数据为脱敏样本，不代替真实客户结果 | 品牌或法务 |
| 版本出口 | 官网主片、销售短版、静音字幕版保留哪些段落 | 制片人 |
每张卡只承担一个任务节点。录屏时把入口、动作与结果分别录成可验收段落，后期才有足够空间调整节奏和版本。
录屏前锁定账号、数据与界面版本
脚本确认后，还需要一张录屏准备清单，避免在剪辑阶段发现账号缺权限、界面已改版或数据不能公开。
- 确认演示账号、角色权限和登录方式；
- 准备脱敏数据，并记录哪些字段不能出镜；
- 锁定录制日期、产品版本、浏览器与屏幕比例；
- 关闭通知、个人信息和无关标签页；
- 先录完整流程，再补光标强调、局部放大和备用近景；
- 由产品负责人核对名称、路径、状态与限制条件。
界面强调动效应服务于同一动作，不要用缩放和高亮掩盖路径缺失。
按观看场景拆分版本，不要把所有信息拉成长片
| 版本 | 核心任务 | 保留内容 |
|---|---|---|
| 官网主片 | 让陌生访客快速理解产品如何工作 | 核心任务、主要动作、结果与下一步 |
| 销售跟进版 | 回答已提出的功能或流程异议 | 更完整的路径、限制条件和使用语境 |
| 单功能答疑 | 回答一个高频问题 | 问题首帧、完整动作、简短结论 |
| Onboarding 片段 | 帮助用户完成第一次成功操作 | 入口、步骤、结果与常见错误 |
版本矩阵至少记录时长、画幅、声音依赖、字幕、界面版本、CTA 和批准人。母版与各渠道版本分别签收，避免把一条成片简单裁切后用于所有场景。
用三轮验收分开产品事实、画面证据与创意节奏
- 事实轮：核对入口、功能名称、演示数据、权限和限制条件；
- 证据轮：检查不依赖旁白时，观众能否看懂动作与结果；
- 表达轮：最后再评估首帧、节奏、音乐、字幕与 CTA。
如果一个功能需要多段旁白，却没有任何可见结果，应回到筛选表：删除、拆片，或补录真实界面证据。可参考 HubSpot 的视频脚本方法与 Shopify 的产品演示指南，但最终脚本仍须以当前产品事实和项目验收口径为准。
SaaS 产品演示视频脚本常见问题
一条演示视频应该放多少个功能？
没有固定数量。先确定一个客户任务，只保留完成任务所需的功能；其他能力拆成销售版或单功能视频。
录屏和旁白应该先做哪一个？
先确认任务、界面路径与可见结果，再写旁白。界面动作发生变化时，优先更新分镜卡和事实口径。
界面频繁更新，怎样降低返工？
记录录制版本与日期，把入口、动作、结果拆成独立段落，并保留无旁白的干净录屏，便于局部替换。
