简介：中国电信客户关系管理（CRM）设计系统文档面向电信运营商管理者、CRM系统设计人员及企业信息化研究者，针对传统“九七工程”面向生产、客户信息孤岛、部门服务脱节等突出问题，提出以客户为中心、分阶段分步骤推进CRM系统建设的管理思路。文档系统梳理了建设背景、现有系统九大问题及改进方向，涵盖客户需求分析、原型法式自上而下建设、信息共享与集成、客户分类与精准营销、个性化一对一服务、决策支持等关键模块，并给出从管理层需求出发、在应用中循环迭代的完善机制。同时结合中国电信实际，重点讨论大客户管理、潜在客户开发、热装冷用现象、客户流失控制及电子商务转型等落地场景，使读者能够获取完整的CRM规划设计框架、问题诊断清单和分步实施建议。资源包共1个docx文件，大小264KB，内容完整、便于直接阅读；已有328人学习，适合正在规划或优化客户关系管理体系的相关人员参考。
1. 一份名叫「中国电信客户关系管理(CRM)设计系统.docx」的文档，真正要交付的是什么
「中国电信客户关系管理(CRM)设计系统.docx」这个文件名，一看就是某个评审会之前的交付物。真正干活的人拿到它，关心的不是文档排版，而是三件事：这套 CRM 管哪些业务对象、对象之间的状态怎么流转、数据最终落到哪些表。标题里的“设计系统”四个字很容易让人往 UI 设计规范上想，但在电信语境下，值钱的是业务架构和数据模型。这题按一线交付习惯展开，适合被安排去写 CRM 设计文档、评审方案，或者准备做 CRM 系统改造的工程师。目标只有一个：让这份 docx 不只看起来“设计得很好”，而是能照着开发不返工。
2. 电信 CRM 的“设计系统”先把两种含义分清：UI 规范和业务架构不是一回事
评审会上我见过标题里带着“设计系统”的文档，目录一打开全是色板、按钮、字体规范，业务表结构一个字没有——写文档的人把 Design System 直接搬了进来。这个问题不是个例，标题本身确实有歧义。要往下做，第一步不是画图，而是明确这个 docx 到底在讲哪一套“设计系统”。
2.1 「设计系统」到底指 UI 设计系统，还是系统设计？
很多团队把 CRM 的目标理解成“把界面设计得比较美观的系统”，于是交付物里全是页面原型和视觉走查表。界面视觉当然要做，但在后面接开发时，UI 规范只是最外面一层。拿一份标题类似的 docx 快速判断：如果目录里有“总体架构”“数据模型”“接口定义”“权限矩阵”，那就是系统设计；如果只有“色彩规范”“组件库”“页面模板”，那就是 UI 设计系统。电信 CRM 的规模基本不可能只靠 UI 规范撑起来。
打开目录还能看到另一种情况：整份文档照着“XX 系统设计与实现”的通用模板写，功能清单一大篇、截图贴满，却回答不了“客户改一个套餐，账务和产品实例怎么联动”。这不是说通用模板没用，而是电信 CRM 和普通销售系统的差异不在表面功能，在业务对象的关系。比如“客户”和“账户”为什么必须分开，套餐为什么不能做成一个字段，这些问题只有系统设计层面能回答。
2.2 电信 CRM 四个核心域：客户、产品、订单、账务
常见 CRM 讲的是线索、商机、跟进、成交，电信 CRM 要再多管一层：人（客户）、在网产品（产品实例）、受理过程（订单）、钱（账务）。这四个域互相咬合，任何一个单独拆出去都会让系统变成“带界面的通讯录”。先定义边界，再谈功能。
| 核心域 | 管理对象 | 典型实体 | 一句话职责 |
|---|---|---|---|
| 客户域 | 客户是谁 | 客户、联系人、客户分类、信用等级 | 统一客户视图，识别个人和企业 |
| 产品域 | 能卖什么、在网什么 | 产品目录、销售品、产品实例 | 套餐、资费、捆绑都从这里取 |
| 订单域 | 业务怎么开通 | 受理单、订单、订单项、状态日志 | 从申请到竣工的状态流转 |
| 账务域 | 钱怎么算 | 账户、账单、缴费记录、欠费 | 出账、销账、催费依附的账户体系 |
客户域在电信场景里很有意思：一个人名下可能有一条宽带、两个移动号、一部固话，它们各自有产品实例，也各自可能停机。销售系统里“跟单状态”那套在这里只是外围，真正的状态机在产品和订单域。产品域的“产品目录”通常是一张独立的主数据表，而不是散落在各业务菜单里的代码；订单域则需要把“一个订单要做的多件事”拆成多个订单项，否则一个订单既新装又变更时状态根本没法流转。
账务域是电信 CRM 最容易在设计时被弱化的一块。很多人天然觉得“账务是计费系统的事”，设计文档里只是提了一句“对接计费”。可现实是：欠费停机、预存抵扣、账单合并、代付关系全部要能反向查到具体账户。CRM 不实现计费，但必须知道账户模型长什么样，否则接口一画就漏。
一个例子就能看出四个域的牵连：用户申请“宽带新装 + 加装副卡”，订单域先拆出两个订单项；资源系统给宽带分配端口；产品实例域在建两条实例；生成的产品实例关联到客户和账户；竣工后账户域开始每月出账。如果账务域在文档里缺席，验收时就会发现在线缴费、欠费停机都是挂在客户表上拼出来的。
2.3 用系统边界表回答「哪些功能不在 CRM 里」
设计系统最容易失控的点，是每个模块都想在自己的库里存一份数据。要刹住这个倾向，建议先做一次“本体级”实体梳理：把业务里真正的名词写出来，再决定每个名词归属哪个系统。企业 ERP 或 CRM 产品的 ontology 思想，本质就是先把名词稳定下来，再来谈表和字段。
| 外部系统 | 与 CRM 交换内容 | 数据方向 | 典型动作 |
|---|---|---|---|
| 计费账务系统 | 账户余额、账单、缴费结果 | CRM 调用 / 回调 | 查余额、销账回执 |
| 开通激活系统 | 订单竣工信息、激活结果 | CRM 推送 / 回调 | 代装工单 |
| 资源管理系统 | 号码、端口、IP 资源 | 双向查询预留 | 选号、端口绑定 |
| 统一支付平台 | 缴费请求、支付结果 | CRM 调用 / 回调 | 支付跳转 |
| 客服工单系统 | 用户诉求、处理结果 | 双向 | 投诉转派 |
边界表的意义在于：设计文档交付时，每个人对“哪个系统负责什么”没有分歧。另一个和边界强相关的问题是“永久在线”。旧式电信 CRM 大量功能是日终批处理，白天受理的单子晚上才出账；现在线上渠道、移动支付进来以后，订单和缴费必须是实时请求响应。设计文档里凡涉及账户余额、订单状态的接口，都按实时接口设计，而不是留一句“系统自动同步”。后续每定义一个新模块，都回到这张边界表问一句：这件事真的属于 CRM 吗？还是应该丢给外围系统。
3. 用客户、账户、产品实例、订单四类实体撑起数据模型：表结构怎么在 docx 里落地
实体清单列完，最容易犯的错是迫不及待开始画功能菜单。“设计系统”的价值恰恰在数据模型：一个菜单不对可以改，一张核心表不对，后续所有开发都在为错误的地基打补丁。这一章给出最核心的实体关系和三张主表骨架。
3.1 先回答三对关系：客户与账户、产品实例与产品、订单与订单项
数据模型不必一开始写全字段，先把关系确定下来。顺序是：客户与账户、产品实例与产品、订单与订单项。
| 关系对 | 关系 | 落地方式 |
|---|---|---|
| 客户 - 账户 | 多对多 | 中间关系表 customer_account_rel |
| 产品实例 - 产品目录 | 多对一 | product_instance.product_id 引用 catalog |
| 订单 - 订单项 | 一对多 | order_item.order_id 引用主单 |
客户和账户分开是电信 CRM 建模的第一原则。客户是自然人或法人，账户是“钱”的容器。一个人可能有两个账户（家庭宽带一个、手机一个），一个账户也可能被多人代付。把账户做成客户表的一列，后面每次出账都会被卡住。产品实例和产品目录分开，是为了让“可售商品”和“用户已购商品”各自独立。最后是订单拆项：电信一张单子常常包含多个动作，比如新装宽带、加装副卡、办理彩铃，这些动作的竣工时间可能不同，必须用订单项分别承载状态。
3.2 核心表骨架：一份可以直接交评审的 DDL 样例
下面这份 SQL 是文档里可以出现的最小演示版本。它的目的不是完整复刻某个现网库，而是把三对关系落到可见的表结构上，让评审者能直接对着字段讨论。
-- 客户主表：只放基本信息和属性，不放余额、不放套餐 CREATE TABLE customer ( customer_id BIGINT PRIMARY KEY COMMENT '客户标识', customer_name VARCHAR(128) COMMENT '客户姓名/企业名称', customer_type TINYINT COMMENT '1-个人 2-企业', cert_type TINYINT COMMENT '证件类型', cert_no VARCHAR(64) COMMENT '证件号码', status TINYINT COMMENT '1-有效 2-冻结 3-注销', create_time DATETIME ) COMMENT='客户主表'; -- 账户表：承载账单、余额、信用 CREATE TABLE account ( account_id BIGINT PRIMARY KEY, account_no VARCHAR(32) UNIQUE COMMENT '账务号码', owner_customer_id BIGINT COMMENT '归属客户，不限制唯一', balance_cent BIGINT COMMENT '余额，单位分', credit_level TINYINT COMMENT '信用等级', status TINYINT ) COMMENT='账户表'; -- 客户账户关系表：支持一个人多个账户、多人代付 CREATE TABLE customer_account_rel ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_id BIGINT, account_id BIGINT, rel_type TINYINT COMMENT '1-归属 2-代付', effective_date DATE, expire_date DATE ) COMMENT='客户账户关系表'; -- 产品目录表：可售卖的宽带、移动、融合套餐 CREATE TABLE product_catalog ( product_id BIGINT PRIMARY KEY, product_name VARCHAR(128), product_type TINYINT COMMENT '1-宽带 2-移动 3-固话 4-融合套餐', status TINYINT ) COMMENT='产品目录'; -- 产品实例表：用户真正订购到的在网记录 CREATE TABLE product_instance ( instance_id BIGINT PRIMARY KEY, customer_id BIGINT, account_id BIGINT, product_id BIGINT COMMENT '引用产品目录', instance_status TINYINT COMMENT '1-在建 2-正常 3-停机 4-销户', order_id BIGINT COMMENT '由哪个订单产生', activate_time DATETIME, expire_time DATETIME ) COMMENT='产品实例表'; -- 订单主表与订单项表 CREATE TABLE sales_order ( order_id BIGINT PRIMARY KEY, order_no VARCHAR(32) UNIQUE, customer_id BIGINT, order_type TINYINT COMMENT '1-新装 2-变更 3-停复机 4-销户', status TINYINT COMMENT '1-草稿 2-受理 3-竣工 4-失败 5-取消', channel VARCHAR(32) COMMENT '营业厅/外呼/线上', create_time DATETIME ) COMMENT='订单主表'; CREATE TABLE order_item ( item_id BIGINT PRIMARY KEY, order_id BIGINT, product_id BIGINT, action_type TINYINT COMMENT '1-开通 2-暂停 3-恢复 4-变更', status TINYINT ) COMMENT='订单项表';这个 DDL 样例有几个参数值得多说。金额字段 balance_cent 用 BIGINT 存“分”，这是为了避免浮点数在账务计算里产生 0.000001 级别的魔鬼误差，电信账务对这类误差零容忍。账号类字段 account_no、order_no 用 VARCHAR 且建 UNIQUE，不用数字主键裸露给外部，防止被遍历。所有状态字段都设计成 TINYINT 并配注释，文档里必须再附一张枚举字典表，否则开发只能靠猜。时间字段用 DATETIME，如果系统可能跨时区，再加一个时区偏移字段，不要靠服务器时区偷偷约定。
索引策略在文档里也要留一行交代。customer_account_rel 按 account_id 建索引，因为按账户查归属客户是高频动作；product_instance 建 (customer_id, status) 联合索引，支撑“某用户名下正常产品列表”；sales_order 建 (status, create_time) 联合索引，工单列表按状态和日期开查询。字段长度按项目实际情况裁剪，但建议都按规范写，不要写 TEXT 偷懒。
3.3 套餐必须进产品目录，不能做成“客户表一列”
老式系统最爱干的事是在 customer 表上直接加 broadband_package、mobile_package 这类字段。第一次营销活动就翻车：用户换套餐，一条 UPDATE 把旧套餐覆盖掉，历史记录全没了；想做“老用户回馈”，连谁曾经用过旧套餐都查不出。更麻烦的是套餐捆绑优惠无法表达，一个融合套餐里有宽带、移动、IPTV，靠字段根本描述不出来。
新模型让套餐变成产品目录里的一条记录，用户订购后产生 product_instance。换套餐的正确动作不是改 customer，而是给旧实例打失效时间，再建一个新实例，或者对同一实例做版本化变更。这样任何时候都能回答“这个用户过去三个月用过什么”。表格对比会更直观：
| 对比项 | 套餐做成字段 | 套餐进产品目录 |
|---|---|---|
| 换套餐 | UPDATE customer 覆盖 | 新实例 + 旧实例失效 |
| 查历史 | 没有历史 | 实例生效/失效时间 |
| 加新套餐 | ALTER TABLE | INSERT product_catalog |
| 营销回溯 | 查不到 | 按实例时间筛选 |
对做过 CRM 系统改造的团队来说，这是最熟悉的一幕：一个旧库上线三五年，客户表上挂了十几个产品字段，改造第一步就是“拆列”。设计文档阶段就把套餐拆开，开发阶段就少一次大迁移。如果项目是改造而非新建，建议在文档里单列一节“数据迁移策略”，按“先建目录、再建实例、回填订单、最后删列”的顺序写，评审时才不会觉得拆列只是 DBA 的事。
4. 从 docx 到能开发的系统：渠道、接口与文档结构一次性定清楚
数据模型定完，下一层是“功能怎么走进系统”。这一章要解决三个实际问题：不同渠道怎么接进来、接口契约写多细、docx 本身怎么组织才能从评审走到开发。
4.1 渠道和受理流程：营业厅、外呼、线上怎么共用一套订单
电信 CRM 几乎必然面对多个渠道：营业厅柜台、电话外呼坐席、线上 App 和公众号。设计系统时最忌讳每个渠道各做一套接口、各存一份数据。正确做法是渠道负责“展示和录入”，核心层负责“业务校验和订单创建”。
| 渠道 | 典型场景 | 差异点 |
|---|---|---|
| 营业厅客户端 | 新装、缴费、打印受理单 | 需打印凭证，支持现金 |
| 外呼坐席 | 套餐变更、到期续约 | 需二次确认，留录音 |
| 线上 App/公众号 | 自助查询、在线缴费 | 无人审核，风控校验更严 |
统一的做法是定义一份“受理请求报文”，渠道层把客户证件、产品标识、操作类型、渠道编码、操作人统一交给订单中心。渠道差异放在渠道配置里，不放在业务逻辑里。比如线上需要校验实名、营业厅可以走人工证件核验，这只影响前置校验，不改变订单创建的主流程。订单状态机的设计也要在文档里写明“谁允许改状态”。常见状态是草稿 → 受理 → 施工 → 竣工 → 失效，但每个跳转都要绑一个操作角色或系统，比如“施工”只能由开通激活系统回调触发，“取消”只能由受理岗或系统超时触发。这个表不画清楚，上线后就会出现渠道互相覆盖状态的黑匣子问题。
“永久在线”在这里不是宣传词，而是接口设计约束：账户余额查询、在线缴费、订单状态回写都不能走日终批量。凡是用户能感知到结果的动作，一律设计成实时接口，批量只能用于报表和对账。
4.2 接口契约：把十个字的字段也写进设计文档
评审会上最常被带过的部分是接口。很多文档写“入参：phoneNo、customerType”，写完等于没写。phoneNo 带不带 86 前缀、customerType 传数字还是中文、字段长度多少，这些细节不写死，联调阶段全是玄学。一个合格的接口清单表至少长这样：
| 接口名 | 说明 | 协议 | 入参摘要 | 出参摘要 | 超时 | 错误码 |
|---|---|---|---|---|---|---|
| createOrder | 订单受理 | REST/JSON | customerInfo + productItems | orderId | 10s | 1001 参数缺失 / 1002 产品不可售 |
| queryBalance | 余额查询 | REST/JSON | accountNo | balanceCent + creditLevel | 3s | 2001 账户不存在 |
| payConfirm | 缴费确认 | REST/JSON | accountNo + amountCent | transactionId | 15s | 3001 支付超时 / 3002 余额不足 |
| orderCallback | 竣工回调 | 消息推送 | orderId + actionType | ack | 5s | 4001 重复通知 |
接口文档的关键字段至少要包含字段名、类型、长度、必填、示例值、校验规则。以 phoneNo 为例：类型 string、长度 11–20、必填、示例 13800138000、校验规则“去空格、去 86 前缀、仅保留数字”。一条一条写，程序员的实现成本反而更低。如果嫌手工维护麻烦，可以用脚本把接口清单从数据源批量生成到 docx。下面这段小脚本是我常用的做法，用 python-docx 把元组表格写进文档，省去复制粘贴：
# 用 python-docx 把接口清单生成到设计文档 from docx import Document doc = Document() doc.add_heading('接口清单', level=1) interfaces = [ ("createOrder", "订单受理", "REST/JSON", "customerInfo+productItems", "orderId", "10s", "1001参数缺失"), ("queryBalance", "余额查询", "REST/JSON", "accountNo", "balanceCent", "3s", "2001账户不存在"), ("payConfirm", "缴费确认", "REST/JSON", "accountNo+amountCent", "transactionId", "15s", "3001支付超时"), ("orderCallback", "竣工回调", "MQ", "orderId+actionType", "ack", "5s", "4001重复通知"), ] table = doc.add_table(rows=1, cols=7) table.style = 'Table Grid' hdr = table.rows[0].cells for i, h in enumerate(['接口名', '说明', '协议', '入参', '出参', '超时', '错误码']): hdr[i].text = h for row in interfaces: cells = table.add_row().cells for i, cell in enumerate(row): cells[i].text = cell doc.save('crm_interface_list.docx')这个脚本的逻辑很直白：先建文档，再按表头建一行空表，然后把接口元组逐个填进单元格，最后保存。参数上需要注意 table.style 要选 Word 内置样式，常用 'Table Grid' 最保险；如果接 Excel 维护，可以用 pandas 读出来再转成元组，不要手工在代码里敲大量接口。脚本跑完生成的是纯表格，粘贴进主 docx 后保留样式就行。接口契约越细，开发阶段扯皮越少。
4.3 文档组成与维护：让设计系统.docx 能持续更新
一份能过评审又能指导开发的设计文档，结构大体是八段：现状与问题、建设目标与范围、总体架构与系统边界、业务流程与状态机、数据模型、接口清单、权限矩阵、非功能需求。前两段用于对齐背景，第三段决定系统怎么做，后五段决定代码怎么写。最容易漏的是权限矩阵，很多人把功能列完就收工，结果上线后每个角色能点什么没人说得清。权限矩阵要覆盖渠道维度，营业厅坐席、外呼坐席、线上用户、管理员各一行，功能模块各一列，交叉打勾。
docx 一定要能“持续更新”，不是交完就沉底。我现在的习惯是把 SQL 和接口清单放在代码仓库里维护，用脚本生成文档片段，再合并进主文档；每次表结构变更，先改 SQL 文件，再生成新片段，文档和库不会各说各话。手工一边改库一边改文档，早晚有一天对不上，到那时 docx 反而成了误导开发的元凶。评审时也可以直接说“文档里的 DDL 和仓库 SQL 是同源的”，这会比一句“我会更新文档”可信得多。
5. 电信 CRM 设计系统的避坑清单：五处最容易返工的设计
下面这些坑是 CRM 系统改造项目里反复出现的老朋友，都属于“评审时看着没问题，开发到一半发现要拆地基”的类型。这一章按现象、原因、解决的顺序写，方便你直接对照自己的文档。
5.1 客户和账户合成一张表：看起来省事，算账时全乱
现象：customer 表上直接挂了 balance、debt、credit 三个字段，查询非常方便，一个表搞定所有客户信息。开发到账务模块时，需求说要支持一个人名下两个账户，一个账户由两个家人代付，才发现表结构根本表达不了。
原因：设计者把“客户”和“钱”混为一谈，默认一个客户只能有一个账户，建模时就省掉了账户表。账务规则一变，整张主表都要拆。
解决：严格落地 customer、account、customer_account_rel 三表结构。客户只管身份，账户只管账务，关系表管归属和代付。评审前自测一句话：所有涉及余额、账单的字段，是否都挂在 account_id 上。
5.2 套餐做成一列：每次营销活动都要改表结构
现象：客户表有 broadband_package、mobile_package 两个字段，营销活动一来要加“家庭融合套餐”，又要 ALTER TABLE 加列。换套餐直接 UPDATE，历史套餐查询完全靠日志。
原因：把“用户正在用的产品”当成了静态属性，没有意识到产品是有生命周期的，它会开通、变更、停机和退订。
解决：把所有套餐收进 product_catalog，用户订购后生成 product_instance，实例带生效时间和失效时间。改造时按“先建目录、再建实例、回填订单、最后删列”的顺序迁数据。凡是见到底层表字段里带 package 字样的，都是启动改造的信号。
5.3 只画流程图不画表结构：评审会过了，开发却“自由发挥”
现象：评审会上一堆用例图、流程图、架构图，看着很完整。开发阶段两个工程师各自建表，一张叫 customer，另一张叫 client，字段对不上，联调第一天就吵起来。
原因：评审只看了宏观流程，没人把数据模型当成验收项。写文档的人觉得表结构是 DBA 的事，开发觉得文档没写就可以自己定义。
解决：在评审材料里把“数据模型”设为硬性章节，核心表必须给出 DDL 或字段清单。一开始不用完美，但客户表、账户表、产品实例表、订单表这几张必须有字段级定义，否则文档打回。
5.4 接口字段只有名词没有格式：联调成了玄学
现象：接口文档写“入参 phoneNo、customerType”，开发照着自己的理解写代码。联调时一个传 13800138000，一个传 +86 13800138000；customerType 一边传 1、2，一边传 “personal”“enterprise”。
原因：只写了字段名，没写类型、长度、必填、示例和校验规则。两边都觉得自己没错。
解决：接口清单按 4.2 的字段规则表写全，每个字段带示例值和校验规则。把“电话号先去掉 86 前缀再入库”这类规则写进文档，联调成本能降一半。
5.5 状态机只有图形没有权限：停复机谁来做说不清
现象：流程图里画出“正常 → 停机 → 恢复”的三态迁移，但没写由谁触发。上线后营业厅能点，外呼也能点，线上用户还能自助点，最后停复机记录全是乱的。
原因：设计文档把状态机当成了纯技术图，忘了状态流转是业务动作，必须绑定角色和系统权限。
解决：状态迁移表加上操作角色、触发系统、超时处理三列。例如“暂停 → 恢复”只能由营业厅受理岗发起，线上仅允许本人操作已实名账号；超时未竣工的工单自动流转到异常队列。权限矩阵和状态机要放在同一章节评审，不能分开看。
6. 交付前用这 8 项检查，把“设计系统.docx”变成可施工方案
写完文档不代表方案成立。评审之前，我习惯拿这张表快速自查一遍，八项全过才敢把 docx 发出去。
| 检查项 | 通过标准 |
|---|---|
| 客户与账户分离 | 所有余额、账单字段都引用 account_id，不出现客户的 balance |
| 套餐进目录 | 核心表没有 package 字段，存在 product_instance |
| 订单拆分项 | 一个订单可查多条 order_item，每项独立状态 |
| 账务边界清晰 | 缴费、欠费、账单在账户域，CRM 只触发不代管账务 |
| 接口字段规格 | 关键接口每个字段有类型、长度、必填、示例 |
| 权限矩阵覆盖渠道 | 营业厅、外呼、线上角色可执行动作已列表 |
| 状态迁移可追溯 | 状态变更表带操作人和操作时间，日志有留痕 |
| 非功能留预算 | 高峰受理 TPS、最长超时、实时接口范围已写明 |
自查方法没有技巧，就是拿着表逐行过。最容易翻车的永远是第一项和第二项，因为它们动的是表结构，一旦开工再改就是拆楼。我的习惯是写 docx 的同时把核心 DDL 放进一个可执行的 SQL 文件，评审时现场演示建表。这一手不是为了炫耀，而是逼自己把所有字段在提交前想完整。这套做法在多次 CRM 系统改造项目里帮我保住了不少后悔药，也希望帮到你。
本文还有配套的精品资源，点击获取
