★ FEATURED ARTICLE 简介这是一份面向电信运营商、CRM项目实施团队及企业信息化规划人员的系统设计文档围绕中国电信CRM系统建设进行全景式梳理。内容涵盖系统建设背景与必要性分析、基于原型法的自上而下实施策略、客户需求分析、信息共享与客户细分等设计关键要素并针对现有系统在信息资源利用率、部门协作、客户流失管理、大客户经营分析、潜在客户开发等方面的短板提出明确改进方向与落地路径。文档既阐述CRM作为管理理念与软件技术的双重属性也给出分阶段、分步骤推进的系统建设建议可直接用于方案编写、需求梳理或项目规划参考帮助读者快速把握电信CRM系统设计的核心框架与实施重点。资源为单个docx文档压缩包约264KB内容结构完整、条理清晰适合学习借鉴。已有328人浏览学习具有较高参考价值。1. 中国电信CRM设计系统docx先想清楚这是一张业务蓝图不是一篇作文拿到《中国电信客户关系管理(CRM)设计系统.docx》这个标题很多人第一反应是打开Word找模板。真正做过运营商项目的人会告诉你这份文档最难的不是排版而是你有没有把电信业务独有的三户模型讲清楚。客户、账户、用户三者关系捋不顺后面的数据模型、流程设计、接口定义全是空中楼阁评审会上被业务一句话就能问倒。这篇文章按我自己做电信BSS项目的习惯把一份能过评审、能指导开发落地的CRM设计系统文档拆开讲业务域怎么分、数据模型怎么建、核心流程怎么画状态机、docx本身怎么编排才不挨骂外加五个我踩过不止一次的坑。适合正在写课程设计或毕业设计的学生也适合要出系统方案给客户评审的产品经理和售前。你不用懂Java也能跟下来但如果你会读SQL收获会更大。2. 从业务域到数据模型电信CRM的骨架怎么搭写设计系统的第一件事不是画架构图是划分业务域。我一般把电信CRM拆成四个域客户域管谁在用产品域管卖什么订单域管怎么卖出去工单触点域管谁来服务。计费账务单独划出去这一点后面专门说。域分清楚了ER图、功能模块、菜单结构就都有了挂靠的地方评审人也知道该去哪里找他要的内容。很多人上来先画一张 Spring Boot Vue 的技术架构图结果业务域没定义评审人看完只知道你用了微服务不知道这套系统到底管什么。2.1 三户模型客户、账户、用户为什么要分开建模三户模型是电信CRM区别于普通电商CRM的根本。客户Customer是法律意义上的签约人账户Account是账单和付费的归属实体用户Subscriber才是真正使用业务的那个标识——手机号、宽带账号、固话号码。举一个最常见的家庭场景张三作为户主签了一份融合套餐。客户是张三账户是这个家庭每月的账单归属用户是名下的两个手机号加一条宽带。欠费停机时是按账户停还是按用户停正确答案是账户级冻结账户下所有用户一起停。你要是把三户拍平成一张客户表这个逻辑在数据模型层面根本表达不出来。-- 客户表签约主体个人或企业 CREATE TABLE cust ( cust_id VARCHAR2(32) PRIMARY KEY, -- 客户编号全局唯一 cust_name VARCHAR2(128) NOT NULL, -- 客户名称 cust_type CHAR(1) NOT NULL, -- 1个人 2政企 cert_type CHAR(2), -- 证件类型 cert_no VARCHAR2(64), -- 证件号码 create_date DATE DEFAULT SYSDATE ); -- 账户表账单与付费主体一个客户可挂多个账户 CREATE TABLE acct ( acct_id VARCHAR2(32) PRIMARY KEY, cust_id VARCHAR2(32) NOT NULL, -- 归属客户 acct_type CHAR(1) DEFAULT 1, -- 1个人账户 2企业账户 pay_method CHAR(1), -- 支付方式 status CHAR(1) DEFAULT 1, -- 账户状态 CONSTRAINT fk_acct_cust FOREIGN KEY (cust_id) REFERENCES cust(cust_id) ); -- 用户表业务使用标识手机号或宽带账号 CREATE TABLE subs ( subs_id VARCHAR2(32) PRIMARY KEY, acct_id VARCHAR2(32) NOT NULL, -- 归属账户 access_no VARCHAR2(32) NOT NULL, -- 接入号手机号/固话/宽带账号 product_id VARCHAR2(32), -- 订购的产品 status CHAR(1) DEFAULT 1, -- 有效状态 CONSTRAINT fk_subs_acct FOREIGN KEY (acct_id) REFERENCES acct(acct_id) );建表顺序是 cust → acct → subs外键全部向下引用。这样设计的一个直接好处是做客户360视图时三张表 JOIN 就能拿到一个客户名下有哪几个账户、每个账户挂了哪些号码而不是在一张大表里用冗余字段硬凑。字段说明里我特意标注了 access_no 是接入号而不是手机号因为宽带账号、固话也是 access_no命名语义要能覆盖全部业务类型。提示设计文档里凡是出现客户手机号客户宽带账号这种把实体合并的写法评审时我都会打回去。字段归属实体不清开发建表必乱。2.2 产品目录与订购把套餐变成可配置的销售品很多初次写电信CRM的人分不清产品和销售品。产品Product是原子能力比如宽带接入、语音通话、流量包销售品Offer是面向客户的可售组合比如全家享199元套餐。同一个产品可以被十几个销售品引用同一个销售品也可以包含多个产品加优惠。这个区分直接决定订购模块怎么设计。如果设计文档里只有一张套餐表那运营一上促销活动开发就得改表结构、改代码然后被业务追着骂。正确做法是把产品目录设计成可配置的层次结构。-- 销售品表可售的套餐/优惠组合 CREATE TABLE offer ( offer_id VARCHAR2(32) PRIMARY KEY, offer_name VARCHAR2(128) NOT NULL, -- 销售品名称 offer_type CHAR(1), -- 1基础产品 2组合套餐 3优惠 price NUMBER(10,2), -- 标准价格 status CHAR(1) -- 上下架状态 ); -- 销售品与产品的关系表一个销售品包含多个基础产品 CREATE TABLE offer_prod_rel ( rel_id VARCHAR2(32) PRIMARY KEY, offer_id VARCHAR2(32) NOT NULL, -- 销售品ID product_id VARCHAR2(32) NOT NULL, -- 产品ID effective_date DATE, -- 生效日期 expire_date DATE -- 失效日期 );两个关键参数要特别说明。effective_date 和 expire_date 控制产品和销售品的有效期这直接决定了一个老套餐到期后已订购客户还能不能续费新客户能不能下单。很多翻车现场都是因为文档里漏了有效期设计导致老套餐下架时存量用户跟着遭殃。另外 offer_type 里我把优惠单独列出来因为优惠往往是限时叠加的和普通套餐的生命周期管理完全不同。2.3 CRM与计费账务的边界哪些需求不能写进这份文档这是评审会上最容易被拍砖的地方。需求方经常把所有BSS业务支撑系统需求都叫成CRM于是设计文档里混进了出账规则、账单打印模板、月租计算逻辑。这种混写会导致文档范围失控而且评审时会被反问CRM要是算月租那计费系统干什么我的做法是在文档第二章就放一张边界表明确这份文档管什么、不管什么能力域归属系统本文档处理方式客户/产品/订单受理CRM详细设计促销活动配置CRM营销模块详细设计月结出账、账单生成计费账务系统只约定接口不展开缴费、销账收费系统只约定接口欠费停机管控信控系统引用外部规则装维施工工单调度系统流程协同设计边界表的价值不只是给评审人看更是给开发团队看的。它告诉后端团队哪些表归你建哪些表你只能调用接口。我在实际项目里见过最迷惑的代码就是CRM服务里自己写了个定时任务去生成账单——因为设计文档没写边界开发顺手就把账务逻辑实现了。2.4 触点与工单协同营业厅、装维、客服共享一份客户视图电信CRM的触点比一般企业系统多得多营业厅坐席是B/S端装维师傅用的是手机App客服在呼叫中心还有网上营业厅和自助终端。设计文档里必须有一节专门讲触点协同核心诉求是所有触点看到的是同一份客户360视图。装维场景最能说明问题。师傅上门装宽带扫设备条形码、扫用户装机地址现场拍照回传这就是现在常见的crm管理系统结合扫码采集落地形态。设计上需要明确扫码采集的数据走移动端安全接入通道回传设备编码回传后自动关联订单和客户ID师傅端只看到工单关联的客户信息证件号码要做脱敏展示。触点的数据权限矩阵建议用表格收敛否则后期上线必出权限事故触点使用人数据范围典型操作营业厅坐席营业员本区域全量客户开户、变更、销户受理装维App装维师傅仅本人工单关联客户扫码采集、回单客服工作台客服全量客户证件脱敏查询、外呼、工单发起网上营业厅客户本人仅本人名下自助查询、缴费工单是订单在服务环节的延伸。订单进入施工状态后生成装维工单工单回单触发订单状态流转。文档里要定义工单与订单的关联字段order_id 是必填外键并说明一个订单可以拆成多个工单的场景——比如宽带加IPTV同时施工就拆成两条工单。这一步不写清楚开发阶段就会争议工单到底算订单的子表还是独立表。3. 把设计装进docx章节骨架、字段字典与排版规范系统设计做完了接下来是把设计装进docx。这一章是很多人最容易糊弄的但恰恰是评审体验的关键。一份排版混乱的文档哪怕内容是对的评审人也只会觉得这人还没想清楚。3.1 设计文档的章节骨架八段式结构我写这类设计系统文档固定用八段式结构覆盖从背景到落地的完整链路章节内容评审人关注点1 引言背景、目标、范围、术语表范围和术语是否一致2 总体架构逻辑架构、部署架构、技术选型架构是否合理、是否过度设计3 功能设计按业务域拆模块、用例功能是否覆盖需求4 数据设计ER图、字段字典字段是否完整、命名是否规范5 接口设计系统间接口清单、报文边界是否清晰6 非功能需求性能、安全、可用性指标是否可度量7 实施计划里程碑、分工排期是否现实8 附录评审记录、变更记录留痕是否完整术语表这一节很多人不写但在电信项目里几乎必被问。客户、账户、用户、销售品、产品、工单、竣工——这些词在不同人口中含义完全不同。我见过评审会上业务方说用户指的是手机号开发说用户指的是登录账号吵了十分钟才对齐。术语表放在第一章评审前先花两分钟过一遍能省掉大量无效争论。3.2 字段字典表实体属性的唯一事实来源ER图只画实体和关系字段定义必须以字段字典为准。字段字典是设计文档的唯一事实来源开发建表、前端表单、接口报文全部以它为准。前后端对字段有疑问先查字典查不到再讨论而不是各说各话。字段名类型长度必填默认值业务说明cust_idVARCHAR232是无客户编号全局唯一cust_nameVARCHAR2128是无客户名称cust_typeCHAR1是11个人 2政企cert_noVARCHAR264否无证件号码脱敏展示statusCHAR1是10失效 1有效命名规范要写死在文档前面一律小写下划线禁止大小写混用主键统一叫 xxx_id状态字段统一用 CHAR(1) 并注释枚举含义时间字段统一 DATE 类型。这些规则看起来琐碎但能避免联调时他这张表叫 custId我那张表叫 customer_id的经典惨剧。3.3 Word排版规范让评审人十分钟找到他想找的docx 的排版规范不需要花哨核心是可导航、可追踪。我一般要求文档满足以下几条硬性规则第一标题必须用 Word 内置的标题1/标题2/标题3样式禁止手动调字号加粗。只有用了内置样式导航窗格和自动目录才能工作评审人才能按目录跳转。第二多级编号用 1 / 1.1 / 1.1.1 的自动编号不要手打数字否则中间插入一章后面全部要手动改。第三所有流程图统一用 draw.io 或 Visio 导出 PNG画布大小统一禁止截图糊成一片。第四表格统一样式字段字典表、状态表、接口清单的列头格式保持一致。还有一条很多人忽略交付时同时给 docx 和 PDF。docx 给项目组做批注修订PDF 给评审人和外部专家防止格式漂移。Word 在不同版本间打开字体和行距会变PDF 不会。3.4 版本管理与评审意见留痕设计文档不是写一次就完事它要跟着评审迭代。文档第一页必须放版本记录表版本日期修改人修改说明v1.02024-06-01张三初稿v1.12024-06-08李四按第一轮评审意见修订数据模型v2.02024-06-15张三增加接口设计章节文件名规范建议CRM设计系统_v2.0_20240615.docx。版本号加日期杜绝最终版最终版2打死不改版这种命名。评审意见留痕用意见表每次评审一张序号、原文位置、评审意见、处理结果接受/拒绝/延后、责任人。不要口头改完就算了没有留痕的评审等于没评。回头出了争议意见表就是决策依据。4. 核心流程的状态机设计开户、变更、销户三条主线CRM的功能设计里开户、变更、销户是绕不开的三条主线。很多文档在这部分画三张粗箭头流程图就结束了评审时看着没问题开发做起来全是窟窿。我的建议是流程必须落到状态机把每个状态的合法转移和异常分支写死。4.1 开户流程选品→订单→施工→竣工的状态机开户不是营业员点一下保存就完事。一个典型的宽带开户要经历选品、下单、受理、派单施工、竣工确认五个阶段。设计文档里用状态机表表达比流程图画得清楚得多当前状态触发动作下一状态责任人待受理客户提交订单已受理营业员已受理系统派发施工施工中系统施工中装维回单已竣工装维师傅施工中装维上报失败施工失败装维师傅施工失败改派重试施工中调度系统已竣工系统归档已归档系统待受理/已受理客户撤销已取消营业员状态机表之后我习惯再配一段极简的状态转移校验代码目的是告诉开发状态流转要写合法性校验不能随意跳转# 开户订单状态机合法转移关系开发照此实现校验逻辑 ALLOWED_TRANSITIONS { 待受理: [已受理, 已取消], 已受理: [施工中, 已取消], 施工中: [已竣工, 施工失败], 施工失败: [施工中, 已取消], # 改派重试或最终取消 已竣工: [已归档], } def can_transit(current: str, target: str) - bool: return target in ALLOWED_TRANSITIONS.get(current, [])这段代码的核心逻辑是当前状态只能转移到白名单里的目标状态其他一律非法。有了这张白名单开发就不会写出已竣工还能改回施工中这种匪夷所思的代码。竣工动作要同时触发设备开通指令这个细节也要在文档里写明状态机只负责订单状态真正的业务动作挂在转移边上。4.2 变更流程订单拆分、回退与异步写卡变更比开户更容易翻车因为一次变更往往涉及多个动作。比如客户申请换套餐加装副卡表面上是一个请求实际拆成三个子订单套餐变更单、副卡开卡单、写卡单。设计文档里必须定义订单拆分规则。子订单类型业务动作完成标志套餐变更单旧销售品失效、新销售品生效生效时间到达副卡开卡单新增一个用户标识并关联账户用户状态变为有效写卡单SIM卡写号写卡设备返回成功回退规则是和拆分同样重要的设计点。主订单回退时子订单怎么处理我的习惯是定义级联回退主订单取消所有未竣工的子订单自动作废已竣工的保持不变但生成反向单。这块如果文档里不写开发遇到回退场景就会各自为政有的删数据有的改状态最后数据全对不上。异步写卡是一个经常被忽视的设计点。写卡是外部设备操作耗时且可能失败所以不能放在订单受理的事务里同步做。设计上应该是受理成功先落库订单状态保持已受理写卡结果通过回调或轮询更新。文档里写明异步执行、失败可重试这八个字后端团队就不会把写卡写进主事务。4.3 销户流程欠费校验、在途单拦截与挽留销户是三条主线里最敏感的一条直接关系到客户资产和收入。设计文档里要把销户的校验顺序写清楚顺序错了就是事故第一步校验在途订单。客户名下还有未竣工的工单或未完成的变更单不能直接销户系统提示存在在途业务。第二步校验欠费。有欠费的客户引导先缴费这里只做校验不处理账务缴费走收费系统接口。第三步确认销户。客户确认后账户状态改为冻结所有关联用户停用。第四步触发拆机工单。装维上门拆设备回单后账户归档。第五步挽留。高价值客户在确认环节插入挽留流程派发外呼工单给客服。挽留这条线很多设计文档完全没写。实际运营中销户确认页面弹一个为您保留号码的挽留提示能留下相当比例的离网客户。文档里至少要有触发条件客户价值等级高于阈值、执行方式生成挽留工单给客服、超时处理48小时未联系则继续销户流程。5. 电信CRM设计文档的5个高频踩坑点以下五个坑来自我实际做过的电信项目每条都按现象到原因再到解决写清楚。这些坑的共同点是评审会上看不出来开发阶段集体遭殃。5.1 三户模型被拍平成一张大表现象设计文档的ER图里只有一张客户表字段里同时塞了客户名称、手机号、宽带账号、账单地址、欠费金额。原因写文档的人拿普通电商CRM的经验套电信业务没理解三户模型的业务语义。解决文档里强制画三户关系图客户、账户、用户三张表必须分开并在数据设计章节说明账户冻结则关联用户全部停用这条业务规则。评审时我把这条列为必查项。5.2 计费账务需求混进CRM设计文档现象文档的功能设计里出现了月租自动扣费账单打印模板滞纳金计算这些内容。原因需求方把所有BSS需求都叫CRM写文档的人照单全收。解决在文档总体架构里放一张系统边界表明确CRM负责受理和客户管理计费账务只做接口约定。一旦发现功能清单里有账务类需求直接划到接口设计章节或者明确不在本系统范围。5.3 流程图只画happy path现象开户流程图从选品画到竣工一路到底没有回退分支。开发实现时发现客户中途撤销、施工失败、设备缺货统统没有状态定义。原因画图时只沿着正常流程走了一遍没有逐节点问这里失败了怎么办。解决每个流程节点旁边标注异常分支用状态机表兜底。我在文档里有一句硬性要求凡是流程图涉及状态变化必须附状态机表没有状态机的流程设计不予评审。5.4 字段字典与ER图对不上现象ER图里实体叫 user_id字段字典里同一个字段叫 subs_id开发按ER图建表前端照着字段字典做接口联调时对不上。原因多人协作图和字典各改各的没有做一致性检查。解决交付前用脚本从docx里提取两处定义逐一比对。具体做法下一章展开核心原则是图和数据字典必须出自同一版本且由同一个人负责维护。5.5 权限设计漏掉渠道隔离和扫码采集现象装维师傅拿着手机App能查到客户的完整证件号和付费账户信息。原因权限只按角色设计没按渠道数据范围设计。装维角色和营业员角色都配了客户查询权限但没有区分数据边界。解决文档里加触点权限矩阵按触点×角色×数据范围三要素定义。装维App的数据范围限定为仅本人工单关联客户且证件号、银行卡必须脱敏扫码采集只回传设备编码和定位信息不拉取客户全量资料。6. 交付前最后一道工序用字段字典反向校验设计文档写到最后别急着发出去。我每次交付前都会做一道反向校验工序专门抓文档自相矛盾的问题。第一步从ER图里抽出所有实体清单列成一张Excel每个实体一行。第二步打开字段字典逐个实体核对字段是否齐全。重点查三件事主键有没有定义、外键有没有指向、状态字段的枚举值有没有写注释。第三步核对命名一致性——ER图里的实体名和字典里的表名必须完全一致差一个下划线都算不合格。第四步把这份核对表附在文档附录里评审人可以自己复核。这道工序抓出过不少问题。有一次我发现字段字典里 subs 表有 acct_id但ER图里这两张实体之间没画关系线——开发照着ER图建表外键就漏了。这种问题靠人眼很难发现所以我还习惯用脚本做一次docx的标题层级检查from docx import Document doc Document(中国电信客户关系管理(CRM)设计系统.docx) last_level 0 for p in doc.paragraphs: if p.style.name.startswith(Heading): level int(p.style.name.split()[-1]) # Heading 1 - 1 if last_level and level last_level 1: print(f标题层级跳跃: {p.text} ({p.style.name})) last_level level这段代码用 python-docx 读取文档里的段落样式找出标题1直接跳到标题3的层级断层。如果你用的是Java技术栈原理一样用 Apache POI 遍历 XWPFParagraph检查 getStyle() 的样式名再按段落顺序做层级比较。目的不是炫技是保证目录结构干净——我见过一份设计文档的目录里同一层级的标题有三种不同格式评审人翻目录就失去了耐心。除了脚本检查还有一个懒办法很管用找一位没参与过前期讨论的同事只给文档和一份开户流程走查清单让他按文档内容模拟走一遍开户、变更、销户。他卡在哪哪里就是文档的缺口。这个方法我每次都用每次都能逮到一两个我以为写清楚了其实没写的地方。最后提醒一句字段字典是文档的锚点ER图、接口报文、测试用例全部要向它对齐。这个反向校验的工序我已经养成习惯它帮我避免了好几次上线前一天才发现字段对不上的尴尬。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
