第二章：CRM业务分析——客户管理核心流程、销售漏斗模型、服务工单系统、数据报表需求
好，咱们进入正题。CRM系统听起来高大上，但说白了，它要解决的就是三个核心问题：客户怎么来、怎么成交、怎么服务好。这一章，我就带你把这几个核心业务模块拆开揉碎了讲清楚。
2.1 客户管理核心流程：从线索到回款
我个人习惯把客户管理流程分成四个阶段：线索获取 → 客户转化 → 客户维护 → 客户增值。你想想看，这其实就是一个完整的生命周期。
2.1.1 线索管理
线索从哪来？渠道太多了。官网注册、市场活动、老客户推荐、甚至销售自己扫街。我在项目中遇到过最头疼的问题，就是线索重复。同一个客户，销售A录入一次，销售B又录入一次，最后两人抢单，闹得不可开交。
解决方案其实不复杂：用手机号+邮箱作为唯一标识，配合模糊匹配算法。代码层面，我建议这样设计去重逻辑：
// 伪代码：线索去重逻辑
function deduplicateLead(lead) {
// 1. 精确匹配手机号
let existing = db.findByPhone(lead.phone);
if (existing) return existing;
// 2. 模糊匹配邮箱
existing = db.findByEmail(lead.email);
if (existing) return existing;
// 3. 公司名+联系人名组合匹配
existing = db.findByNameAndCompany(lead.name, lead.company);
if (existing) return existing;
// 4. 都没匹配到，创建新线索
return db.createLead(lead);
}
2.1.2 客户信息模型
客户信息怎么存？别搞成一张大表。我建议拆成三层：
| 层级 | 包含字段 | 说明 |
|---|---|---|
| 基础信息 | 客户ID、名称、行业、规模、来源渠道 | 不变或极少变化 |
| 联系信息 | 手机、邮箱、地址、微信 | 可能变更，独立存储 |
| 业务信息 | 客户等级、所属销售、最近跟进时间、成交金额 | 动态变化，高频更新 |
嗯，这里要注意：联系信息一定要支持多对多。一个客户可能有多个联系人，一个联系人可能对应多个客户（比如采购经理跳槽了）。
2.2 销售漏斗模型：把过程管起来
销售漏斗，说白了就是把销售过程可视化。我见过太多公司只盯着结果——这个月签了多少单。但过程呢？哪个环节流失最多？没人知道。
2.2.1 漏斗阶段设计
我建议至少分5个阶段：
- 初步接触：销售第一次联系客户
- 需求确认：客户有明确需求，双方沟通方案
- 方案报价：提交正式报价或方案
- 商务谈判：谈价格、合同条款
- 成交/丢单：最终结果
2.2.2 漏斗分析怎么做
我记得有一次帮一家SaaS公司做CRM，他们的销售漏斗在「方案报价」到「商务谈判」这个环节转化率只有20%。一查原因，原来是报价流程太慢，销售要等3天才能拿到审批。后来我们做了自动化报价审批，转化率直接翻倍。
代码层面，漏斗分析其实就是状态机+时间戳：
// 伪代码：漏斗阶段变更记录
class Opportunity {
constructor() {
this.stages = [];
this.currentStage = 'initial_contact';
}
moveToStage(newStage) {
this.stages.push({
from: this.currentStage,
to: newStage,
timestamp: Date.now()
});
this.currentStage = newStage;
}
getStageDuration(stageName) {
// 计算在某个阶段停留的时间
const stage = this.stages.find(s => s.to === stageName);
if (!stage) return 0;
const nextStage = this.stages.find(s => s.from === stageName);
return nextStage ? (nextStage.timestamp - stage.timestamp) : (Date.now() - stage.timestamp);
}
}
2.3 服务工单系统：把服务标准化
客户买了产品，只是开始。后续的服务才是留住客户的关键。工单系统，就是把服务流程标准化、可追踪。
2.3.1 工单生命周期
一个工单从创建到关闭，我建议走这6步：
- 创建：客户或客服发起工单
- 分配：自动或手动分配给工程师
- 处理中：工程师开始处理
- 等待客户反馈：需要客户确认或提供信息
- 解决：问题已处理，等待客户确认
- 关闭：客户确认问题解决，工单关闭
2.3.2 工单与客户关联
工单不能孤立存在。它必须关联到客户、合同、产品。我在项目中遇到过最尴尬的事：客服处理一个工单，查了半天才发现这个客户已经过了保修期。所以，工单创建时就要自动校验：
// 伪代码：工单创建校验
function createTicket(customerId, productId, issue) {
const customer = getCustomer(customerId);
const contract = getActiveContract(customerId, productId);
if (!contract) {
// 没有有效合同，提示客户购买服务
return { error: '该产品暂无有效服务合同', suggestPurchase: true };
}
if (contract.isExpired()) {
// 合同已过期，提示续费
return { error: '服务合同已过期', suggestRenew: true };
}
// 一切正常，创建工单
return createTicketInternal(customer, product, issue, contract.slaLevel);
}
2.4 数据报表需求：用数据说话
CRM系统没有报表，就像开车没有仪表盘。你根本不知道业务跑得怎么样。我建议至少做这三类报表：
2.4.1 销售报表
| 报表名称 | 核心指标 | 更新频率 |
|---|---|---|
| 销售漏斗报表 | 各阶段转化率、平均停留时长 | 每日 |
| 销售业绩报表 | 签约金额、回款金额、完成率 | 实时 |
| 客户流失报表 | 流失客户数、流失原因分析 | 每周 |
2.4.2 服务报表
- 工单响应时效：平均响应时间、超时率
- 工单解决率：首次解决率、平均解决时长
- 客户满意度：工单关闭后的评分统计
2.4.3 报表技术选型
说到技术实现，我建议用事件驱动+物化视图的方式。别在业务数据库里直接跑复杂查询，会拖垮性能的。
// 伪代码：报表数据聚合
// 1. 业务操作产生事件
eventBus.emit('ticket.closed', { ticketId, customerId, duration, satisfaction });
// 2. 事件消费者更新物化视图
eventBus.on('ticket.closed', (event) => {
db.query(`
UPDATE daily_service_report
SET total_closed = total_closed + 1,
avg_duration = (avg_duration * total_closed + ${event.duration}) / (total_closed + 1)
WHERE date = CURRENT_DATE
`);
});
这样做的好处是：报表数据实时更新，而且不影响业务数据库的性能。我在多个项目中都用这个方案，效果很好。
好了，这一章的内容就这些。客户管理、销售漏斗、工单系统、数据报表——这四个模块是CRM的骨架。下一章，我会带你看看微服务架构下怎么拆分这些模块。到时候你会发现，业务分析得越清楚，技术拆分就越简单。