customer-journey-map

customer-journey-map 技能概览

customer-journey-map 技能可以帮你创建结构化的客户旅程地图，把阶段、触点、行为、情绪、KPI、业务目标和团队串联起来。它最适合产品经理、UX 研究员、服务设计师以及需要更清楚看出体验在哪些环节失效、下一步该改什么的跨职能负责人。

当你需要的不只是用户流时，就该用这个 skill：它的设计目标是把从认知到忠诚的完整体验都呈现出来，让团队对真实的客户旅程达成一致，而不是只盯着某个页面或漏斗步骤。customer-journey-map 的核心价值，在于它能把缺口、交接和各阶段的痛点用更容易讨论、也更容易落地的方式显现出来。

适合 UX Research 和 PM 的场景

customer-journey-map 技能尤其适合用于 UX Research 场景下的 customer-journey-map：当你已经有访谈记录、客服信号、分析数据或 onboarding 观察结果时，它可以帮你把这些材料整理成可用的产出物。它同样适用于产品和增长工作，尤其是当目标是按阶段优先级推进改进，而不是按功能清单推进时。

它的不同之处

这个 skill 强调的是可衡量的旅程阶段，而不只是定性叙事。它会推动你把客户行为和业务目标、相关团队连起来，因此比通用的 workshop prompt 更适合直接用于执行。

什么时候不适合用

如果你只需要任务流、页面地图或转化漏斗，这个 skill 的范围可能太大。它最强的场景，是问题横跨多个触点、多个团队的时候。

如何使用 customer-journey-map 技能

customer-journey-map 安装

使用以下命令安装该 skill：

npx skills add deanpeters/Product-Manager-Skills --skill customer-journey-map

安装后，确认 skills/customer-journey-map 目录已经存在，并先阅读主说明文件。

仓库里先读什么

先看 SKILL.md，再检查 template.md 和 examples/ 里的示例。模板会告诉你预期结构，示例则展示如何把真实的阶段、触点和指标填进去。如果你正在判断是直接复用这个 skill，还是需要做适配，这三个文件能最快给你信号。

怎么提问效果最好

在使用 customer-journey-map 时，要给模型一个明确的客户、清晰的旅程边界，以及你想回答的业务问题。高质量输入通常包括：

• Persona 或细分人群
• 旅程的起点和终点
• 产品或服务背景
• 已知痛点或假设
• 相关指标、团队或触点

像“做一个 customer journey map”这样的问题太弱，会留下太多自由度。更好的提问方式是： “为我们的 B2B SaaS 产品创建一个 customer-journey-map，范围是首次 onboarding，从注册到首次获得价值，使用客服工单、激活指标和用户访谈主题。按阶段突出流失点、情绪和团队归属。”

实际工作流

一个好的 customer-journey-map 指南通常按下面的顺序推进：

1. 定义 persona 和旅程范围。
2. 按顺序列出各个阶段。
3. 为每个阶段收集行为、触点、情绪和 KPI。
4. 加入业务目标和涉及的团队。
5. 回顾哪些环节摩擦最大，或在哪些地方存在 ownership 空缺。
6. 把这些缺口转化为优先级更高的实验或研究问题。

这个工作流很重要，因为这个 skill 最适合建立在证据基础上，而不是从零凭空编出来。

customer-journey-map 技能 FAQ

customer-journey-map 只适合 UX Research 吗？

不是。它同样适用于 UX Research、产品管理、onboarding、客户成功和服务设计。UX Research 场景下的价值最强，尤其是在你想把定性洞察整合成团队可以直接使用的旅程地图时。

它和通用 prompt 有什么区别？

通用 prompt 可能也能生成一个看起来不错的表格，但 customer-journey-map 技能会给你更清晰的分析框架：按阶段分析、触点、情绪、KPI、业务目标和团队归属。这样的结构通常能产出更可执行的结果，也更少来回修改。

我必须先有很强的源数据吗？

如果你有一些源材料，结果通常会更好，比如访谈笔记、分析数据、客服主题或 onboarding 观察。这个 skill 也可以基于假设先出一个草稿，但如果能对应到真实信号，可信度会高得多。

什么时候应该跳过这个 skill？

如果你的问题只集中在一个交互、一个页面或一个转化步骤上，就不必用它。若你需要的是视觉化 UI wireframe 或流程图，而不是客户体验地图，它也不合适。

如何改进 customer-journey-map 技能

输入要比“整个旅程”更具体

决定输出质量的最大杠杆是范围。不要只泛泛地要一张端到端地图，而要明确 persona、渠道和你关心的结果。例如，“面向自助型 SMB 用户的 trial-to-paid onboarding”就比“我们的 customer journey”清楚得多。

提供证据，不要只给假设

如果你加入具体源材料，这个 skill 会明显更好用：最常见的客服投诉、几条访谈原话、激活指标、流失原因，或者销售异议。这能让地图更贴近现实，也能避免填充过多空泛的阶段性内容。

检查阶段缺口和归属缺口

第一版出来后，重点看哪些阶段的触点模糊、情绪缺失，或者没有明确的团队 owner。这些地方通常最需要补充信息，或者再迭代一轮。在 customer-journey-map 的使用中，不顺畅的交接往往比修饰得很漂亮的文字更有价值。

朝着决策推进迭代

用第一版输出来决定下一步该研究什么、修什么、测什么。如果地图太笼统，就要求它缩小 persona 范围，或者把旅程边界定得更具体。如果内容太描述化，就要求它按阶段突出痛点、KPI 和团队动作。