第1章 业务痛点定义与分类

适用场景

• 业务流程优化前的问题诊断与痛点筛查
• 产品功能改进中的用户需求挖掘
• 客户体验提升项目中痛点定位与分级
• 系统性能瓶颈分析与根因追溯
• 组织效率提升中的障碍识别与分类
• 新业务立项前的风险与机会点评估

前置条件

• 已完成基础业务数据的收集与整理
• 利益相关方（业务、产品、技术、运营）已确认参与
• 具备当前的流程文档或业务全景图（至少V1.0）
• 团队已接受痛点识别基础概念培训
• 已建立统一的术语表，避免定义歧义

操作步骤

步骤一：定义业务痛点

1. 收集业务反馈 — 从客服记录、用户访谈、运营报表、系统日志等渠道获取原始问题描述。
2. 识别损失维度 — 判断痛点属于效率损失、成本增加、体验下降还是机会错失。
3. 撰写痛点陈述 — 用一句话公式表述：“在【场景】下，【角色】因【障碍】导致【后果】”。

步骤二：区分显性痛点与隐性痛点

依据痛点的可观测程度和数据支撑情况，将其归入显性或隐性类别。对比维度如下：

步骤三：界定痛点与问题的边界

痛点不等于问题。判定边界时需从三个维度交叉验证：

输入输出物

责任边界

记录材料

• 《业务痛点识别登记表》 — 记录痛点编号、名称、步骤一中定义描述、发现日期、发现人、状态。
• 《显性/隐性分类判定表》 — 包含可观测性评分、数据支撑度、表象层判断、最终分类结论。
• 《痛点-问题边界判定表》 — 对每个痛点进行情感属性、可量化程度、归因方式的三维打分，输出边界结论。

| 痛点编号 | 痛点名称         | 情感属性 | 可量化程度 | 归因方式 | 边界结论 |
|----------|------------------|----------|------------|----------|----------|
| P-001    | 下单页超时        | 焦虑     | 高（4.2s） | 技术     | 问题     |
| P-002    | 客户觉得流程繁琐  | 不满     | 低（定性）  | 体验     | 痛点     |

异常处理

验收标准

1. 定义准确 — 每个痛点都有明确的场景、角色、障碍、后果四要素，无歧义。
2. 分类清晰 — 显性痛点均有量化数据佐证；隐性痛点均有定性分析或行为轨迹支撑。
3. 边界可追溯 — 每个痛点/问题的边界判定均有情感属性、可量化程度、归因方式的三维记录。
4. 清单完整 — 覆盖所有已识别的业务反馈，无遗漏（需与原始反馈记录逐条核对）。
5. 评审通过 — 业务、产品、技术、运营四方对分类与边界结论达成一致，签字确认。