简介运营商家庭标准化产品库方案PPT系统梳理了运营商家庭业务标准化产品库的建设目标与实施路径适合通信行业产品经理、市场运营及一线装维营销人员阅读。内容覆盖家庭产品现状盘点、七大家庭业务分场景解决方案、标准化产品组合推荐、融合营销套餐设计等模块结合宽带、互联网电视、智能家居、健康服务等具体产品展开能够帮助读者直观理解如何将分散的家庭产品转化为面向不同户型和人群的标准化方案。资源包共1个pptx文件大小341KB目前已有179人学习。通过该方案可掌握从家庭场景细分、产品组合设计到精准推荐和常态化更新的完整思路对运营商构建家庭产品库、优化营销推广流程具有较高的实战参考价值。1. 从单品叠加到场景编排为什么家庭业务要建“产品库在运营商做家庭业务运营的人大多有过这种体会产品清单越来越长一线话术越来越乱。宽带、互联网电视、IMS固话、和目、智能组网、血压计、扫地机器人、智能门锁……营业前台和装维营人员逮到什么推什么最常见的动作还是“宽带融合套餐单品”。真正的问题是缺少一个面向用户的标准化产品体系把“公司有什么”翻译成“用户该买什么”。本文拆解的这套家庭标准化产品库方案解决的就是这个环节用集团、省两级产品库把全网产品和属地创新收口用家庭基础通信、家庭娱乐、亲情沟通、家庭安防、家庭控制、家庭健康、生活服务七大类分场景方案覆盖用户生活场景再靠“必选可选”的融合套餐和户型、人群标签让营业厅和装维现场都能在几分钟内做精准推荐。适合正在做家庭产品目录、营销中台或装维营工具的产品经理和系统架构师参考。2. 产品全量盘点与两级库结构设计先把目录建起来2.1 现状里的三类产品自有基础服务、智能硬件、分省创新家庭产品不是一天攒出来的。方案里先做的是现状盘底把它分成三类目的不是归档而是为了决定后续每种产品按什么方式入库、由谁评审、怎么对接。分类一旦定错后面做字段建模和渠道同步都会返工。第一类是自有产品包括家庭宽带、互联网电视、IMS固话、家庭V网、智能组网、高清视频通话以及咪咕学堂、咪咕爱唱、咪咕视频、和家亲、和家相册等。这类产品的共同点是业务流程完整、计费体系成熟入库时重点补的是场景标签和卖点不需要重新做硬件对接。第二类是已接入或准备接入的智能硬件。方案里给出两种对接方式一种是内嵌或集成 Andlink 协议例如南京物联的 mini 网关、红外感应、水浸、门窗磁、智能门锁、机械手、运营商智能插座、体重计、血压计等另一种是通过云平台对接例如海尔空气净化器、扫地机器人、长虹 zigbee 网关、京东智能插座、小米智能插座和米家台灯。两者的运维成本和数据采集能力差异很大Andlink 方式靠近设备端对配网、控制和本地联动更直接云平台方式依赖第三方接口的稳定性和响应速度入库时还要增加接口 SLA 评估否则设备状态更新延迟会让家庭控制场景体验明显打折。第三类是分省创新产品。像江苏的多屏互动、江西的电视购物“赣鄱优品”、家庭健康包、居家养老应用这些产品在部分省份已经跑出用户规模但缺少一条进入全网的标准通道。家庭标准化产品库要解决的核心问题之一就是让这些省公司创新从“单点试点”变成“全网可复制”而不是每个省各做一套数据标准。2.2 集团和省各管一段两个月评审加月度回传建立标准化产品库的核心不是做一张大表而是定清楚维护节奏。方案采用两级管理集团层面负责调研市场行情、设计新产品服务建立全网标准化产品库收集省公司或专业公司上报的入库申请和标签更新建议每两个月组织一次全网产品评审评审结果通过管理平台和家庭市场发展通报下发到省。省公司层面做四件事在全网产品库基础上建立省内属地化产品库结合宽带 DPI 等数据给产品打用户标签利用装维上门机会采集小区房型、户型信息每个月把省内产品库同步回集团同时提交全网库优化建议包括申请入库产品和标签更新建议。这个节奏决定了产品库是一个双月迭代的运营对象而不是一张静态表格。省公司想申请产品入库需要赶在集团评审前走完内部材料集团每两个月更新一次也意味着新产品从被发现到全网下发最多延迟两个月。产品库管理平台在其中主要承担版本存储、下发记录和反馈收集。下面是一个简化版的产品库核心表结构适合直接落到关系型数据库里作为底座CREATE TABLE dim_family_product ( product_id VARCHAR(32) PRIMARY KEY, product_name VARCHAR(128) NOT NULL, product_type TINYINT COMMENT 1-自有产品 2-智能硬件 3-分省创新, connect_mode VARCHAR(16) COMMENT andlink/cloud/none, category_1st VARCHAR(32) COMMENT 一级分类: 基础通信/娱乐/亲情沟通/安防/控制/健康/生活服务, category_2nd VARCHAR(64), scene_tag VARCHAR(128) COMMENT 适用场景, 如老年关爱、厨卫安全, core_benefit VARCHAR(512) COMMENT 核心卖点, 给一线话术用, price_type VARCHAR(16) COMMENT 终端费/服务费/融合, hardware_list JSON COMMENT 依赖的智能硬件清单, house_type_tag VARCHAR(64) COMMENT 一室/二室/其他, crowd_tag VARCHAR(64) COMMENT 中老年/青年/带小孩家庭, package_bind VARCHAR(128) COMMENT 归属的融合套餐编码, product_status TINYINT COMMENT 0草稿 1在用 2下架, owner_org VARCHAR(32) COMMENT 集团/省编码, effective_date DATE, expire_date DATE ) DEFAULT CHARSETutf8mb4;这块表的重点是product_type和connect_mode分开因为一个分省创新产品也可能走 Andlink 硬件package_bind不是为了替代订单系统而是让产品库知道某个产品被哪些融合套餐引用做下线评估时可以先查引用关系。实际落地时我一般会再加一张product_audit_log记录每次入库、变更的评分和决策人方便回答“这个产品当时为什么能进库”这类溯源问题。2.3 入库评审不是拍脑袋八个维度卡住底线方案给出了相对完整的评审框架重点从“用户规模、产品成熟、产品价格、产品黏性、服务保障”展开再拆成八个可操作的考量维度评审维度考量点用户规模分省销售情况、宽带用户渗透率新开发产品不考核规模产品成熟度是否具有全国复制性是否属于分省特色平台系统支撑现有平台能否支撑全国发展是否需新建平台硬件供应能力全国推广后硬件是否有稳定供应价格竞争力与友商对比、与电商渠道对比商务模式月功能费、增值服务费是否合理产品黏性与家庭宽带的捆绑程度能否降低离网率服务保障全国规模推广后售后支撑体系是否匹配这八个维度在操作时最好转成分数卡而不是文字描述。比如用户规模按渗透率区间给 0-10 分硬件供应按“是否有 3 家以上品牌可替换”给分这样省公司申报材料才有可比性。方案里还提到智能硬件终端要引入不低于 3 个品牌厂家优先采用 Andlink 协议目的就是避免单一供应商导致入库后交付卡住。3. 七大分场景建模与融合套餐编排把“卖产品”改成“卖组合”3.1 为什么按生活场景拆而不是按产品线拆传统渠道卖家庭宽带的历史包袱是“拿到什么产品就推什么”但用户认知是“我想在家看高清视频”“我想随时看到老人安全”。同一个用户可能同时需要宽带、和目摄像头、门窗磁、血压仪把这些拆成不同产品让营业员逐个推销既低效又不专业。方案给出的解法是先把家庭业务分成七大分场景解决方案家庭基础通信、家庭娱乐、亲情沟通、家庭安防、家庭控制、家庭健康、生活服务再往每个场景里填产品。具体映射关系如下场景解决的用户问题典型产品与硬件基础通信上网、固话、家庭内通话家庭宽带、IMS固话、家庭V网、智能组网家庭娱乐看电视、点播、游戏、教育互联网电视基础服务、咪咕视频/游戏/爱唱/学堂亲情沟通与父母、子女视频共享照片高清视频通话、和家亲、和家相册家庭安防看家、防入侵、防燃气泄漏和目、门窗磁、智能门锁、燃气传感器、水浸传感器、电动机械手家庭控制远程开关、场景联动智能开关、智能插座、红外转发器家庭健康测血压、血糖健身管理血压计、血氧计、体重体脂秤生活服务缴费、就医、社区通知新闻资讯、生活缴费、预约挂号、公共信息这里的核心不是每个场景覆盖多少产品而是给一线一套“提问路径”先判断客户家最关心什么问题再打开对应场景页面找产品。这样即使新产品不断进入产品库也不会打乱推荐逻辑。省公司在做属地化时也不需要改七大场景框架只需要在对应场景下增删产品这保证了一张菜单全国通用、各地加菜。3.2 用“必选可选”定义融合套餐 Schema有了场景以后下一步是把场景转成营销套餐。方案里设计了家庭尊享套餐和家庭基础套餐下面再拆出欢乐包、安全包、温馨包、舒适包、健康包、智慧包。套餐结构是统一的每个包有必选服务也有可选服务可选服务再根据用户人群和房型做推荐。这套结构可以用 JSON Schema 描述既方便产品库管理平台存储也方便营业前台和装维 APP 渲染。下面是一个简化版{ package_code: happy_package, package_name: 欢乐包, scene: [基础通信, 家庭娱乐, 亲情沟通], base_services: [family_broadband, ims_fixed_phone], optional_services: { family_vnet: {crowd_tags: [中老年, 青年, 带小孩家庭], house_type_tags: [一室, 二室, 其他]}, wifi_mesh: {house_type_tags: [二室, 其他], remark: 视房型推荐}, migu_video: {crowd_tags: [青年, 带小孩家庭]}, hi_home_album: {crowd_tags: [中老年], remark: 面向与非同住子女分享照片场景} }, entrance: [magic_box, hi_home_app], selling_point: 极光宽带、欢乐家 }这个配置的作用是让套餐规则可下发、可校验。base_services是签约时必选的决定套餐门槛optional_services是推荐位前台的规则引擎根据当前用户标签过滤可选列表而不是把一个套餐里所有可选服务全部展示。比如青年用户看欢乐包时只看到咪咕视频、智能组网不会看到和家相册这类中老年向推荐带小孩家庭则会看到和家亲、视频监控、幼儿健康服务。如果产品库没有结构化这一步基本只能靠人工写营销手册运营数据也回不来。所以融合套餐在设计时就应该和产品库共用一个产品编码避免营销系统和产品目录各维护一套名称。这个编码冲突实际上是很多省级项目上线后才发现的老大难问题早建字段早省事。3.3 户型与人群标签参与推荐规则引擎怎么落地方案里给了一个非常具体的分层推荐逻辑。户型维度分三档一室小户型以七大解决方案中的基础服务为主例如宽带、IMS固话、家庭V网、智能组网基础服务、互联网电视基础服务、和目、和家亲/和家相册二室在一室基础上增加智能组网尊享服务、魔百和增值服务、家庭安防服务、厨卫安全服务其他户型在二室标准组合上按房间数、房屋面积叠加产品。人群维度更细中老年人重点需求是通信、电视、与子女视频、子女远程看护、煤气泄漏等危险监测、健康监测推荐宽带、IMS固话、家庭V网、互联网电视、高清视频通话、视频监控、家庭安防、厨卫安全、中老年健康、预约挂号青年用户重点看 WiFi 覆盖、煲电话、大屏娱乐、与父母视频、安防监控、健身健康、便民生活推荐宽带、智能组网、家庭V网、互联网电视及娱乐增值、和家亲、和家相册、家庭安防、健康健身、新闻资讯、生活缴费带小孩家庭则更关注 WiFi 覆盖、大屏娱乐、关爱子女、家庭安防、健康保障推荐宽带、智能组网、IMS固话、家庭V网、电视娱乐增值、和家亲、视频监控、安防、幼儿/儿童健康、保险理财。落到工程上可以做成一个轻量规则函数def recommend_products(user_tags, house_type, product_library): recs [] for pid, p in product_library.items(): if house_type not in p[house_type_tags]: continue if not (set(user_tags) set(p[crowd_tags])): continue recs.append(pid) return group_by_scene_and_top_n(recs, n2)这里的关键是提前把“人群重点需求分析”变成一组标签而不是自然语言描述。比如“子女关爱老人在家情况”对应标签care_for_elderly它直接映射到和目、门窗磁、燃气传感器营业前台拿到这个标签后推荐列表会自动出现相关产品。方案里提到要“结合大数据分析制定和迭代优化各产品重点推广的用户群体、用户房型标签”说明这个映射关系要持续调整而不是上线后就固定不变。4. 平台化落地与渠道协同从集团下发到装维现场回流4.1 管理平台要管的不只是目录还有版本家庭标准化产品库管理平台是这套体系的“发件箱”。集团每两个月把更新后的产品库通过平台下发到省平台不仅要记录每个版本的生效时间还要能回答“某个产品是什么时候进入某省库的”“某个套餐在哪个渠道版本下可用”。我建议至少包含三个功能域产品库管理支持产品新增、变更、停售和下架套餐管理维护融合套餐与产品的关联关系渠道同步管理记录每个渠道的拉取时间、拉取版本并支持灰度下发。方案里提到的“家庭市场发展通报”可以理解成平台上的一个运营报表模块每次评审后自动生成变更摘要分发给省级接口人和一线培训群。4.2 与营业厅、装维营的同步机制方案里的时间线是8 月底集团完成首次家庭标准化产品库下发9 月底各省完成省内产品库、融合套餐和渠道方案10 月底完成培训并在至少一个地市试点。这里有一个常见坑省公司光建库不接渠道产品库只躺在管理平台上营业员根本不知道。所以方案明确要求“制定与营业厅渠道、装维营渠道定期同步产品库的流程及机制”。常见做法是在渠道营销系统里挂一个拉取任务curl -X GET https://family-product-mng.example.com/openapi/v1/products?provincejsversion20250930 \ -H Authorization: Bearer channel_token \ -o /data/sync/family_products_20250930.json python3 /opt/scripts/load_product_lib.py \ --env prod \ --product-file /data/sync/family_products_20250930.json \ --sync-type incremental命令里的province参数很关键它让省公司只拉取本省生效的产品避免把集团库全量灌到省侧营销系统造成误推广。sync-type是增量更新配合产品库里的expire_date做下架处理。真正上线时我一般会在加载脚本里额外落一张sync_record表记录每个文件包的哈希防止半包数据污染线上配置。如果某个营业厅终端没有拉库它的产品列表就会停留在上一版新版套餐自然卖不出去所以渠道同步必须带校验和重试机制。4.3 装维人员采集户型回填用户标签方案里有一个容易被低估的点代维装维人员上门服务时注重搜集用户所在小区的房型、户型信息方便同小区其他用户开户时第一时间做产品推荐。这是运营商特有的数据优势因为装维工单里有地址、楼栋、房间号而宽带账号天然关联到用户。具体做法是把装维工单里的房屋信息同步到用户标签表UPDATE dim_user_tag u JOIN ( SELECT user_id, SUBSTRING_INDEX(install_address, 室, 1) AS house_unit, CASE WHEN install_address LIKE %一室% THEN 一室 WHEN install_address LIKE %二室% THEN 二室 ELSE 其他 END AS house_type, community_id FROM fact_install_order WHERE install_time DATE_SUB(NOW(), INTERVAL 1 DAY) ) o ON u.user_id o.user_id SET u.house_type o.house_type, u.community_id o.community_id WHERE u.broadband_status active;这段 SQL 做了两件事从装维工单表里解析出户型关键词并把小区 ID 回写到用户标签。这里要注意直接按地址关键词判断户型容易误判比如“精装二室一厅”会被 LIKE 命中“二室”但“一室一厅”也可能被短信地址格式干扰。实际项目里最好在装维 APP 上加一个户型下拉字段让装维人员上门时顺手选择而不是事后用地址解析。方案里写的是“搜集”落到工具上就是给装维人员一个三秒钟的选项页这比后期写清洗规则更可靠。4.4 智能硬件商务模式终端费和服务费要分开定价家庭标准化产品库里大量涉及智能硬件比如智能门锁、摄像头、空气净化器。方案明确提出涉及智能硬件终端的产品标准目录价需分为终端费和服务费。终端费可以按购买或租赁计费购买价不可低于终端采购成本租赁模式要考虑折旧和后期翻新成本服务费目录价参考行业服务费标准并给后期促销优惠留空间。这一条是实际商务谈判里最容易拉扯的地方。如果省公司只报一个“含硬件总价”集团无法判断这个价格是不是在用硬件补贴拉低服务费或者反过来服务费定得太高导致一线没有动力。拆开后终端费对标采购成本服务费对标行业标准融合促销再单独申请资源形成可审计的定价链路。方案还要求涉及基础通信服务流量、语音的家庭标准化产品在正式运行前 6 个月需报总部批准这相当于给新商务模式留了红线省公司不能拿基础语音做无限降价。5. 用一致性稽核脚本守住产品库质量产品库运营的典型风险不是“产品不够”而是“产品库和套餐配置脱节”某个产品在目录里停售了套餐还在推荐七大场景里某一个场景没有可推荐产品一线只能看到六大类套餐里的必选产品在产品库中找不到。既然整个方案强调两级管理、每月更新我建议在 CI 或数据同步流水线里挂一个稽核脚本在下发前自动拦住明显错误。下面是我常用的一个校验脚本适合放在渠道拉取任务之后import json from collections import defaultdict def load_library_and_packages(product_file, package_file): with open(product_file, r, encodingutf-8) as f: products json.load(f) with open(package_file, r, encodingutf-8) as f: packages json.load(f) return products, packages def audit(products, packages): errors [] pids {p[product_id] for p in products} scene_map defaultdict(int) for p in products: if not p.get(core_benefit): errors.append(fmissing core_benefit: {p.get(product_id)}) scene_map[p[category_1st]] 1 required_scenes {基础通信, 家庭娱乐, 亲情沟通, 家庭安防, 家庭控制, 家庭健康, 生活服务} for scene in required_scenes: if scene not in scene_map or scene_map[scene] 0: errors.append(fempty scene: {scene}) for pkg in packages: for base in pkg.get(base_services, []): if base not in pids: errors.append(fpackage {pkg[package_code]} base missing {base}) for opt, rule in pkg.get(optional_services, {}).items(): if opt not in pids: errors.append(fpackage {pkg[package_code]} optional missing {opt}) elif not rule.get(crowd_tags) and not rule.get(house_type_tags): errors.append(f{opt} has no recommend condition) return errors if __name__ __main__: products, packages load_library_and_packages(products.json, packages.json) errs audit(products, packages) if errs: raise SystemExit(\n.join(errs)) print(audit passed)这个脚本在每个版产品库更新后运行检查三件事每个产品是否填写核心卖点七大场景是否都有产品可推荐套餐引用的产品是否都存在于产品库且每个可选服务是否配置了人群或户型标签避免出现一个推荐位没有限定条件导致所有用户都看到的情况。实际项目中还可以再扩展校验price_type是否合法校验停售产品是否仍被套餐绑定校验同一个省级库是否存在重复 product_id校验融合套餐的入口字段是否填写了魔百和或和家亲 APP。把这些检查挂在产品库管理平台的发布流水线里脚本返回非 0 时渠道同步任务直接中断省公司看到的状态就是“未发布”而不是带着脏数据去营业厅。这样就能保证两个月一次的更新不至于把渠道端的推荐配置弄乱。本文还有配套的精品资源点击获取