拓冰网站定制 
简介这是一份面向电信行业CRM项目规划者、产品经理、系统分析师及高校相关专业学生的设计方案文档以中国电信为背景系统梳理客户关系管理系统的建设动因、核心设计要素与实施路径。文档从“以客户为中心”出发覆盖客户需求分析、客户分类与细分、个性化服务、决策支持等关键模块并结合九七工程遗留问题剖析现有客户信息资源利用不足、部门协作不畅、客户流失缺乏管控等痛点给出原型法式自上而下、分阶段推进的落地建议也明确了从管理层提出建设性要求、循环迭代完善系统的具体做法。压缩包内为1个docx文档整体264KB内容密度高、结构完整。已有328人学习下载适合需要快速建立CRM系统整体认知、撰写设计方案或进行电信业务信息化研究的人员使用。1. 中国电信CRM设计系统一份docx文档背后要扛起的业务与改造在电信营业厅或者呼叫中心待过的人都有一个共同体验查一个客户的资料要在BOSS系统、计费系统、电子渠道后台之间来回切换客户在系统A里是停机状态在系统B里却还能正常订购套餐。所谓中国电信客户关系管理(CRM)设计系统就是把你手头这份以docx形式存在的设计文档从画几张用例图、写几段需求描述推进到能指导开发的完整设计方案。它要回答的不是CRM是什么而是电信业务里客户、产品、订单、账务这四层数据怎么建模功能模块怎么拆跟BOSS和计费系统的边界画在哪。这份文档适合正在做毕业设计的学生、接电信行业CRM改造项目的乙方团队以及企业内部要重构旧CRM的产品经理——照着它把业务模型立住后面开发才不会翻车。2. 先把业务模型立住电信CRM的客户、产品、订单、账务四层关系2.1 为什么电信CRM不能照搬快消行业的客户表结构做过零售CRM的人都知道一套用户表订单表商品表就能跑通大多数场景。但电信行业拿这套模型直接套第一轮需求评审就过不去。原因在于电信业务里客户和业务使用者是分离的一个家庭客户户主身份证名下挂了宽带、两部手机、一部固话缴费的是户主用业务的是全家。如果按快消思路把一个手机号当成一个客户那这个家庭就被拆成四个孤岛营销活动和账单对账全乱套。所以电信CRM做客户模型第一条原则就是客户、账户、业务实例三者分离。客户是自然人或法人账户是缴费和账单的载体业务实例是具体的电话号码、宽带账号。一个客户可以拥有多个账户一个账户可以挂多个业务实例。这套模型在电信行业叫三户模型不只在CRM里用BOSS系统也是按这个逻辑建的设计文档第一张ER图必须画清楚这个三角关系。提示评审时先问一句客户表主键是身份证号还是客户ID。用身份证号做主键携号转网和证件变更场景直接卡死。主键必须用自生成的客户ID证件号只做校验条件。2.2 客户360视图从客户主表到四张扩展表的拆分客户360视图是CRM设计文档里最常被提到的概念但多数文档停留在画一个雷达图中间放客户头像的程度。落到数据库层面客户域至少要拆成客户主表、证件信息表、联系信息表、客户等级表四张。主表只放稳定属性联系信息单独拆表是因为一个客户可能有多个手机号、多个地址而且联系人信息变更频繁混在主表里会导致表膨胀和历史追溯困难。-- 客户主表只放稳定属性不存地址和联系方式 CREATE TABLE cust_main ( cust_id VARCHAR(32) PRIMARY KEY COMMENT 客户ID全局唯一不随证件变更, cust_name VARCHAR(64) COMMENT 客户姓名或单位名称, cust_type TINYINT COMMENT 1-个人 2-家庭 3-政企, cert_type TINYINT COMMENT 证件类型1-身份证 2-护照 3-营业执照, cert_no VARCHAR(32) COMMENT 证件号码只做查询条件不做主键, emp_id VARCHAR(16) COMMENT 归属客户经理工号, channel_code VARCHAR(16) COMMENT 注册渠道编码, create_time DATETIME, update_time DATETIME, KEY idx_cert (cert_type, cert_no), KEY idx_emp (emp_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段DDL里最重要的一条设计是cert_no不设唯一索引。真实业务里一个证件号可能对应多个客户ID——历史数据清洗不干净、政企客户多级联系人持有同一证件的情况都有唯一索引一加数据同步直接报错。cust_type字段要预留即使第一期只做个人客户也要预埋家庭和政企的类型值不然第二期改造表结构成本极高。2.3 电信产品是组合套餐不是商品产品域这样建模快消行业的商品表一条记录一个SKU电信行业要是这么干一个5G融合套餐就够你建二十条SKU。电信产品的核心特征是包装一个销售品比如159元融合套餐内部包含了流量包、语音包、宽带、副卡权益、视频会员多个子项每个子项还可能叠加促销优惠比如首年打七折。产品域建模我用三层结构产品目录层、销售品层、产品实例层。产品目录是静态的资费定义销售品是面向渠道和客户的可售单元产品实例是客户实际订购后生成的记录要关联到具体的业务实例手机号、宽带账号。这样设计的直接好处是改资费不动客户数据一个销售品下架不影响已订购客户的实例有效性。设计文档里产品域至少要覆盖两个状态机销售品生命周期设计中→可售→在售→下架和产品实例生命周期订购→生效→变更→退订。很多设计文档漏了后者开发同学只能自己拍脑袋定义状态后期做订单追溯的时候状态值对不上是常事。2.4 订单与账务受理单状态机和与计费系统的对账边界订单域在电信CRM里叫受理单跟电商订单差别很大。一个电商订单就买一件商品一个电信受理单可能同时包含新装宽带、办副卡、换套餐三个动作每个动作在后台对应独立的订单项分别走不同的激活流程。设计文档里受理单要拆受理单头和受理单项两级订单项状态机独立流转。账务是电信CRM最容易踩坑的域。我的建议是CRM不做账务计算只做账单展示和缴费记录同步。出账、优惠计算、滞纳金生成都是计费系统的职责CRM通过接口把账单和缴费流水同步过来存到查询用表里。这样划分的依据是电信行业的系统职责边界——计费系统是算账的CRM是看账的硬要在CRM里做账务计算月底出账高峰那几天CRM的数据库IO会被查询拖垮。3. 功能模块落成设计文档从客户管理到经营分析怎么拆分3.1 客户信息管理与客户分群标签体系和客户等级怎么落地客户信息管理模块不只是增删改查。电信客户分群要支撑后续营销活动所以在客户主表之上还要建一张客户标签表。标签分两类事实标签和计算标签。事实标签是明确属性比如政企客户宽带用户5G套餐用户计算标签是靠规则算出来的比如高流失风险客户高价值客户。设计文档里要写明每个标签的口径定义否则同一个客户在三个报表里三个状态。客户等级建议用一张独立等级表不要写死在客户主表的字段里。等级是会被调整的——大客户经理申请把某政企客户从普通升到VIP审批通过后更新等级表。等级表的生效时间和失效时间两个字段必须有不然历史等级追溯做不了。-- 客户标签表一个客户多条记录标签类型区分事实/计算 CREATE TABLE cust_tag ( cust_id VARCHAR(32) NOT NULL, tag_code VARCHAR(32) NOT NULL COMMENT 标签编码, tag_type TINYINT COMMENT 0-事实标签 1-计算标签, tag_value VARCHAR(64) COMMENT 标签值如流失风险高, source_sys VARCHAR(16) COMMENT 来源系统CRM/BOSS/数据仓库, tag_eff_dt DATE COMMENT 生效日期, tag_exp_dt DATE COMMENT 失效日期, PRIMARY KEY (cust_id, tag_code, tag_eff_dt) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;标签表设计成按tag_code和tag_eff_dt做联合主键就是允许客户在一个时间段内因规则调整被重新打标签旧记录保留、新记录插入。很多团队把标签做成覆盖式更新跑完当天批量任务历史就没了后面做流失分析根本拉不出上个月这批客户到底是什么状态。3.2 产品订购与受理工单订单生命周期必须画到泳道级产品订购模块是电信CRM的核心交易入口。设计文档里这个模块的灵魂是受理流程的泳道图——不是画一个从选择套餐到确认订单的线性箭头而是要画出CRM、计费系统、网络激活系统、施工调度系统四个参与方各自的动作。常见的翻车点是CRM提交订单后计费系统已经生效了但网络激活系统失败了这时候订单状态应该回退还是置为半生效行业内的一致做法是引入预受理状态订单先不生效,等所有下游系统返回成功才置为已竣工任何一个失败都走人工介入。订单状态至少要有这七个待受理、受理中、已生效、已竣工、退订中、已退订、失败。要给每个状态定义超时时间比如受理中超过两小时未竣工自动告警。很多二次开发的CRM项目把状态砍到四个上线后工单积压在处理中没人发现就是少了超时机制这一层。销售系统与受理工单的联动也在这个模块实现——渠道经理录入一个商机转化为受理单后自动挂到对应客户名下商机的预计金额、签约概率这些字段能反过来帮销售跟踪丢单原因。我一般建议设计文档里加一张商机转化率的月报视图用受理单创建时间关联商机创建时间看两个时间差超过一周才转化的商机大概率是中途被客户比价了。3.3 投诉工单与服务闭环SLA、升级机制、满意度回访投诉工单模块容易被当成客户服务的事而设计得很薄实际上这是电信CRM里数据关系最复杂的模块。一张投诉工单要关联客户、业务实例、受理单、历史缴费记录四个实体。比如用户投诉宽带慢客服要能在工单界面看到这个宽带账号的安装地址、套餐带宽、最近三次缴费记录、是否近期办理过提速。设计文档里要定义工单详情页的数据聚合规则而不是让客服在普通工单表里一条条翻。SLA机制必须有升级链普通投诉24小时响应升级投诉4小时响应重大投诉15分钟响应。超时后工单自动升级到上一级处理人并在升级记录表里留痕。没有自动升级机制的工单系统本质上是张Excel表,靠人盯着群消息才能推进。3.4 经营分析与报表企业客户信息数据统计分析模块的产品化数据统计分析模块是电信CRM设计文档里写起来最爽、做起来最容易烂的部分。烂的原因是无限制地做定制报表。我的建议是报表分三层固定报表、自助分析、专题分析。固定报表是日报周报月报比如新增用户数、离网率、套餐升转降自助分析开放给运营人员自己圈选维度和指标专题分析针对特定场景比如流失预警、异网用户挖掘。流失预警是电信CRM最值得做的分析功能。核心逻辑是打分制根据用户在网时长、最近三个月话费变化、投诉频次、流量使用趋势给每个用户算一个流失风险分。抽样取数SQL可以先想清楚特征字段-- 流失风险特征抽取最近30天话费变化率 流量使用变化率 SELECT a.cust_id, a.bill_amt_this_month, b.bill_amt_last_month, ROUND((a.bill_amt_this_month - b.bill_amt_last_month) / b.bill_amt_last_month, 4) AS amt_change_rate, CASE WHEN a.data_usage_this_month b.data_usage_last_month * 0.5 THEN 1 ELSE 0 END AS data_usage_drop_flag FROM cust_month_bill a JOIN cust_month_bill b ON a.cust_id b.cust_id AND a.stat_month b.stat_month - INTERVAL 1 MONTH;这段SQL直接把本月比上月少用一半流量的用户标记出来加上话费变化率就能进流失预警候选池。amt_change_rate用ROUND保留四位小数是为了后续分位数打分时精度够data_usage_drop_flag这个字段在正式模型里要拆成多个档位不能只有0和1档位太粗会把流量小幅下滑但话费没变的用户误伤。4. 把docx变成可落地的交付物表结构、泳道图与接口边界4.1 核心表结构设计订单表与产品包关系表怎么画设计文档里最能体现工程水平的就是核心表结构。订单表和产品包关系表这两张是我评审任何电信CRM设计文档时第一眼会看的。订单表如果只设计成订单头订单项两层还不够必须考虑一个订单项被部分退订的场景——比如一个融合套餐里的副卡要退订但主套餐还在。所以订单项上要加拆单状态允许一个订单项拆成多个子项每个子项独立维护生命周期状态。-- 订单项表支持部分退订和拆单 CREATE TABLE ord_item ( item_id VARCHAR(40) PRIMARY KEY, order_id VARCHAR(40) COMMENT 受理单头ID, parent_item_id VARCHAR(40) COMMENT 父订单项ID拆单时使用, cust_id VARCHAR(32) COMMENT 客户ID, acct_id VARCHAR(32) COMMENT 账户ID, product_inst_id VARCHAR(32) COMMENT 产品实例ID关联实际业务, item_status TINYINT COMMENT 1-订购中 2-已生效 3-已拆单 4-已退订, begin_time DATETIME COMMENT 生效时间, end_time DATETIME COMMENT 失效时间, oper_emp_id VARCHAR(16) COMMENT 受理工号, oper_channel VARCHAR(16) COMMENT 受理渠道 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段DDL里parent_item_id是关键。没有这个字段拆单业务只能硬删原记录再插新记录审计追溯全断。product_inst_id字段关联的是产品实例而不是产品定义因为一个客户可能订了同一款套餐两次分属不同业务实例。字段注释里补齐了状态值枚举开发建表时不至于靠猜。4.2 泳道图与时序图设计文档里流程图画到什么程度很多设计文档的流程图停留在方框箭头的层面评审的时候人人都说看得懂开发做起来全在猜。电信CRM的流程设计至少要到泳道图级别横轴是系统纵轴是时间一个动作不能悬空必须落在某个系统里。给点可操作的硬标准每个影响金额或服务可用性的业务场景都必须画一张时序图标注出请求超时时间、失败重试次数、补偿操作。举个例子用户在线办理停机保号时序图必须画清楚CRM发起停机请求→计费系统按天出账冻结→网络侧关闭服务→CRM收到成功回执→更新产品实例状态。任何一步失败设计文档里要有明确补偿动作是自动重试还是转人工。没有补偿流程的设计文档上线后大概率要靠DBA手工刷库来收拾残局。4.3 与BOSS和计费系统的接口边界哪些功能别做进CRM电信行业的系统边界不清晰是所有CRM改造项目的通病。我在评审时只认一条原则CRM管人和关系BOSS管销售和资源计费管账和钱。CRM里可以查账单但绝不直接生成账单CRM可以发起订购但资费校验必须调BOSS接口。具体到接口设计文档要列接口清单、字段映射、同步频率、异常处理策略。选型上也说一句很多人纠结要不要直接拿微软Dynamics CRM做本地部署省得自研。但在电信这个BSS/OSS生态相对封闭的行业外部产品往往卡在接口适配和私有协议上改造的成本很可能高于自研。线上那些免费CRM和自建系统的区别也在这——免费CRM给你解决了客户登记和跟进提醒但电信业务需要的码号资源、业务实例状态、融合套餐这些领域模型不是普通CRM能覆盖的。设计的重点不是选什么软件而是把电信特有的模型梳理出来封装成服务给前端用。5. 电信CRM设计避坑六条贴着业务拍的踩坑记录5.1 现象一个用户被拆成了三个客户营销下发全乱套一个用户在营业厅办新号时用新身份证登记在线上渠道用老证件号注册又在政企渠道作为联系人出现结果系统里有三个客户ID积分、账单、营销触点各自为政。原因客户主数据没有合并机制CRM、电子渠道、BOSS各自生成客户主记录靠身份证号匹配但证件号本身不一致。解决设计客户主数据合并流程以证件号姓名做候选匹配规则匹配到的记录进入人工审核合并池审核通过后保留一个客户ID其余ID挂已合并标记并保留历史映射表。5.2 现象BOSS系统已停机CRM还显示正常客户被推销了新套餐营业员在CRM里看到客户状态是正常给客户推了升舱套餐结果提交订购时被BOSS拒绝场面很难看。原因CRM从BOSS同步客户状态用的是T1批处理停机这类实时状态变更没走实时接口。解决非核心状态用批处理可以但停机、欠费、黑名单这三个状态必须设计实时同步接口CRM有缓存的话每次订购提交前强制刷新一次状态。5.3 现象营销名单圈选SQL跑四个小时运营人员不敢点执行做高价值客户流失预警名单圈选直接在客户表上按标签和时间维度过滤全国上亿客户量的电信场景下全表扫描必卡。原因没做分桶也没做预聚合。解决客户分群结果落地到人群快照表按人群编码日期存一份数据快照运营人员圈选时只查快照表。快照表每晚定时任务刷新圈选查询从小时级降到秒级。提示设计文档里写查询优化四个字是没用的。至少要有SQL层面的设计说明——哪些查询走索引哪些场景需要用快照表或宽表预聚合任务的调度频次是什么。5.4 现象投诉工单在客服、装维、网优之间踢了五天皮球宽带报障工单客服转给装维装维上门检测发现是小区光交箱故障转给网优网优处理完没回填工单客服又得打电话问客户解决了吗。原因工单没有设超时升级机制也没有处理人回填后需客户确认闭环的必选动作。解决工单流转状态机里增加客户确认环节各环节设置SLA时限超时自动升级到上一级处理人的领导处理结果必须关联满意度回访问卷回访分数低于阈值自动重开工单。5.5 现象历史账单迁移后对不上账用户投诉月结金额有误老系统迁移时只迁了当前余额和最近三个月账单客户查半年前的详单全是空还有客户6月份的账单金额跟缴费记录对不上。原因迁移方案里漏了账单流水和缴费流水只搬了汇总表。解决迁移前让业务方梳理客户可查数据范围的合规要求一般要求所有历史账单都要可查。迁移话单和账单流水时要支持按来源系统流水号去重不然同一笔缴费在老系统和CRM各记一次余额两边对不上。5.6 现象代理商账号能查到其他代理商的客户资料渠道代理商登录CRM在客户查询里输入号码段能拉出非本渠道发展的客户全量资料。这是一条安全红线电信行业的客户资料泄露是要被追责的。原因权限模型只做了功能权限谁能查没做数据权限能查谁的数据。解决权限体系里增加数据范围概念每个实体上强制校验数据归属维度——代理商只能查自己发展渠道的客户客户经理只能查自己归属网格内的客户设计文档里要把数据权限校验规则写到每个查询接口的说明里。6. 用原型和数据字典把设计文档锁死交付前再抠三道细节6.1 先做高保真原型再回来补设计文档的坑设计文档写完后我会建议团队先用Axure或墨刀把客户360视图、受理工单、投诉处理这三条主流程的界面画出来。画原型的目的不是给客户看UI多美观而是逼着自己把字段和交互状态定义清楚——比如客户状态下拉框里到底有几项选了停机之后哪些按钮要置灰这些细节在设计文档的文字描述里很容易含糊一画原型就暴露。原型走查时重点看异常分支光画正常路径走通的原型等于没画。6.2 数据字典做到字段级评审每个字段都要回答谁在用数据字典不是建表语句的堆砌而是每个字段都要写清楚业务含义、取值来源、更新频度、质量规则。评审的时候我会随机抽核心表的三五个字段问这个字段谁写入、谁读取、为空代表什么。设计文档里字段注释写预留的基本都会被砍掉——预留字段意味着没人用没人用的字段在数据迁移时会变成脏数据源头。这份数据字典直接作为后续开发建表的依据也作为数据仓库建模的元数据基础。6.3 电信CRM设计文档的五道评审关第一道关是客户主数据客户ID是否全局唯一且不可复用客户合并流程是否可用。第二道关是产品模型产品包和产品实例是否分层资费变更是否影响存量实例。第三道关是订单状态机每个状态都有超时约定每个失败都有补偿动作。第四道关是接口边界CRM和BOSS、计费、网络激活系统的接口清单是否完整异常码定义是否统一。第五道关是数据安全数据权限模型是否覆盖所有查询入口操作日志是否留痕。走到这一轮设计文档基本可以交给开发开工了。我自己的习惯是评审完后让开发同学把核心表DDL先落地建出来用真实数据量跑一次读写压测很多设计问题在压测阶段就会提前暴露而不是等到联调才炸。做电信CRM这块文档写得糙不糙最终都在上线后的报表对不上数和工单积压上见分晓。希望这份思路能帮你在动手写那一份docx之前先把最容易返工的模型想清楚少走我走过的弯路。本文还有配套的精品资源点击获取 电信CRM设计实战：四层业务模型与核心表结构拆解
简介这是一份面向电信行业CRM项目规划者、产品经理、系统分析师及高校相关专业学生的设计方案文档以中国电信为背景系统梳理客户关系管理系统的建设动因、核心设计要素与实施路径。文档从“以客户为中心”出发覆盖客户需求分析、客户分类与细分、个性化服务、决策支持等关键模块并结合九七工程遗留问题剖析现有客户信息资源利用不足、部门协作不畅、客户流失缺乏管控等痛点给出原型法式自上而下、分阶段推进的落地建议也明确了从管理层提出建设性要求、循环迭代完善系统的具体做法。压缩包内为1个docx文档整体264KB内容密度高、结构完整。已有328人学习下载适合需要快速建立CRM系统整体认知、撰写设计方案或进行电信业务信息化研究的人员使用。1. 中国电信CRM设计系统一份docx文档背后要扛起的业务与改造在电信营业厅或者呼叫中心待过的人都有一个共同体验查一个客户的资料要在BOSS系统、计费系统、电子渠道后台之间来回切换客户在系统A里是停机状态在系统B里却还能正常订购套餐。所谓中国电信客户关系管理(CRM)设计系统就是把你手头这份以docx形式存在的设计文档从画几张用例图、写几段需求描述推进到能指导开发的完整设计方案。它要回答的不是CRM是什么而是电信业务里客户、产品、订单、账务这四层数据怎么建模功能模块怎么拆跟BOSS和计费系统的边界画在哪。这份文档适合正在做毕业设计的学生、接电信行业CRM改造项目的乙方团队以及企业内部要重构旧CRM的产品经理——照着它把业务模型立住后面开发才不会翻车。2. 先把业务模型立住电信CRM的客户、产品、订单、账务四层关系2.1 为什么电信CRM不能照搬快消行业的客户表结构做过零售CRM的人都知道一套用户表订单表商品表就能跑通大多数场景。但电信行业拿这套模型直接套第一轮需求评审就过不去。原因在于电信业务里客户和业务使用者是分离的一个家庭客户户主身份证名下挂了宽带、两部手机、一部固话缴费的是户主用业务的是全家。如果按快消思路把一个手机号当成一个客户那这个家庭就被拆成四个孤岛营销活动和账单对账全乱套。所以电信CRM做客户模型第一条原则就是客户、账户、业务实例三者分离。客户是自然人或法人账户是缴费和账单的载体业务实例是具体的电话号码、宽带账号。一个客户可以拥有多个账户一个账户可以挂多个业务实例。这套模型在电信行业叫三户模型不只在CRM里用BOSS系统也是按这个逻辑建的设计文档第一张ER图必须画清楚这个三角关系。提示评审时先问一句客户表主键是身份证号还是客户ID。用身份证号做主键携号转网和证件变更场景直接卡死。主键必须用自生成的客户ID证件号只做校验条件。2.2 客户360视图从客户主表到四张扩展表的拆分客户360视图是CRM设计文档里最常被提到的概念但多数文档停留在画一个雷达图中间放客户头像的程度。落到数据库层面客户域至少要拆成客户主表、证件信息表、联系信息表、客户等级表四张。主表只放稳定属性联系信息单独拆表是因为一个客户可能有多个手机号、多个地址而且联系人信息变更频繁混在主表里会导致表膨胀和历史追溯困难。-- 客户主表只放稳定属性不存地址和联系方式 CREATE TABLE cust_main ( cust_id VARCHAR(32) PRIMARY KEY COMMENT 客户ID全局唯一不随证件变更, cust_name VARCHAR(64) COMMENT 客户姓名或单位名称, cust_type TINYINT COMMENT 1-个人 2-家庭 3-政企, cert_type TINYINT COMMENT 证件类型1-身份证 2-护照 3-营业执照, cert_no VARCHAR(32) COMMENT 证件号码只做查询条件不做主键, emp_id VARCHAR(16) COMMENT 归属客户经理工号, channel_code VARCHAR(16) COMMENT 注册渠道编码, create_time DATETIME, update_time DATETIME, KEY idx_cert (cert_type, cert_no), KEY idx_emp (emp_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段DDL里最重要的一条设计是cert_no不设唯一索引。真实业务里一个证件号可能对应多个客户ID——历史数据清洗不干净、政企客户多级联系人持有同一证件的情况都有唯一索引一加数据同步直接报错。cust_type字段要预留即使第一期只做个人客户也要预埋家庭和政企的类型值不然第二期改造表结构成本极高。2.3 电信产品是组合套餐不是商品产品域这样建模快消行业的商品表一条记录一个SKU电信行业要是这么干一个5G融合套餐就够你建二十条SKU。电信产品的核心特征是包装一个销售品比如159元融合套餐内部包含了流量包、语音包、宽带、副卡权益、视频会员多个子项每个子项还可能叠加促销优惠比如首年打七折。产品域建模我用三层结构产品目录层、销售品层、产品实例层。产品目录是静态的资费定义销售品是面向渠道和客户的可售单元产品实例是客户实际订购后生成的记录要关联到具体的业务实例手机号、宽带账号。这样设计的直接好处是改资费不动客户数据一个销售品下架不影响已订购客户的实例有效性。设计文档里产品域至少要覆盖两个状态机销售品生命周期设计中→可售→在售→下架和产品实例生命周期订购→生效→变更→退订。很多设计文档漏了后者开发同学只能自己拍脑袋定义状态后期做订单追溯的时候状态值对不上是常事。2.4 订单与账务受理单状态机和与计费系统的对账边界订单域在电信CRM里叫受理单跟电商订单差别很大。一个电商订单就买一件商品一个电信受理单可能同时包含新装宽带、办副卡、换套餐三个动作每个动作在后台对应独立的订单项分别走不同的激活流程。设计文档里受理单要拆受理单头和受理单项两级订单项状态机独立流转。账务是电信CRM最容易踩坑的域。我的建议是CRM不做账务计算只做账单展示和缴费记录同步。出账、优惠计算、滞纳金生成都是计费系统的职责CRM通过接口把账单和缴费流水同步过来存到查询用表里。这样划分的依据是电信行业的系统职责边界——计费系统是算账的CRM是看账的硬要在CRM里做账务计算月底出账高峰那几天CRM的数据库IO会被查询拖垮。3. 功能模块落成设计文档从客户管理到经营分析怎么拆分3.1 客户信息管理与客户分群标签体系和客户等级怎么落地客户信息管理模块不只是增删改查。电信客户分群要支撑后续营销活动所以在客户主表之上还要建一张客户标签表。标签分两类事实标签和计算标签。事实标签是明确属性比如政企客户宽带用户5G套餐用户计算标签是靠规则算出来的比如高流失风险客户高价值客户。设计文档里要写明每个标签的口径定义否则同一个客户在三个报表里三个状态。客户等级建议用一张独立等级表不要写死在客户主表的字段里。等级是会被调整的——大客户经理申请把某政企客户从普通升到VIP审批通过后更新等级表。等级表的生效时间和失效时间两个字段必须有不然历史等级追溯做不了。-- 客户标签表一个客户多条记录标签类型区分事实/计算 CREATE TABLE cust_tag ( cust_id VARCHAR(32) NOT NULL, tag_code VARCHAR(32) NOT NULL COMMENT 标签编码, tag_type TINYINT COMMENT 0-事实标签 1-计算标签, tag_value VARCHAR(64) COMMENT 标签值如流失风险高, source_sys VARCHAR(16) COMMENT 来源系统CRM/BOSS/数据仓库, tag_eff_dt DATE COMMENT 生效日期, tag_exp_dt DATE COMMENT 失效日期, PRIMARY KEY (cust_id, tag_code, tag_eff_dt) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;标签表设计成按tag_code和tag_eff_dt做联合主键就是允许客户在一个时间段内因规则调整被重新打标签旧记录保留、新记录插入。很多团队把标签做成覆盖式更新跑完当天批量任务历史就没了后面做流失分析根本拉不出上个月这批客户到底是什么状态。3.2 产品订购与受理工单订单生命周期必须画到泳道级产品订购模块是电信CRM的核心交易入口。设计文档里这个模块的灵魂是受理流程的泳道图——不是画一个从选择套餐到确认订单的线性箭头而是要画出CRM、计费系统、网络激活系统、施工调度系统四个参与方各自的动作。常见的翻车点是CRM提交订单后计费系统已经生效了但网络激活系统失败了这时候订单状态应该回退还是置为半生效行业内的一致做法是引入预受理状态订单先不生效,等所有下游系统返回成功才置为已竣工任何一个失败都走人工介入。订单状态至少要有这七个待受理、受理中、已生效、已竣工、退订中、已退订、失败。要给每个状态定义超时时间比如受理中超过两小时未竣工自动告警。很多二次开发的CRM项目把状态砍到四个上线后工单积压在处理中没人发现就是少了超时机制这一层。销售系统与受理工单的联动也在这个模块实现——渠道经理录入一个商机转化为受理单后自动挂到对应客户名下商机的预计金额、签约概率这些字段能反过来帮销售跟踪丢单原因。我一般建议设计文档里加一张商机转化率的月报视图用受理单创建时间关联商机创建时间看两个时间差超过一周才转化的商机大概率是中途被客户比价了。3.3 投诉工单与服务闭环SLA、升级机制、满意度回访投诉工单模块容易被当成客户服务的事而设计得很薄实际上这是电信CRM里数据关系最复杂的模块。一张投诉工单要关联客户、业务实例、受理单、历史缴费记录四个实体。比如用户投诉宽带慢客服要能在工单界面看到这个宽带账号的安装地址、套餐带宽、最近三次缴费记录、是否近期办理过提速。设计文档里要定义工单详情页的数据聚合规则而不是让客服在普通工单表里一条条翻。SLA机制必须有升级链普通投诉24小时响应升级投诉4小时响应重大投诉15分钟响应。超时后工单自动升级到上一级处理人并在升级记录表里留痕。没有自动升级机制的工单系统本质上是张Excel表,靠人盯着群消息才能推进。3.4 经营分析与报表企业客户信息数据统计分析模块的产品化数据统计分析模块是电信CRM设计文档里写起来最爽、做起来最容易烂的部分。烂的原因是无限制地做定制报表。我的建议是报表分三层固定报表、自助分析、专题分析。固定报表是日报周报月报比如新增用户数、离网率、套餐升转降自助分析开放给运营人员自己圈选维度和指标专题分析针对特定场景比如流失预警、异网用户挖掘。流失预警是电信CRM最值得做的分析功能。核心逻辑是打分制根据用户在网时长、最近三个月话费变化、投诉频次、流量使用趋势给每个用户算一个流失风险分。抽样取数SQL可以先想清楚特征字段-- 流失风险特征抽取最近30天话费变化率 流量使用变化率 SELECT a.cust_id, a.bill_amt_this_month, b.bill_amt_last_month, ROUND((a.bill_amt_this_month - b.bill_amt_last_month) / b.bill_amt_last_month, 4) AS amt_change_rate, CASE WHEN a.data_usage_this_month b.data_usage_last_month * 0.5 THEN 1 ELSE 0 END AS data_usage_drop_flag FROM cust_month_bill a JOIN cust_month_bill b ON a.cust_id b.cust_id AND a.stat_month b.stat_month - INTERVAL 1 MONTH;这段SQL直接把本月比上月少用一半流量的用户标记出来加上话费变化率就能进流失预警候选池。amt_change_rate用ROUND保留四位小数是为了后续分位数打分时精度够data_usage_drop_flag这个字段在正式模型里要拆成多个档位不能只有0和1档位太粗会把流量小幅下滑但话费没变的用户误伤。4. 把docx变成可落地的交付物表结构、泳道图与接口边界4.1 核心表结构设计订单表与产品包关系表怎么画设计文档里最能体现工程水平的就是核心表结构。订单表和产品包关系表这两张是我评审任何电信CRM设计文档时第一眼会看的。订单表如果只设计成订单头订单项两层还不够必须考虑一个订单项被部分退订的场景——比如一个融合套餐里的副卡要退订但主套餐还在。所以订单项上要加拆单状态允许一个订单项拆成多个子项每个子项独立维护生命周期状态。-- 订单项表支持部分退订和拆单 CREATE TABLE ord_item ( item_id VARCHAR(40) PRIMARY KEY, order_id VARCHAR(40) COMMENT 受理单头ID, parent_item_id VARCHAR(40) COMMENT 父订单项ID拆单时使用, cust_id VARCHAR(32) COMMENT 客户ID, acct_id VARCHAR(32) COMMENT 账户ID, product_inst_id VARCHAR(32) COMMENT 产品实例ID关联实际业务, item_status TINYINT COMMENT 1-订购中 2-已生效 3-已拆单 4-已退订, begin_time DATETIME COMMENT 生效时间, end_time DATETIME COMMENT 失效时间, oper_emp_id VARCHAR(16) COMMENT 受理工号, oper_channel VARCHAR(16) COMMENT 受理渠道 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段DDL里parent_item_id是关键。没有这个字段拆单业务只能硬删原记录再插新记录审计追溯全断。product_inst_id字段关联的是产品实例而不是产品定义因为一个客户可能订了同一款套餐两次分属不同业务实例。字段注释里补齐了状态值枚举开发建表时不至于靠猜。4.2 泳道图与时序图设计文档里流程图画到什么程度很多设计文档的流程图停留在方框箭头的层面评审的时候人人都说看得懂开发做起来全在猜。电信CRM的流程设计至少要到泳道图级别横轴是系统纵轴是时间一个动作不能悬空必须落在某个系统里。给点可操作的硬标准每个影响金额或服务可用性的业务场景都必须画一张时序图标注出请求超时时间、失败重试次数、补偿操作。举个例子用户在线办理停机保号时序图必须画清楚CRM发起停机请求→计费系统按天出账冻结→网络侧关闭服务→CRM收到成功回执→更新产品实例状态。任何一步失败设计文档里要有明确补偿动作是自动重试还是转人工。没有补偿流程的设计文档上线后大概率要靠DBA手工刷库来收拾残局。4.3 与BOSS和计费系统的接口边界哪些功能别做进CRM电信行业的系统边界不清晰是所有CRM改造项目的通病。我在评审时只认一条原则CRM管人和关系BOSS管销售和资源计费管账和钱。CRM里可以查账单但绝不直接生成账单CRM可以发起订购但资费校验必须调BOSS接口。具体到接口设计文档要列接口清单、字段映射、同步频率、异常处理策略。选型上也说一句很多人纠结要不要直接拿微软Dynamics CRM做本地部署省得自研。但在电信这个BSS/OSS生态相对封闭的行业外部产品往往卡在接口适配和私有协议上改造的成本很可能高于自研。线上那些免费CRM和自建系统的区别也在这——免费CRM给你解决了客户登记和跟进提醒但电信业务需要的码号资源、业务实例状态、融合套餐这些领域模型不是普通CRM能覆盖的。设计的重点不是选什么软件而是把电信特有的模型梳理出来封装成服务给前端用。5. 电信CRM设计避坑六条贴着业务拍的踩坑记录5.1 现象一个用户被拆成了三个客户营销下发全乱套一个用户在营业厅办新号时用新身份证登记在线上渠道用老证件号注册又在政企渠道作为联系人出现结果系统里有三个客户ID积分、账单、营销触点各自为政。原因客户主数据没有合并机制CRM、电子渠道、BOSS各自生成客户主记录靠身份证号匹配但证件号本身不一致。解决设计客户主数据合并流程以证件号姓名做候选匹配规则匹配到的记录进入人工审核合并池审核通过后保留一个客户ID其余ID挂已合并标记并保留历史映射表。5.2 现象BOSS系统已停机CRM还显示正常客户被推销了新套餐营业员在CRM里看到客户状态是正常给客户推了升舱套餐结果提交订购时被BOSS拒绝场面很难看。原因CRM从BOSS同步客户状态用的是T1批处理停机这类实时状态变更没走实时接口。解决非核心状态用批处理可以但停机、欠费、黑名单这三个状态必须设计实时同步接口CRM有缓存的话每次订购提交前强制刷新一次状态。5.3 现象营销名单圈选SQL跑四个小时运营人员不敢点执行做高价值客户流失预警名单圈选直接在客户表上按标签和时间维度过滤全国上亿客户量的电信场景下全表扫描必卡。原因没做分桶也没做预聚合。解决客户分群结果落地到人群快照表按人群编码日期存一份数据快照运营人员圈选时只查快照表。快照表每晚定时任务刷新圈选查询从小时级降到秒级。提示设计文档里写查询优化四个字是没用的。至少要有SQL层面的设计说明——哪些查询走索引哪些场景需要用快照表或宽表预聚合任务的调度频次是什么。5.4 现象投诉工单在客服、装维、网优之间踢了五天皮球宽带报障工单客服转给装维装维上门检测发现是小区光交箱故障转给网优网优处理完没回填工单客服又得打电话问客户解决了吗。原因工单没有设超时升级机制也没有处理人回填后需客户确认闭环的必选动作。解决工单流转状态机里增加客户确认环节各环节设置SLA时限超时自动升级到上一级处理人的领导处理结果必须关联满意度回访问卷回访分数低于阈值自动重开工单。5.5 现象历史账单迁移后对不上账用户投诉月结金额有误老系统迁移时只迁了当前余额和最近三个月账单客户查半年前的详单全是空还有客户6月份的账单金额跟缴费记录对不上。原因迁移方案里漏了账单流水和缴费流水只搬了汇总表。解决迁移前让业务方梳理客户可查数据范围的合规要求一般要求所有历史账单都要可查。迁移话单和账单流水时要支持按来源系统流水号去重不然同一笔缴费在老系统和CRM各记一次余额两边对不上。5.6 现象代理商账号能查到其他代理商的客户资料渠道代理商登录CRM在客户查询里输入号码段能拉出非本渠道发展的客户全量资料。这是一条安全红线电信行业的客户资料泄露是要被追责的。原因权限模型只做了功能权限谁能查没做数据权限能查谁的数据。解决权限体系里增加数据范围概念每个实体上强制校验数据归属维度——代理商只能查自己发展渠道的客户客户经理只能查自己归属网格内的客户设计文档里要把数据权限校验规则写到每个查询接口的说明里。6. 用原型和数据字典把设计文档锁死交付前再抠三道细节6.1 先做高保真原型再回来补设计文档的坑设计文档写完后我会建议团队先用Axure或墨刀把客户360视图、受理工单、投诉处理这三条主流程的界面画出来。画原型的目的不是给客户看UI多美观而是逼着自己把字段和交互状态定义清楚——比如客户状态下拉框里到底有几项选了停机之后哪些按钮要置灰这些细节在设计文档的文字描述里很容易含糊一画原型就暴露。原型走查时重点看异常分支光画正常路径走通的原型等于没画。6.2 数据字典做到字段级评审每个字段都要回答谁在用数据字典不是建表语句的堆砌而是每个字段都要写清楚业务含义、取值来源、更新频度、质量规则。评审的时候我会随机抽核心表的三五个字段问这个字段谁写入、谁读取、为空代表什么。设计文档里字段注释写预留的基本都会被砍掉——预留字段意味着没人用没人用的字段在数据迁移时会变成脏数据源头。这份数据字典直接作为后续开发建表的依据也作为数据仓库建模的元数据基础。6.3 电信CRM设计文档的五道评审关第一道关是客户主数据客户ID是否全局唯一且不可复用客户合并流程是否可用。第二道关是产品模型产品包和产品实例是否分层资费变更是否影响存量实例。第三道关是订单状态机每个状态都有超时约定每个失败都有补偿动作。第四道关是接口边界CRM和BOSS、计费、网络激活系统的接口清单是否完整异常码定义是否统一。第五道关是数据安全数据权限模型是否覆盖所有查询入口操作日志是否留痕。走到这一轮设计文档基本可以交给开发开工了。我自己的习惯是评审完后让开发同学把核心表DDL先落地建出来用真实数据量跑一次读写压测很多设计问题在压测阶段就会提前暴露而不是等到联调才炸。做电信CRM这块文档写得糙不糙最终都在上线后的报表对不上数和工单积压上见分晓。希望这份思路能帮你在动手写那一份docx之前先把最容易返工的模型想清楚少走我走过的弯路。本文还有配套的精品资源点击获取