项目概览
把分散的客户数据，连接成可持续的客户经营体系
这不是单一报表系统，也不是企微工具，而是一套数据驱动的客户经营产品体系。
项目通过“运营决策—任务路由—客户经营—效果反馈”四个环节，把分散的数据和运营动作连接起来，让数据不仅用于分析，还能够直接产生目标客群、策略和客户级执行任务。
银行并不缺客户、资产和交易数据，难点在于如何把这些数据稳定地转化为可持续运行的客户经营能力。本项目围绕分行数字化运营持续演进：ECOP 负责识别目标客户、经营场景与策略编排；商机平台负责把策略客户清单映射到具体服务人员；企微工作台负责承接任务、客户经营、触达与结果登记；运营报表再把执行、互动和转化反馈回策略优化。
本人不是整体平台 Owner。在资深开发导师带领下，主要从数据产品与运营数据建设切入：重点参与 MOT/Event、生命周期、行为漏斗等场景数据落地；负责或深度参与企微、外呼、策略、管户及客户经营相关报表数据；承担策略运营与“我的客户”相关数据建设，并参与部分需求讨论、表结构设计和后端实现。
以上为平台后续生产运营规模，用于说明产品长期承载能力，不作为本人 2024—2025 建设期的个人独立成果；公开网站建议继续保留模糊化口径。
- 平台累计运营策略*
- 7000+平台后续生产运营规模；不作为本人建设期个人成果。
- 年度触达客户*
- 800万+平台后续生产运营规模；不作为本人建设期个人成果。
- 企微累计客户*
- 270万+平台后续生产运营规模；不作为本人建设期个人成果。
运营决策｜ECOP
识别客户、经营时机与目标客群，定义策略、渠道和运营控制。
- 主要对象
- Customer / Scene / Audience / Strategy
任务路由｜商机平台
把策略客户清单转换为客户级机会，并匹配对应客服/客户经理。
- 主要对象
- Opportunity / Employee
客户经营｜企微工作台
员工执行任务、查看客户上下文、完成企微/外呼并登记结果。
- 主要对象
- Task / Customer / Touch
反馈管理｜报表
观察执行、触达、互动与转化，支持分机构/策略/员工分析。
- 主要对象
- Metric / Report
EIOP 总行平台、ECOP 1.0 已有能力、企微工作台整体架构和主要系统研发属于平台/团队成果；平台后续全部运营策略、触达与转化规模也不归为个人成果。
业务背景与问题定义
真正的问题不是缺数据，而是数据没有被组织成可执行的经营能力
真正的问题不是“缺数据”，而是数据没有被组织成可执行的经营能力。
数据很多，但无法直接形成运营对象
原始客户、资产、交易和行为数据需要被加工成客户池、标签、生命周期、MOT/Event 等经营语义，才能真正进入圈客和策略。
找到客户，不代表能够完成复杂经营
自动策略适合标准化触达；对于需要解释、跟进和服务的客户，需要把策略客群进一步转成商机/任务，落到具体客服或客户经理。
任务已发送，不等于客户真正被经营
系统动作必须拆成执行、实际触达、点击/回复/会话、转化等不同事实，否则报表只能看到“发了多少”，看不到“发生了什么”。
分行会做，不等于基层能够复用
成熟能力要通过策略库、复用审批、分级权限、“我的客户”等机制向支行和一线下沉，同时控制合规、防打扰和数据权限。
项目要建立的能力
项目要建立的能力
这个客户是谁？
客户、资产、产品、管户、企微关系、历史触达
- 数据 / 产品对象
- Customer / Profile
- 最终能力
- 客户、资产、产品、管户、企微关系、历史触达
为什么现在值得经营？
经营时机、事件触发、生命周期与行为漏斗
- 数据 / 产品对象
- Scene / MOT / Event
- 最终能力
- 经营时机、事件触发、生命周期与行为漏斗
这次运营谁？
通过客户池、标签、MOT/Event、白名单形成目标客群
- 数据 / 产品对象
- Audience
- 最终能力
- 通过客户池、标签、MOT/Event、白名单形成目标客群
怎么运营？
周期、节点、渠道、内容、频次与运营控制
- 数据 / 产品对象
- Strategy / Node
- 最终能力
- 周期、节点、渠道、内容、频次与运营控制
谁执行、结果如何？
任务路由、企微执行、互动与转化反馈
- 数据 / 产品对象
- Task / Touch / Conversion
- 最终能力
- 任务路由、企微执行、互动与转化反馈
客户经营要回答五个连续问题：这个客户是谁？为什么现在值得经营？这次运营谁？怎么运营？谁来执行、结果如何？如果这些问题分别落在孤立系统和数据里，就无法形成稳定闭环。
从数据到业务动作：客户经营闭环
数据产品的终点不是报表，而是让数据进入圈客、策略、任务与客户经营
数据产品的终点不是报表，而是让数据进入圈客、策略、任务与客户经营。
端到端数字化运营闭环
业务目标 → 数据识别 → 策略 → 商机/任务 → 客户触达 → 效果反馈
它把“数据判断”和“业务动作”放在同一套对象体系中：Scene/MOT/Event 解决什么时候值得联系；Audience 形成目标客群；Strategy 规定如何运营；Task 把策略落到具体执行者；Touch/Interaction/Conversion 则记录实际结果。数据不再只服务分析，而是在运营决策、员工执行和结果反馈之间循环。
- 它把“数据判断”和“业务动作”放在同一套对象体系中。
- Scene / MOT / Event 解决什么时候值得联系。
- Audience 形成目标客群，Strategy 规定如何运营。
- Task 把策略落到具体执行者；Touch / Interaction / Conversion 记录实际结果。
当前闭环
核心数据链路
从客户识别出发，经过客群、策略与任务，最终回到触达、互动与转化结果。- Customer
- Scene
- Audience
- Strategy
- Task
- Touch
- Interaction
- Conversion
核心能力
- Customer：被经营主体；Scene / MOT / Event 决定联系时机。
- Audience：通过客户池、标签、MOT/Event、白名单形成目标客群。
- Strategy：规定运营周期、节点、渠道、内容与频次。
- Task：把策略落到具体执行者；Touch / Interaction / Conversion 记录实际结果。
关键产品与数据判断
比功能清单更重要的，是为什么使用这些数据对象与产品机制
比功能清单更重要的，是为什么要用这些数据对象和产品机制。
普通标签之外，补充 MOT 与 Event 场景语义
- 业务约束
- 标签更适合回答“客户是什么样的人”，但无法表达“为什么现在值得联系”或“某件事发生后应该做什么”。
- 产品决策
- 在标签基础上建设 MOT（经营时机）与 Event（事件触发），把静态画像升级为可运营的场景语义。
- 选择原因
- 三者共同把静态画像升级为可运营的场景语义，真正支撑圈客与策略。
- 代价与边界
- 需要定义行为口径、时间窗口与排除逻辑，场景体系维护成本上升。
01普通标签之外，补充 MOT 与 Event 场景语义
- 业务约束
- 标签更适合回答“客户是什么样的人”，但无法表达“为什么现在值得联系”或“某件事发生后应该做什么”。
- 产品决策
- 在标签基础上建设 MOT（经营时机）与 Event（事件触发），把静态画像升级为可运营的场景语义。
- 选择原因
- 三者共同把静态画像升级为可运营的场景语义，真正支撑圈客与策略。
- 代价与边界
- 需要定义行为口径、时间窗口与排除逻辑，场景体系维护成本上升。
02Strategy 是可执行运营配置，不是客户名单
- 业务约束
- 若策略只是一张客户名单，就无法控制运营节奏、渠道、频次与合规。
- 产品决策
- Strategy 作为可执行运营配置，包含目标客群、有效周期、节点/事件、渠道与内容、频次、审批、防打扰等控制。
- 选择原因
- 客户清单只是策略运行后的执行事实；配置化才能支撑复用、审批与治理。
- 代价与边界
- 配置复杂度与使用门槛上升，需要分级权限和审批机制支撑。
03ECOP、商机与企微工作台三个环节分工
- 业务约束
- 决策、路由与人工执行对组织关系和系统边界的要求不同。
- 产品决策
- ECOP 负责决策与策略编排；商机平台把“策略客户”转换为“具体员工任务”；企微工作台负责人工经营。
- 选择原因
- 决策、路由和执行分工能更好适配企业组织关系。
- 代价与边界
- 跨系统数据链路更长，需要统一客户、策略、触达和组织关系口径。
04发送量不能代表运营效果
- 业务约束
- 发送只是系统动作，无法体现客户是否真正触达和产生响应。
- 产品决策
- 把执行、实际到达、点击/回复/会话、业务转化分成不同事实层级，建立执行→触达→互动→转化指标层次。
- 选择原因
- 避免把系统执行量误当成业务结果。
- 代价与边界
- 需要更细粒度的明细数据与口径治理，报表复杂度上升。
05策略运营与“我的客户”服务不同运营起点
- 业务约束
- 策略驱动与客户驱动需要不同的产品路径。
- 产品决策
- 策略运营从成熟 Strategy 出发寻找客户（Strategy → Customer）；“我的客户”从管户客户出发主动寻找经营机会（Customer → Action）。
- 选择原因
- 两类能力共用客户和运营数据，但解决的业务任务不同。
- 代价与边界
- 需要同时维护策略配置与客户经营两类对象关系。
06把治理设计进产品，而不是事后附加
- 业务约束
- 真实运营存在权限、审批、防打扰、黑名单、人员变化、服务关系和数据口径等约束。
- 产品决策
- 将权限、审批、防打扰、黑名单、数据口径等治理能力设计进平台机制。
- 选择原因
- 否则“效率提升”会以客户体验、合规和数据一致性为代价。
- 代价与边界
- 治理能力增加产品与数据模型复杂度，但这是规模化运营的前置条件。
产品与系统总体设计
不是按菜单罗列，而是按运营决策—任务路由—客户经营—反馈管理组织平台
不是按菜单罗列，而是按“运营决策—任务路由—客户经营—反馈管理”组织平台。
企业级产品功能架构
业务目标与客群 → 运营决策 → 任务路由 → 执行经营 → 分析管理 → 基础支撑
架构按“运营决策—任务路由—客户经营—反馈管理”组织，覆盖业务目标、运营对象、决策、路由、执行、分析与基础支撑。
- 业务目标与运营对象层：个人客户、对公客户、管户客户、企微客户。
- 运营决策层（ECOP）：客群识别、策略中心、运营控制、审批与治理。
- 任务承接与路由层：客户清单生成、商机任务生成、服务人员映射。
- 执行经营层（企微运营工作台）：任务管理、客户经营视图、触达工具、结果记录。
- 分析与管理层：策略运营、运营报表、管理驾驶舱。
- 基础支撑层：行为数据、企微关系数据、组织/人员/权限数据、数据加工。
运营决策层｜ECOP
运营谁？什么时候？通过什么策略？
- 关键能力
- 客群、MOT/Event、Strategy、渠道/内容、运营控制、审批
任务路由层｜商机
谁来执行？
- 关键能力
- 策略客户清单、服务关系、员工匹配、客户级机会/任务
客户经营层｜企微工作台
员工今天应该做什么？
- 关键能力
- 任务、客户画像、企微/外呼、结果登记、策略运营、“我的客户”
反馈管理层｜报表
做完以后发生了什么？
- 关键能力
- 执行、触达、互动、转化；按策略、机构、员工、客户观察
工作台不能只提供任务列表。员工在触达客户前需要理解客户画像、资产/产品、历史触达和当前策略；执行后又需要记录真实触达与结果。与此同时，分行侧成熟策略还要通过策略库、复用和审批向基层下沉，使平台既支持集中运营，也支持一线主动经营。
数据架构与核心数据产品设计
围绕客户经营链路，定义稳定的数据主题域与核心业务对象
这是项目最能体现个人数据产品能力的章节。
运营数据架构
源数据 → 标准加工 → 规则与识别 → 运营主题域 → 产品应用
数据从源头经过标准加工、规则与识别，进入运营主题域并最终到达圈客、策略、任务和报表等产品应用。
- 客户经营域：Customer、资产、产品、管户、企微关系。
- 场景客群域：客户池、标签、MOT、Event、Audience。
- 策略域与任务触达域：Strategy、Node、Opportunity、Task、Touch。
- 结果分析域与组织权限域：Conversion、指标、Org、Employee、Role。
代表性数据产品案例
三个代表性数据产品案例
MOT / Event 场景数据
MOT 的核心不是“再做一张表”，而是把模糊经营想法变成可计算规则。以“理财浏览未购买”为例，业务先定义场景，数据侧再明确浏览行为、时间窗口、未购买条件和排除逻辑，通过批量作业形成“客户 × 场景 × 日期”记录，并接入 ECOP 作为策略圈客条件。
- 阶段
- 业务语言 → 规则定义 → 数据作业 → 产品接入
- 数据产品价值
- 把业务语言转换为可计算条件，形成可稳定复用的场景数据对象，并作为 Audience 圈客条件。
- 为什么值得展示
- 证明能把业务语言转为可计算规则并接入策略。
企微运营效果分析
运营效果不能只统计“发送量”。企微群发需要从主任务拆到员工子任务和客户明细，再继续连接实际送达、点击、回复/会话和最终转化，才能建立真实漏斗。本人在已有业务数据基础上重点参与指标逻辑、漏斗和报表数据建设。
- 指标层次
- 执行 → 触达 → 互动 → 转化
- 典型指标
- 任务数/执行人数/发送客户数；实际到达客户/触达率；点击/回复/会话/互动率；转化客户/交易/资产变化。
- 为什么值得展示
- 证明能把运营动作转为可观测漏斗，避免把系统执行量误当成业务结果。
策略运营与“我的客户”
策略运营与“我的客户”分别代表两类产品起点：前者从成熟 Strategy 出发，通过策略库、复用和审批找到目标客户；后者从管户 Customer 出发，结合资产、产品渗透、历史触达和企微关系筛选机会并主动经营。两类能力共用客户和运营数据，但解决的业务任务不同。
- 两类起点
- 策略运营：Strategy → Customer；“我的客户”：Customer → Action。
- 数据产品价值
- 共用客户和运营数据，但解决不同业务任务。
- 为什么值得展示
- 证明能把统一客户与策略数据转为一线可直接使用的经营产品。
项目成果、运营规模与个人贡献
平台成果、后续规模与个人贡献分开表达
平台成果、后续规模和个人贡献必须分开表达。
已完成成果
数据进入运营
客户池、标签、MOT/Event、生命周期和行为数据进入圈客，数据不只做分析，直接产生目标客群。
策略进入人工经营
ECOP → 商机 → 企微工作台，把策略客户转化为员工可执行任务。
经营过程可观察
执行 → 触达 → 互动 → 转化，运营效果不再只看发送量。
成熟能力可下沉
策略库、复用审批、“我的客户”、分级权限，让分行能力向支行和一线复用。
真实边界
- EIOP 总行平台整体能力，以及 ECOP 1.0 已有基础能力。
- 企微运营工作台整体产品架构和主要系统研发；资深开发导师及团队承担较多整体开发工作。
- 平台全部运营策略、整体触达与转化规模，以及后续 2026 年平台运营数据。
- 未有充分证据支持的“AI 自动优化”“自动学习策略”“严格增量归因”等能力。
- 平台后续运营规模（7000+ 策略 / 800万+ 触达客户 / 270万+ 企微客户）采用模糊化公开表达，仅用于证明产品长期承载能力；不作为本人建设期个人成果，也不将平台记录的转化直接归因于系统创造的增量收益。
个人核心贡献
运营场景数据
MOT/Event、生命周期、行为/漏斗等数据规则、作业和落地。
- 责任边界
- 数据侧重点参与 / 主责执行
运营效果数据
企微、外呼、策略、管户、客户经营等报表数据整理与建设。
- 责任边界
- 主责工作之一
企微群发分析
基于已有业务数据设计指标逻辑、漏斗与报表数据。
- 责任边界
- 分析 / 报表侧重点负责
策略运营数据
策略报表、复用相关数据、组织权限数据配合。
- 责任边界
- 数据侧主责，产品参与
“我的客户”数据
个人/对公客户、产品渗透、历史触达、管户关系等。
- 责任边界
- 数据侧主责，产品参与
产品与后端
需求讨论、部分功能设计、表结构、部分后端接口/功能实现。
- 责任边界
- 参与
产品证据
产品证据与截图
截图只用于证明产品机制；页面数据与对话内容均为匿名化合成素材。端到端数字化运营闭环
页面说明从经营目标、数据识别、策略配置、任务执行到客户触达与效果反馈的端到端数字化运营闭环图。
用户任务快速理解 ECOP、商机平台、企微工作台与报表如何连接成完整运营链路。
证明机制证明项目不是单一报表或企微工具，而是数据进入业务动作的完整闭环。
企业级产品功能架构
页面说明数字化运营工作台企业级功能架构图，覆盖业务目标与运营对象、运营决策、任务路由、执行经营、分析管理与基础支撑。
用户任务理解 ECOP / 商机 / 企微工作台 / 报表的分工与层次关系。
证明机制证明平台按“运营决策—任务路由—客户经营—反馈管理”组织，而非菜单堆叠。
运营数据架构
页面说明从源数据、标准加工、规则与识别、运营主题域到产品应用的运营数据架构图。
用户任务理解数据如何从源头进入圈客、策略、任务和报表等产品能力。
证明机制证明数据经过标准加工与规则识别后成为运营输入，而非静态存储。
核心业务对象与概念数据模型
页面说明Customer、Scene、Audience、Strategy、Opportunity、Task、Touch、Interaction、Conversion 等核心业务对象与关系模型图。
用户任务理解对象粒度、关系和数据生命周期。
证明机制证明数据建模首先是业务建模，对象与粒度讲清客户经营链路。
MOT / Event 场景数据
页面说明MOT / Event 场景配置与标签管理页面（已提供原始截图）。
用户任务查看业务场景如何被产品化为可圈选的经营语义。
证明机制证明能把业务语言（如“理财浏览未购买”）转为可计算规则并接入策略。
策略配置 / Strategy
页面说明策略配置页面（已提供原始截图）。
用户任务查看客群、时间窗口、渠道、模板与运营控制如何组成策略。
证明机制证明 Strategy 是可执行运营配置而非简单客户名单。
商机 / 企微任务
页面说明“我的任务”页面（已提供原始截图）。
用户任务查看策略客户如何转成员工可执行任务并跟进触达。
证明机制证明任务驱动人工经营闭环，策略落到具体执行者。
客户画像 / 客户经营页
页面说明客户画像与客户经营页（待补）。
用户任务查看员工触达前如何获得资产、产品、历史触达等上下文。
证明机制证明客户经营层提供经营上下文，支撑一线主动经营。
企微群发 / 触达明细
页面说明企微群发与触达明细页（待补）。
用户任务查看任务 → 员工 → 客户 → 点击 / 会话等数据如何沉淀。
证明机制证明执行、触达、互动、转化指标层次建立在明细数据之上。
策略运营
页面说明策略运营页（待补）。
用户任务查看成熟策略如何被复用、审批和向基层下沉。
证明机制证明平台化的核心是能力复用，而非功能堆叠。
“我的客户”
页面说明“我的客户”页（待补）。
用户任务查看从管户客户出发主动筛选和经营的入口。
证明机制证明客户驱动主动经营与策略驱动运营并存。
运营效果报表
页面说明运营效果报表页（待补）。
用户任务查看执行、触达、互动、转化等指标层次。
证明机制证明运营效果不只统计发送量，而是区分系统动作与业务事实。
运营大屏
页面说明运营大屏（待补）。
用户任务查看平台后续生产规模的可视化承载。
证明机制仅作为平台长期承载能力证据，不作为本人建设期个人成果。
项目复盘与能力沉淀
真正的成长不是做过很多报表，而是理解数据怎样进入业务动作
真正的成长不是“做过很多报表”，而是理解数据怎样进入业务动作。
数据产品的终点不是报表，而是业务动作
如果数据只用于展示，价值有限；当 MOT/Audience/Strategy 能改变谁被运营、什么时候运营和采取什么动作，数据才真正进入业务。
数据建模首先是业务建模
Customer、Scene、Strategy、Task、Touch、Conversion 并不是数据库字段分类，而是客户经营链路上不同生命周期的业务对象。
指标必须区分系统动作和业务事实
“已发送”是系统动作，“实际到达、互动、转化”逐步接近真实业务事实。口径设计直接决定运营判断是否可信。
平台化的核心是能力复用，而不是功能堆叠
成熟策略通过策略库、复用审批和权限向基层下沉，才能让分行能力被支行和一线持续复用。
企业级产品必须同时解决效率与治理
权限、审批、防打扰、黑名单、人员调整、服务关系和数据一致性不是附加功能，而是规模化运营的前置条件。
三个真实不足
三个真实不足
业务运营深度有限
科技侧更多承担产品、数据和开发实施，具体策略调优与运营复盘主要由业务团队负责。
- 后续提升方向
- 加强策略复盘、用户分层与运营实验能力。
早期工作偏需求执行
很多工作最初是“业务提需求 → 科技落地”，后续才逐步抽象成稳定产品能力。
- 后续提升方向
- 更早从对象、机制和复用性定义产品问题。
增量归因不足
平台能观察转化，但“发生转化”不等于证明策略创造了全部增量。
- 后续提升方向
- 补强对照组、增量效果、ROI 和归因方法。
这个项目最有价值的不是“做过一个复杂平台”，而是能够把业务场景、数据对象、产品机制和执行反馈连成一套清晰模型，并在真实企业级项目中承担数据规则、表结构、报表、数据开发及部分产品/后端建设。