简介中国电信客户关系管理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 TABLEINSERT product_catalog营销回溯查不到按实例时间筛选对做过 CRM 系统改造的团队来说这是最熟悉的一幕一个旧库上线三五年客户表上挂了十几个产品字段改造第一步就是“拆列”。设计文档阶段就把套餐拆开开发阶段就少一次大迁移。如果项目是改造而非新建建议在文档里单列一节“数据迁移策略”按“先建目录、再建实例、回填订单、最后删列”的顺序写评审时才不会觉得拆列只是 DBA 的事。4. 从 docx 到能开发的系统渠道、接口与文档结构一次性定清楚数据模型定完下一层是“功能怎么走进系统”。这一章要解决三个实际问题不同渠道怎么接进来、接口契约写多细、docx 本身怎么组织才能从评审走到开发。4.1 渠道和受理流程营业厅、外呼、线上怎么共用一套订单电信 CRM 几乎必然面对多个渠道营业厅柜台、电话外呼坐席、线上 App 和公众号。设计系统时最忌讳每个渠道各做一套接口、各存一份数据。正确做法是渠道负责“展示和录入”核心层负责“业务校验和订单创建”。渠道典型场景差异点营业厅客户端新装、缴费、打印受理单需打印凭证支持现金外呼坐席套餐变更、到期续约需二次确认留录音线上 App/公众号自助查询、在线缴费无人审核风控校验更严统一的做法是定义一份“受理请求报文”渠道层把客户证件、产品标识、操作类型、渠道编码、操作人统一交给订单中心。渠道差异放在渠道配置里不放在业务逻辑里。比如线上需要校验实名、营业厅可以走人工证件核验这只影响前置校验不改变订单创建的主流程。订单状态机的设计也要在文档里写明“谁允许改状态”。常见状态是草稿 → 受理 → 施工 → 竣工 → 失效但每个跳转都要绑一个操作角色或系统比如“施工”只能由开通激活系统回调触发“取消”只能由受理岗或系统超时触发。这个表不画清楚上线后就会出现渠道互相覆盖状态的黑匣子问题。“永久在线”在这里不是宣传词而是接口设计约束账户余额查询、在线缴费、订单状态回写都不能走日终批量。凡是用户能感知到结果的动作一律设计成实时接口批量只能用于报表和对账。4.2 接口契约把十个字的字段也写进设计文档评审会上最常被带过的部分是接口。很多文档写“入参phoneNo、customerType”写完等于没写。phoneNo 带不带 86 前缀、customerType 传数字还是中文、字段长度多少这些细节不写死联调阶段全是玄学。一个合格的接口清单表至少长这样接口名说明协议入参摘要出参摘要超时错误码createOrder订单受理REST/JSONcustomerInfo productItemsorderId10s1001 参数缺失 / 1002 产品不可售queryBalance余额查询REST/JSONaccountNobalanceCent creditLevel3s2001 账户不存在payConfirm缴费确认REST/JSONaccountNo amountCenttransactionId15s3001 支付超时 / 3002 余额不足orderCallback竣工回调消息推送orderId actionTypeack5s4001 重复通知接口文档的关键字段至少要包含字段名、类型、长度、必填、示例值、校验规则。以 phoneNo 为例类型 string、长度 11–20、必填、示例 13800138000、校验规则“去空格、去 86 前缀、仅保留数字”。一条一条写程序员的实现成本反而更低。如果嫌手工维护麻烦可以用脚本把接口清单从数据源批量生成到 docx。下面这段小脚本是我常用的做法用 python-docx 把元组表格写进文档省去复制粘贴# 用 python-docx 把接口清单生成到设计文档 from docx import Document doc Document() doc.add_heading(接口清单, level1) interfaces [ (createOrder, 订单受理, REST/JSON, customerInfoproductItems, orderId, 10s, 1001参数缺失), (queryBalance, 余额查询, REST/JSON, accountNo, balanceCent, 3s, 2001账户不存在), (payConfirm, 缴费确认, REST/JSON, accountNoamountCent, transactionId, 15s, 3001支付超时), (orderCallback, 竣工回调, MQ, orderIdactionType, ack, 5s, 4001重复通知), ] table doc.add_table(rows1, cols7) 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 13800138000customerType 一边传 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 系统改造项目里帮我保住了不少后悔药也希望帮到你。本文还有配套的精品资源点击获取
电信CRM设计系统：核心域、数据模型与文档落地要点
简介中国电信客户关系管理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 TABLEINSERT product_catalog营销回溯查不到按实例时间筛选对做过 CRM 系统改造的团队来说这是最熟悉的一幕一个旧库上线三五年客户表上挂了十几个产品字段改造第一步就是“拆列”。设计文档阶段就把套餐拆开开发阶段就少一次大迁移。如果项目是改造而非新建建议在文档里单列一节“数据迁移策略”按“先建目录、再建实例、回填订单、最后删列”的顺序写评审时才不会觉得拆列只是 DBA 的事。4. 从 docx 到能开发的系统渠道、接口与文档结构一次性定清楚数据模型定完下一层是“功能怎么走进系统”。这一章要解决三个实际问题不同渠道怎么接进来、接口契约写多细、docx 本身怎么组织才能从评审走到开发。4.1 渠道和受理流程营业厅、外呼、线上怎么共用一套订单电信 CRM 几乎必然面对多个渠道营业厅柜台、电话外呼坐席、线上 App 和公众号。设计系统时最忌讳每个渠道各做一套接口、各存一份数据。正确做法是渠道负责“展示和录入”核心层负责“业务校验和订单创建”。渠道典型场景差异点营业厅客户端新装、缴费、打印受理单需打印凭证支持现金外呼坐席套餐变更、到期续约需二次确认留录音线上 App/公众号自助查询、在线缴费无人审核风控校验更严统一的做法是定义一份“受理请求报文”渠道层把客户证件、产品标识、操作类型、渠道编码、操作人统一交给订单中心。渠道差异放在渠道配置里不放在业务逻辑里。比如线上需要校验实名、营业厅可以走人工证件核验这只影响前置校验不改变订单创建的主流程。订单状态机的设计也要在文档里写明“谁允许改状态”。常见状态是草稿 → 受理 → 施工 → 竣工 → 失效但每个跳转都要绑一个操作角色或系统比如“施工”只能由开通激活系统回调触发“取消”只能由受理岗或系统超时触发。这个表不画清楚上线后就会出现渠道互相覆盖状态的黑匣子问题。“永久在线”在这里不是宣传词而是接口设计约束账户余额查询、在线缴费、订单状态回写都不能走日终批量。凡是用户能感知到结果的动作一律设计成实时接口批量只能用于报表和对账。4.2 接口契约把十个字的字段也写进设计文档评审会上最常被带过的部分是接口。很多文档写“入参phoneNo、customerType”写完等于没写。phoneNo 带不带 86 前缀、customerType 传数字还是中文、字段长度多少这些细节不写死联调阶段全是玄学。一个合格的接口清单表至少长这样接口名说明协议入参摘要出参摘要超时错误码createOrder订单受理REST/JSONcustomerInfo productItemsorderId10s1001 参数缺失 / 1002 产品不可售queryBalance余额查询REST/JSONaccountNobalanceCent creditLevel3s2001 账户不存在payConfirm缴费确认REST/JSONaccountNo amountCenttransactionId15s3001 支付超时 / 3002 余额不足orderCallback竣工回调消息推送orderId actionTypeack5s4001 重复通知接口文档的关键字段至少要包含字段名、类型、长度、必填、示例值、校验规则。以 phoneNo 为例类型 string、长度 11–20、必填、示例 13800138000、校验规则“去空格、去 86 前缀、仅保留数字”。一条一条写程序员的实现成本反而更低。如果嫌手工维护麻烦可以用脚本把接口清单从数据源批量生成到 docx。下面这段小脚本是我常用的做法用 python-docx 把元组表格写进文档省去复制粘贴# 用 python-docx 把接口清单生成到设计文档 from docx import Document doc Document() doc.add_heading(接口清单, level1) interfaces [ (createOrder, 订单受理, REST/JSON, customerInfoproductItems, orderId, 10s, 1001参数缺失), (queryBalance, 余额查询, REST/JSON, accountNo, balanceCent, 3s, 2001账户不存在), (payConfirm, 缴费确认, REST/JSON, accountNoamountCent, transactionId, 15s, 3001支付超时), (orderCallback, 竣工回调, MQ, orderIdactionType, ack, 5s, 4001重复通知), ] table doc.add_table(rows1, cols7) 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 13800138000customerType 一边传 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 系统改造项目里帮我保住了不少后悔药也希望帮到你。本文还有配套的精品资源点击获取