工行软件开发中心企微客户运营体系数字化转型之路

作者 | 中国工商银行软开中心

工行数字化运营支撑体系规模庞大，种类繁多，目前已完成了客户、渠道、营销、权益、内容、策略等诸多企业级运营支撑能力中心的建设。渠道（客户触达渠道）作为运营体系的最后一公里，深度影响着客户对工行产品的接受程度。在渠道支撑方面内，聚焦“以客户为中心”，统筹考虑客户与渠道组合费效比，微信生态是首选的客户运营阵地。在微信生态内，企微承担了连接工行与客户个人微信的职责，客户经理使用企微直连客户进行沟通与服务，工行企微触客系统作为 Social CRM 工具赋能客户经理开展微信客户运营工作。

工行企微触客系统专注于服务关系“连得上”、客户关系“留得住”，围绕客户分级识别、标签展示等基层的经营场景，提炼形成备注码、个性欢迎语、定制工作台及分行标签等标准化触客能力，已连接了 1500 万微信客户。系统深度对接企业级运营内容库，融合分行特色素材，按属地特色转发、置顶、轮播热点内容，服务了近 9 万名客户经理开展客户维系工作。打通零售、普惠、结现、卡等垂直业务场景，以普惠小程序、云工作室等媒介触达客户，辅助各场景运营。

产品建设架构痛点与转型思路

在企微触客系统建设初期，以满足业务诉求解决细分场景打通为目标，考虑研发部署简单和代码库易管理因素，将功能集中在单个项目中开发并部署。在客户规模小，数据体量不大，关联上下游较短，数据流扩散路径单一的初期，单体架构只需按 MVC 进行简单分层，即可满足对客户与经理好友关系、员工通讯录等的数据加工与前端渲染工作。

随着客户规模持续膨胀，触客渠道不断增加，智能排班等触客工具不断丰富，员工与机构、客户与员工关系、端内外身份映射等数据维度不断扩展，根据客群筛选经理、对客内容推荐以及人货场的管理等逻辑愈发复杂，经营数据的分布愈发分散。随之而来的模块边界变得模糊、程序复杂度升高、数据规模增大以及数据加工难度增大，导致了原单体架构已无法满足当下业务快速发展要求。同时全行范围内的快速推广，也对系统提出了标准能力开箱即用和特色能力可定制的要求。因此需要对原有架构进行升级。

工行以“云 + 分布式”技术体系，对企微触客系统进行分布式微服务架构转型升级。采用六边形适配器架构进行分层解耦，标准化业务流程，构建单一职责微服务，降低生产运维复杂度的同时，控制问题影响半径，提升系统可扩展性、可维护性。

转型目标

重塑分层解耦的系统架构

基于领域驱动设计方法，搭建客沟通与内容曝光、营销活动组织与任务下发、效果回流统计等的单一职责能力中心，以各能力中心内的核心数据实体模型聚合服务能力，构建纵向有层次、横向能解耦的的系统架构。

打造高可用的租户隔离体系

通过多租户改造，支持分支机构接入后开箱即用，做到一次建设，多地共享。同时基于隔离机制，保障租户间的服务高可用及数据安全性。

建设标准能力基座与扩展特色工具

建设包含 APP 端企微运营辅助工具和开放 API 服务的标准触客能力体系，为工行众多分支机构预留定制功能扩展插槽，在定制属地特色首页与属地特色标签加工使用等方面支持“百行百面”。

转型实施方案

业务架构

企微触客系统的核心是员工企微账户与客户个人微信的好友关系，即与客户的连接，所有运营动作均基于此衍生。通过这个连接通道，各种内容得以推送，各业务条线营销任务得以下达执行。所以我们认为从业务上应用横跨了渠道与营销两个领域。

为此，我们按照工行的领域驱动流程建模思路，识别客户及好友关系、营销任务活动等领域业务实体，设计业务对象服务（BOS）解耦业务逻辑与存储，再按操作者与被操作目标维度重新组合形成业务组件服务（ACS），面向不同的业务场景进一步聚合成业务交易服务（ATS），最终以应用集群与服务及其之间的关联关系呈现 IT 架构。以一个简单围绕客户生命周期的场景为例，该场景大体可分为拉新拓客和存留转化阶段。

拉新拓客：当潜客被纳入某个客户经理或网点账号的微信好友后，即达成了客户与工行客户经理的好友关系（协议），所以需要有一个好友关系管理子系统。

其次，客户经理在运营客户期间，需要知道面对的是谁才能开展精细化经营动作，即打通微信客户与工行，这就要用到 KYC 客户认证子系统。

存留转化：关系达成后，网点经理需要进行关系经营和产品营销，以留住客户和进行转化。因此需要进行活动内容等的转发和推文发送，需要搭建活动组装和素材库子系统。

随后执行批量触达任务的是客户经理等企微用户，其日常工作之一是接收管理端下达的批量触达任务，所以就有了群发任务子系统。

最后需要评估本轮运营动作的费效比，需要有埋点与后评估子系统。

据此进一步细化开展实体建模工作。厘清各上下文边界、核心数据职责和关联关系，以核心实体聚合根与其关联支撑实体呈现系统能力。初步形成了：一、客户协议、微信客户等核心数据；二、人员菜单、营销活动、素材与埋点等通用类数据；三、营销任务、认证客户、会话等支撑类数据。

同时围绕数据能力生长出群发任务、展码、KYC、素材组装与内容库管理、特色标签管理、客户雷达与推荐、合规质检、通讯录与机构管理等诸多微服务，进一步聚合形成客户服务、营销活动、统计分析、公共服务四大能力中心集群。

应用架构

企微触客系统作为工行数字化运营体系中的重要组成部分，需要在企业应用架构中找准自身架构定位，外部基于企业 IT 架构分层原则、内部遵循领域驱动业务建模方法，构建纵向有层次、横向能解耦的应用架构。同时全行范围的推广规划，以及总分行间、各分行间的特色化运营差异大等现状，对系统提出了“多租户”及“标准基座 + 扩展工具”架构要求。据此，我们在以下 4 个方面进行应用架构设计。

1. 应用间边界解耦

工行应用架构蓝图自上而下划分为生态连接服务、业务产品服务、业务基础服务、技术基础服务四层。其中，生态连接服务层聚焦于以用户为中心，为客户提供一点接入、全方位响应、可定制化的一站式一体化服务体验。

企微触客系统作为触客渠道，连接了工行与客户，负责通过微信生态向客户投放产品与金融服务，定位上归属于生态连接服务层。如何开展体系化的客户触达维系、投放差异化的服务，则需要企微系统客户服务集群对接业务产品服务层的运营策略平台负责末端执行，并由营销活动集群对接业务产品服务层不同权益内容生成待投活动，最后基于客群标签进行差异化投放触达。运营策略的后评估调整与客群的精细化挖掘，反过来也需依赖企微渠道供给回流数据，通过大数据加工给出业务基础服务层的企业级共享标签数据服务。如此，通过各层应用协同，实现了一个运营数据飞轮闭环。

2. 应用内纵横划分

如前述，企微触客系统转型前是简单分层的单体架构应用，为做到纵向领域解耦，横向功能分层，在编码落地层面引入业界的 COLA 工具，进行内部子领域模块解耦与部署节点的分层。

3. 分支机构租户隔离

工行拥有众多的分支机构，客户分布范围广，不同地区客户关系数据的访问集中，存在属地特色的内容运营及产品运营需求。在数据与标准能力的统一建设之上，为了满足分支机构接入时开箱即用、机构间特色功能与数据隔离的要求，引入多租户隔离机制。

4. 标准基座与特色工具扩展

针对已具备成熟开发能力的分行，提供对标准能力的扩展机制。在客户经理企微 APP 工作台首页支持灵活配置，支持分行特色应用与外购服务商产品。如在对客沟通标准工具栏上添加分行特色欢迎语库与编辑入口，在好友详情中展示源自分行的本地特色标签信息等。

转型建设成果

通过架构转型，企微触客系统提高了系统可靠性，具备了敏捷开发与高可测性，灵活部署运维，对客场景方案快速组装，和特色场景可扩展的特点。通过开展业务建模工作，也锻炼了研发团队领域驱动思想的学习运用，显著提升了代码可读性使之更优雅。租户隔离体系的落地，也带来了分行开箱即用与故障爆炸半径的有效控制。

未来展望

后续，工行将持续在“连得上”，“配的准”，“留得住”三个方面赋能客户经理，提升客户体验。

“连得上”

• 提效备注。客户经理通过含有备注标签及个性化欢迎语的备注码，进行展码获客。由系统自动化修改客户备注信息等，降低员工工作量。
• 提效识别。丰富客户识别手段，运用除绑卡外的多种认证识别方式，提升客户认证率。
• 提效加新。运用小程序封装客户经理二维码，缩短客户扫码、点击与添加好友流程，提升客户体验。

“配的准”

• 属地化标签。通过对接分行特色回流数据，加工成属地特色标签，并在触客端展现，精准提供属地差异化客户服务。支撑后续产品运营或网点引流工作。

“留得住”

• SOP 标准化流程。将客户经理在客户维系，产品转化上的优质运营步骤流程沉淀为 SOP，并以企微等渠道承接 SOP 触达的最后一公里，提高分行间客户运营经验的推广效率。