有研究数据时把客户旅程整理成阶段、触点…

当你已有访谈、问卷或分析等研究信号，需要把客户端到端或某一阶段的体验综合成结构化旅程地图时使用。

适用场景

解决思路

1. 先确认必需输入：目标人群/客户细分（旅程是给谁的）、目标/期望结果（客户想完成什么）、范围（端到端全生命周期，还是聚焦某一阶段如 onboarding、checkout、renewal、support）；可选输入包括访谈综合、问卷结果、客服工单、分析数据、已有旅程地图、需覆盖的特定阶段或触点、线性还是循环旅程类型（默认线性，循环用于重复性互动）。
2. 坚持核心原则：旅程地图是综合产物而非头脑风暴，每个阶段、触点、情绪和痛点都要能追溯到研究输入（访谈、问卷、分析、观察）；没有研究信号时，把条目标注为假设并建议验证研究，拒绝编造情绪或行为数据。
3. 产出 3-5 句的执行摘要：旅程是给谁的、他们想完成什么、最大痛点和机会在哪、最重要的关键时刻是什么。
4. 写一段人物/细分摘要：描述该旅程对应的客户；若已有 persona 则引用，没有则总结关键属性。
5. 明确旅程范围：说明覆盖的阶段/生命周期，并显式列出包含什么、排除什么。
6. 划分 3-7 个命名阶段，每个阶段包含：阶段名（用客户语言的动词形式，如 Discovers、Considers、Tries、Decides、Uses、Renews）、客户在该阶段的目标、时长估计（分钟/天/周）、进入该阶段的触发条件、离开该阶段的退出标准。
7. 为每个阶段列出触点表格，列包含：Stage、Touchpoint、Channel、What happens（例如 Discovers / Search result / Search engine / 看到竞品选项）。
8. 为每个阶段写情绪曲线，使用具体情绪标签（frustration、hope、surprise、anxiety、satisfaction）而非泛泛的 happy/sad；表格列包含 Stage、Dominant emotion、Confidence（high/medium/low，基于研究证据）、Source（如 12 次用户访谈，3 人明确提到怀疑）；若无研究数据，每条标注为 Hypothesis、置信度 Low，并建议验证研究。
9. 为每个阶段列出痛点与关键时刻：痛点是客户遇到摩擦、困惑、挫败、阻碍之处；关键时刻是决定客户继续还是放弃的 3-5 个瞬间，不是每次互动；表格列包含 Stage、Pain / Moment of Truth、Severity（1-5）、Customer evidence、Implication（例如 Considers / 定价困惑 / 4 / 87% 问卷信号 / 阻碍转化，需要价格清晰化工作）。
10. 为每个阶段标注 1-3 个机会：产品可在何处介入以减少痛点或放大关键时刻；表格列包含 Stage、Opportunity、What product change addresses it、Effort estimate（rough，如 Small/Medium）。
11. 在可行时产出 mermaid 图，markdown 表格始终是有效兜底：主图用 mermaid timeline（线性旅程）或 flowchart（带决策点的分支旅程）覆盖完整旅程；阶段数≥5 时，额外为每个阶段（或每 2-3 个阶段）产出聚焦的 mermaid 块，避免视觉拥挤和渲染失败；多角色旅程简化或省略 mermaid，改用每个角色一张并行 markdown 表格。
12. 显式写出研究缺口：因为数据不可得，地图没有覆盖什么；哪些后续研究能填补最重要的缺口。
13. 遵守拒绝协议：无人物或范围时要求补充；无研究信号却要情绪数据时，说明只能给标注为 Hypothesis（Confidence: Low）的假设情绪并建议验证，询问是走假设模式还是提供研究数据；被要求服务蓝图或架构图时说明本技能只覆盖用户体验侧，建议直接用绘图工具，但作为用户体验视角的漏斗仍在范围内；范围过大（如 5 年 B2B SaaS 端到端）时拒绝并让其选一个阶段（购前、onboarding、扩展、流失）；只给单一触点时说明单触点不是旅程，要么扩展到周边阶段，要么改用 deliver-edge-cases 枚举该流程的失败与边界条件（每行一个条件及预期处理）。
14. 按需选择旅程模式：线性（默认，用于购买旅程、onboarding 流程、支持解决路径）、循环（用于续约周期、互动循环、重复任务工作流，如 B2B 月度 QBR 周期）、多角色（高级模式，谨慎使用；用并行 markdown 表格、共享触点标注、简化或省略 mermaid，并在输出中加复杂度警告，说明多角色旅程更难验证、研究深度应优先主要角色）。
15. 定稿前跑质量清单：人物与范围已显式说明；3-7 个命名阶段各含目标、时长、触发、退出标准；每条情绪曲线条目带置信度标签和来源（或标为 Hypothesis）；关键时刻限制在决定继续/放弃的 3-5 个；每个机会都对应具体痛点或关键时刻；可行时有 mermaid 图且以 markdown 表格兜底；研究缺口已显式写出。
16. 按 references/TEMPLATE.md 组织输出，参考 references/EXAMPLE.md 的完整示例；输出可喂给 define-problem-statement、define-hypothesis、define-opportunity-tree，输入常来自 foundation-persona、discover-interview-synthesis、measure-survey-analysis，可视化用 utility-mermaid-diagrams，对抗性评审用 utility-pm-critic。

适用边界 · 注意事项

• 需要运营服务蓝图或系统架构图时（本技能只覆盖用户体验视角，不含后台流程）。
• 尚无任何研究信号、却想要超出「标注为假设的占位内容」的产出时，应先跑 discover-interview-synthesis 或 measure-survey-analysis。
• 只想框定一个具体问题而非完整体验弧线时，用 define-problem-statement；只映射单次会话任务流而非多阶段旅程时，用 deliver-edge-cases。