一、CRM系统概述与需求分析
大家好，我是老张。做数据库架构这行十几年了，CRM系统是我接触最多的业务系统之一。今天咱们聊聊CRM系统最基础的东西——它到底是什么，核心模块有哪些，以及需求分析该怎么做。
说实话，很多刚入行的朋友对CRM的理解就是「客户管理软件」。嗯，这个说法没错，但太表面了。我见过不少项目，就是因为一开始没搞清楚CRM的本质，最后做出来一个「高级通讯录」——除了存客户电话，啥也干不了。
1.1 什么是CRM系统
CRM，全称Customer Relationship Management，客户关系管理。说白了，就是帮企业管好「跟客户打交道」这件事。
你想想看，一个销售每天要联系几十个客户，每个客户从初次接触到最终成交，中间可能有几十次沟通。这些信息如果全靠脑子记，或者散落在Excel、微信聊天记录里，那基本等于没有。
CRM系统要解决的核心问题就三个：
- 客户信息集中管理——所有客户数据在一个地方，谁都能查到
- 销售过程可视化——每个客户处于什么阶段，一目了然
- 服务体验可追溯——客户投诉、售后问题，有记录、有跟踪
我个人习惯把CRM比作「客户全生命周期管理工具」。从潜在客户到忠实客户，再到可能流失的客户，CRM要覆盖整个过程。我在项目中遇到过很多次，业务方说「我们就要个简单的客户登记系统」，结果用着用着就发现，销售跟进、合同管理、服务工单全都要加进来。所以一开始就把生命周期想清楚，能省很多事。
1.2 核心业务模块
CRM系统再复杂，核心模块也就三个：客户管理、销售管理、服务管理。咱们一个一个说。
1.2.1 客户管理模块
这是CRM的根基。没有客户数据，其他模块都是空中楼阁。
客户管理要管什么？我列一下最基本的需求：
- 客户基本信息：公司名称、联系人、电话、邮箱、地址
- 客户分类：潜在客户、意向客户、成交客户、流失客户
- 客户来源：广告投放、朋友介绍、线下展会、官网注册
- 联系记录：每次沟通的时间、内容、结果
- 客户标签：行业、规模、需求偏好等自定义标签
这里有个坑，我提醒一下。很多系统把客户和联系人混在一起，一个客户只对应一个联系人。但实际业务中，一个公司可能有多个联系人——采购经理、技术负责人、老板，每个人关注的点都不一样。我曾经就因为这个设计失误，导致一个项目上线后被业务部门疯狂吐槽。所以，客户和联系人一定要分开建模。
避坑指南：我曾经接手过一个项目，客户表里直接存了「联系人姓名」字段。后来业务要求一个客户有多个联系人，改表结构改得我头皮发麻。所以一开始就设计成「客户表」+「联系人表」一对多的关系，后面会省心很多。
1.2.2 销售管理模块
销售管理，说白了就是管「怎么把客户变成钱」的过程。
核心功能包括：
- 销售线索管理：从各种渠道获取的潜在客户信息，统一录入、分配
- 商机管理：把有明确购买意向的线索转化为商机，跟踪推进
- 销售漏斗：可视化展示每个阶段的商机数量和金额
- 报价与合同：生成报价单，管理合同审批流程
- 销售预测：基于漏斗数据，预测未来一段时间的成交额
我记得有一次，一个销售总监跟我说：「老张，我手底下20个销售，每天忙得团团转，但我根本不知道他们到底在忙什么。」这就是销售管理要解决的问题。通过销售漏斗，每个商机在哪个阶段、预计成交时间、金额，全都清清楚楚。
嗯，这里要注意一点。销售漏斗的每个阶段，一定要跟业务方确认清楚。不同公司的销售流程不一样，有的简单（意向→报价→成交），有的复杂（初次接触→需求确认→方案演示→技术交流→商务谈判→合同审批→成交）。我建议用阶段表来管理，而不是硬编码在代码里。
-- 销售阶段表设计示例
CREATE TABLE sales_stage (
stage_id INT PRIMARY KEY,
stage_name VARCHAR(50), -- 阶段名称
stage_order INT, -- 排序
probability DECIMAL(5,2), -- 成交概率（%）
is_active TINYINT DEFAULT 1 -- 是否启用
);
-- 商机表
CREATE TABLE opportunity (
opp_id INT PRIMARY KEY,
customer_id INT, -- 关联客户
opp_name VARCHAR(100), -- 商机名称
amount DECIMAL(12,2), -- 预计金额
current_stage INT, -- 当前阶段
create_time DATETIME,
expected_close_date DATE,
FOREIGN KEY (current_stage) REFERENCES sales_stage(stage_id)
);
1.2.3 服务管理模块
客户买完东西就结束了吗？当然不是。售后服务做得好，客户才会复购，才会帮你转介绍。
服务管理模块的核心功能：
- 工单管理：客户提交问题，生成服务工单，分配给对应人员
- 知识库：常见问题的解决方案，客户和客服都能查
- 服务满意度：工单完成后，客户评价服务质量
- 客户回访：定期回访，了解客户使用情况
这里我想强调一下工单的流转。一个工单可能从客服接单，转到技术支持，再转到研发，最后回到客服确认关闭。每个环节的处理时间、处理人、处理结果，都要有记录。我见过一个系统，工单状态就三个「待处理、处理中、已完成」，结果业务部门根本没法追溯问题到底卡在哪个环节。
注意：工单的状态流转一定要设计成「状态机」模式。每个状态定义清楚「可执行的操作」和「下一个状态」。比如「待处理」只能「接单」变成「处理中」，不能直接跳到「已完成」。否则数据会乱得一塌糊涂。
1.3 典型功能需求分析
讲完核心模块，咱们聊聊需求分析。做CRM系统，最怕的就是业务方说「你看着做吧，功能全一点就行」。这种需求，基本等于没需求。
我一般会从三个维度去梳理需求：
| 需求维度 | 典型问题 | 对应功能 |
|---|---|---|
| 客户管理 | 客户信息太分散，销售离职客户就丢了 | 客户统一管理、数据导出、权限控制 |
| 销售管理 | 不知道每个销售在跟什么客户，进度如何 | 销售漏斗、跟进记录、日报统计 |
| 服务管理 | 客户投诉没人管，问题解决效率低 | 工单系统、自动分配、超时提醒 |
| 数据分析 | 管理层看不到整体业务情况 | 数据看板、报表统计、趋势分析 |
举个例子。有一次我去一家做企业软件的公司做需求调研，销售总监跟我说：「我就想知道，我这个月能签多少单。」这个需求听起来简单，但背后涉及的东西不少——销售漏斗数据要准，每个阶段的转化率要算，历史数据要能对比。最后我们做了一个销售预测看板，把漏斗数据、历史同期数据、个人目标完成率放在一起，他一看就明白了。
所以，需求分析不能只听表面。业务方说「我要一个客户管理功能」，你要追问：「管什么？怎么管？谁管？管到什么程度？」问得越细，后面设计数据库的时候就越有底气。
总结一下：CRM系统的核心，就是围绕客户的全生命周期，把销售过程和服务过程管起来。数据库设计的时候，一定要先理解业务，再动手建表。我见过太多人一上来就画ER图，结果画出来的东西跟业务对不上，改来改去浪费大量时间。先花时间把需求搞清楚，后面会顺利很多。
好了，这一章就聊到这儿。下一章咱们会深入客户管理模块的数据库设计，包括客户表、联系人表、客户分类表的具体字段和索引设计。到时候我会拿实际项目中的案例来讲，保证干货满满。