3、需求分析与建模：销售漏斗模型、客户旅程地图、核心实体（客户、线索、商机、合同）
好，咱们进入第三章。这一章很关键，说白了就是给整个销售自动化系统「打地基」。你想想看，如果地基没打好，后面盖的楼再漂亮也得塌。我个人习惯，做任何系统之前，先花大量时间在需求分析和领域建模上。磨刀不误砍柴工嘛。
3.1 销售漏斗模型：从「广撒网」到「精准捕捞」
销售漏斗，英文叫 Sales Funnel。它不是一个物理漏斗，而是一个过程模型。它描述了潜在客户从「知道我们」到「掏钱买单」的整个转化路径。
我在项目中遇到过不少团队，上来就写代码，结果做着做着发现「咦？这个商机到底算哪个阶段？」。嗯，这就是没把漏斗定义清楚。
核心观点：漏斗的每一层，都代表一个「转化动作」。没有动作，就没有阶段。
一个经典的 B2B 销售漏斗，通常包含这几个阶段：
- 线索（Leads）： 潜在客户的第一印象。比如，他填了你的表单，或者下载了你的白皮书。
- 合格线索（MQL - Marketing Qualified Lead）： 市场部觉得「嗯，这人有点意思」，比如他看了3次你的产品页面。
- 商机（Opportunity）： 销售接手了，并且确认对方有预算、有决策权、有需求。这是质的飞跃。
- 报价/提案（Proposal）： 你给了方案，对方在考虑。
- 谈判/评审（Negotiation）： 讨价还价，法务介入。
- 赢单/丢单（Closed Won/Lost）： 最终结果。
你可能会问：「为什么一定要分这么细？」
原因很简单：没有漏斗，你就不知道你的销售团队卡在哪里。 是线索不够？还是线索质量太差？还是销售跟单能力不行？漏斗数据会告诉你答案。
我的小技巧： 在设计数据库时，我会给「阶段」字段预留一个排序值（order_index）。这样前端展示漏斗图时，直接按这个值排序，非常优雅。千万别用字符串排序，你会后悔的。
3.2 客户旅程地图：站在用户的角度看问题
销售漏斗是「我们」的视角。客户旅程地图（Customer Journey Map）是「客户」的视角。这两个东西，就像硬币的两面，缺一不可。
我曾经犯过一个错：只关注漏斗转化率，忽略了客户体验。结果呢？转化率上去了，但客户投诉率也上去了。后来我明白了，漏斗是骨架，旅程是血肉。
客户旅程通常分为几个阶段：
- 认知（Awareness）： 客户发现他有某个问题，或者发现了你的产品。
- 考虑（Consideration）： 客户开始研究解决方案，对比你和竞品。
- 决策（Decision）： 客户决定买谁家的。
- 服务（Service）： 买完之后，使用、续费、推荐。
在建模时，我们需要把「客户旅程」和「销售漏斗」对应起来。比如：
| 客户旅程阶段 | 对应漏斗阶段 | 客户行为 | 系统需要记录什么？ |
|---|---|---|---|
| 认知 | 线索 | 访问官网、点击广告 | 来源渠道、首次访问时间 |
| 考虑 | 合格线索 -> 商机 | 请求演示、咨询价格 | 沟通记录、需求文档 |
| 决策 | 报价 -> 谈判 | 要求修改方案、法务审核 | 版本历史、审批记录 |
| 服务 | 赢单 | 使用产品、寻求支持 | 工单、合同、续费提醒 |
避坑指南： 我曾经见过一个系统，把「客户旅程」和「销售漏斗」混为一谈，结果数据一团糟。记住：旅程是「客户做了什么」，漏斗是「我们做了什么」。 两者可以关联，但不能等同。
3.3 核心实体建模：客户、线索、商机、合同
好，理论讲完了，咱们来点实际的。这部分我会直接给出我常用的实体设计思路。你想想看，一个销售自动化系统，核心就这四个实体：客户（Account）、线索（Lead）、商机（Opportunity）、合同（Contract）。
3.3.1 客户（Account）
客户是「公司」或「组织」。注意，不是「联系人」。联系人（Contact）是客户下的子实体。这个区分很重要。
我习惯的客户表字段：
-- 客户表核心字段
Account {
id: UUID (主键)
name: String (公司名称，必填)
industry: String (行业，比如「制造业」、「金融」)
size: Enum (公司规模: 1-50人, 50-200人, 200-1000人, 1000+)
status: Enum (潜在客户, 现有客户, 流失客户)
source: String (来源渠道，比如「百度推广」、「朋友介绍」)
created_at: DateTime
updated_at: DateTime
}个人经验： 别把「客户名称」设成唯一索引。现实中，重名的公司太多了。我一般用「名称 + 行业 + 地区」组合来去重。
3.3.2 线索（Lead）
线索是「未经确认的潜在客户」。它可能是一个人，也可能是一个公司。线索的核心是「来源」和「状态」。
-- 线索表核心字段
Lead {
id: UUID
first_name: String
last_name: String
email: String
phone: String
company: String (他所在的公司)
source: String (来源，同上)
status: Enum (新建, 联系中, 已转化, 已废弃)
converted_to_opportunity_id: UUID (关联到商机，可为空)
converted_to_account_id: UUID (关联到客户，可为空)
created_at: DateTime
}这里有个关键点：线索转化。当一个线索被确认是「有效」的，它就会变成「商机」，同时可能创建一个「客户」记录。这个过程，我建议用事务（Transaction）来保证数据一致性。
3.3.3 商机（Opportunity）
商机是「正在推进的销售项目」。它是整个系统的核心，所有活动都围绕它展开。
-- 商机表核心字段
Opportunity {
id: UUID
name: String (商机名称，比如「XX公司ERP项目」)
account_id: UUID (关联客户)
amount: Decimal (预计金额)
stage: Enum (阶段，对应漏斗)
probability: Integer (赢单概率，0-100)
close_date: Date (预计关单日期)
owner_id: UUID (负责人)
description: Text
created_at: DateTime
}重点： stage 和 probability 是动态的。我建议把它们做成配置表，而不是硬编码。这样业务方可以随时调整漏斗阶段，不需要改代码。
3.3.4 合同（Contract）
合同是「成交的最终产物」。它关联商机，也关联客户。
-- 合同表核心字段
Contract {
id: UUID
contract_number: String (合同编号，唯一)
opportunity_id: UUID (关联商机)
account_id: UUID (关联客户)
total_amount: Decimal (合同总金额)
status: Enum (草稿, 待审批, 已签署, 执行中, 已终止)
signed_date: Date
start_date: Date
end_date: Date
payment_terms: String (付款条款)
created_at: DateTime
}嗯，这里要注意：合同和商机是一对一的关系吗？ 不一定。一个商机可能拆成多个合同（分期付款），也可能一个合同包含多个商机（打包销售）。我建议设计成「多对多」，中间加一个关联表。
3.4 实体关系图（ER 图）
最后，咱们用文字描述一下这几个实体的关系：
- 客户（Account） 1 : N 联系人（Contact） —— 一个客户有多个联系人。
- 线索（Lead） 1 : 0..1 商机（Opportunity） —— 一个线索最多转化成一个商机。
- 商机（Opportunity） N : M 合同（Contract） —— 通过中间表关联。
- 客户（Account） 1 : N 合同（Contract） —— 一个客户可以有多个合同。
说白了，这就是一个「从模糊到清晰」的过程。线索是模糊的，商机是清晰的，合同是确定的。每一步，数据都在变「重」。
我曾经踩过的坑： 在设计初期，我把「线索」和「联系人」合并了。结果导致数据非常混乱，因为线索可能没有公司信息，而联系人必须有。后来我花了整整一周重构数据。所以，一开始就把实体分清楚，比什么都重要。
好，这一章就到这里。下一章，咱们会基于这些实体，开始设计具体的 API 和数据库表结构。到时候，我会带着你一起写 SQL 和代码。