企业官网建设流程全解析

简介：这是一份面向电信行业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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

标签表设计成按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 '受理渠道' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段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同步客户状态用的是T+1批处理，停机这类实时状态变更没走实时接口。解决：非核心状态用批处理可以，但"停机、欠费、黑名单"这三个状态必须设计实时同步接口，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之前，先把最容易返工的模型想清楚，少走我走过的弯路。

本文还有配套的精品资源，点击获取