作者 | 中國工商銀行軟開中心
工行數字化運營支撐體系規模龐大，種類繁多，目前已完成了客戶、渠道、營銷、權益、內容、策略等諸多企業級運營支撐能力中心的建設。渠道（客戶觸達渠道）作為運營體系的最後一公里，深度影響著客戶對工行產品的接受程度。在渠道支撐方面內，聚焦「以客戶為中心」，統籌考慮客戶與渠道組合費效比，微信生態是首選的客戶運營陣地。在微信生態內，企微承擔了連接工行與客戶個人微信的職責，客戶經理使用企微直連客戶進行溝通與服務，工行企微觸客系統作為 Social CRM 工具賦能客戶經理開展微信客戶運營工作。
工行企微觸客系統專注於服務關係「連得上」、客戶關係「留得住」，圍繞客戶分級識別、標籤展示等基層的經營場景，提鍊形成備註碼、個性歡迎語、定製工作檯及分行標籤等標準化觸客能力，已連接了 1500 萬微信客戶。系統深度對接企業級運營內容庫，融合分行特色素材，按屬地特色轉發、置頂、輪播熱點內容，服務了近 9 萬名客戶經理開展客戶維繫工作。打通零售、普惠、結現、卡等垂直業務場景，以普惠小程序、雲工作室等媒介觸達客戶，輔助各場景運營。
產品建設架構痛點與轉型思路
在企微觸客系統建設初期，以滿足業務訴求解決細分場景打通為目標，考慮研發部署簡單和代碼庫易管理因素，將功能集中在單個項目中開發並部署。在客戶規模小，數據體量不大，關聯上下游較短，數據流擴散路徑單一的初期，單體架構只需按 MVC 進行簡單分層，即可滿足對客戶與經理好友關係、員工通訊錄等的數據加工與前端渲染工作。
隨著客戶規模持續膨脹，觸客渠道不斷增加，智能排班等觸客工具不斷豐富，員工與機構、客戶與員工關係、端內外身份映射等數據維度不斷擴展，根據客群篩選經理、對客內容推薦以及人貨場的管理等邏輯愈發複雜，經營數據的分布愈發分散。隨之而來的模塊邊界變得模糊、程序複雜度升高、數據規模增大以及數據加工難度增大，導致了原單體架構已無法滿足當下業務快速發展要求。同時全行範圍內的快速推廣，也對系統提出了標準能力開箱即用和特色能力可定製的要求。因此需要對原有架構進行升級。
工行以「雲 + 分布式」技術體系，對企微觸客系統進行分布式微服務架構轉型升級。採用六邊形適配器架構進行分層解耦，標準化業務流程，構建單一職責微服務，降低生產運維複雜度的同時，控制問題影響半徑，提升系統可擴展性、可維護性。
轉型目標
重塑分層解耦的系統架構
基於領域驅動設計方法，搭建客溝通與內容曝光、營銷活動組織與任務下發、效果回流統計等的單一職責能力中心，以各能力中心內的核心數據實體模型聚合服務能力，構建縱向有層次、橫向能解耦的的系統架構。
打造高可用的租戶隔離體系
通過多租戶改造，支持分支機構接入後開箱即用，做到一次建設，多地共享。同時基於隔離機制，保障租戶間的服務高可用及數據安全性。
建設標準能力基座與擴展特色工具
建設包含 APP 端企微運營輔助工具和開放 API 服務的標準觸客能力體系，為工行眾多分支機構預留定製功能擴展插槽，在定製屬地特色首頁與屬地特色標籤加工使用等方面支持「百行百面」。
轉型實施方案
業務架構
企微觸客系統的核心是員工企微帳戶與客戶個人微信的好友關係，即與客戶的連接，所有運營動作均基於此衍生。通過這個連接通道，各種內容得以推送，各業務條線營銷任務得以下達執行。所以我們認為從業務上應用橫跨了渠道與營銷兩個領域。
為此，我們按照工行的領域驅動流程建模思路，識別客戶及好友關係、營銷任務活動等領域業務實體，設計業務對象服務（BOS）解耦業務邏輯與存儲，再按操作者與被操作目標維度重新組合形成業務組件服務（ACS），面向不同的業務場景進一步聚合成業務交易服務（ATS），最終以應用集群與服務及其之間的關聯關係呈現 IT 架構。以一個簡單圍繞客戶生命周期的場景為例，該場景大體可分為拉新拓客和存留轉化階段。
拉新拓客：當潛客被納入某個客戶經理或網點帳號的微信好友後，即達成了客戶與工行客戶經理的好友關係（協議），所以需要有一個好友關係管理子系統。
其次，客戶經理在運營客戶期間，需要知道面對的是誰才能開展精細化經營動作，即打通微信客戶與工行，這就要用到 KYC 客戶認證子系統。
存留轉化：關係達成後，網點經理需要進行關係經營和產品營銷，以留住客戶和進行轉化。因此需要進行活動內容等的轉發和推文發送，需要搭建活動組裝和素材庫子系統。
隨後執行批量觸達任務的是客戶經理等企微用戶，其日常工作之一是接收管理端下達的批量觸達任務，所以就有了群發任務子系統。
最後需要評估本輪運營動作的費效比，需要有埋點與後評估子系統。
據此進一步細化開展實體建模工作。釐清各上下文邊界、核心數據職責和關聯關係，以核心實體聚合根與其關聯支撐實體呈現系統能力。初步形成了：一、客戶協議、微信客戶等核心數據；二、人員菜單、營銷活動、素材與埋點等通用類數據；三、營銷任務、認證客戶、會話等支撐類數據。
同時圍繞數據能力生長出群發任務、展碼、KYC、素材組裝與內容庫管理、特色標籤管理、客戶雷達與推薦、合規質檢、通訊錄與機構管理等諸多微服務，進一步聚合形成客戶服務、營銷活動、統計分析、公共服務四大能力中心集群。
應用架構
企微觸客系統作為工行數字化運營體系中的重要組成部分，需要在企業應用架構中找准自身架構定位，外部基於企業 IT 架構分層原則、內部遵循領域驅動業務建模方法，構建縱向有層次、橫向能解耦的應用架構。同時全行範圍的推廣規劃，以及總分行間、各分行間的特色化運營差異大等現狀，對系統提出了「多租戶」及「標準基座 + 擴展工具」架構要求。據此，我們在以下 4 個方面進行應用架構設計。
1. 應用間邊界解耦
工行應用架構藍圖自上而下劃分為生態連接服務、業務產品服務、業務基礎服務、技術基礎服務四層。其中，生態連接服務層聚焦於以用戶為中心，為客戶提供一點接入、全方位響應、可定製化的一站式一體化服務體驗。
企微觸客系統作為觸客渠道，連接了工行與客戶，負責通過微信生態向客戶投放產品與金融服務，定位上歸屬於生態連接服務層。如何開展體系化的客戶觸達維繫、投放差異化的服務，則需要企微系統客戶服務集群對接業務產品服務層的運營策略平台負責末端執行，並由營銷活動集群對接業務產品服務層不同權益內容生成待投活動，最後基於客群標籤進行差異化投放觸達。運營策略的後評估調整與客群的精細化挖掘，反過來也需依賴企微渠道供給回流數據，通過大數據加工給出業務基礎服務層的企業級共享標籤數據服務。如此，通過各層應用協同，實現了一個運營數據飛輪閉環。
2. 應用內縱橫劃分
如前述，企微觸客系統轉型前是簡單分層的單體架構應用，為做到縱向領域解耦，橫向功能分層，在編碼落地層面引入業界的 COLA 工具，進行內部子領域模塊解耦與部署節點的分層。
3. 分支機構租戶隔離
工行擁有眾多的分支機構，客戶分布範圍廣，不同地區客戶關係數據的訪問集中，存在屬地特色的內容運營及產品運營需求。在數據與標準能力的統一建設之上，為了滿足分支機構接入時開箱即用、機構間特色功能與數據隔離的要求，引入多租戶隔離機制。
4. 標準基座與特色工具擴展
針對已具備成熟開發能力的分行，提供對標準能力的擴展機制。在客戶經理企微 APP 工作檯首頁支持靈活配置，支持分行特色應用與外購服務商產品。如在對客溝通標準工具欄上添加分行特色歡迎語庫與編輯入口，在好友詳情中展示源自分行的本地特色標籤信息等。
轉型建設成果
通過架構轉型，企微觸客系統提高了系統可靠性，具備了敏捷開發與高可測性，靈活部署運維，對客場景方案快速組裝，和特色場景可擴展的特點。通過開展業務建模工作，也鍛鍊了研發團隊領域驅動思想的學習運用，顯著提升了代碼可讀性使之更優雅。租戶隔離體系的落地，也帶來了分行開箱即用與故障爆炸半徑的有效控制。
未來展望
後續，工行將持續在「連得上」，「配的准」，「留得住」三個方面賦能客戶經理，提升客戶體驗。
「連得上」
- 提效備註。客戶經理通過含有備註標籤及個性化歡迎語的備註碼，進行展碼獲客。由系統自動化修改客戶備註信息等，降低員工工作量。
- 提效識別。豐富客戶識別手段，運用除綁卡外的多種認證識別方式，提升客戶認證率。
- 提效加新。運用小程序封裝客戶經理二維碼，縮短客戶掃碼、點擊與添加好友流程，提升客戶體驗。
「配的准」
- 屬地化標籤。通過對接分行特色回流數據，加工成屬地特色標籤，並在觸客端展現，精準提供屬地差異化客戶服務。支撐後續產品運營或網點引流工作。
「留得住」
- SOP 標準化流程。將客戶經理在客戶維繫，產品轉化上的優質運營步驟流程沉澱為 SOP，並以企微等渠道承接 SOP 觸達的最後一公里，提高分行間客戶運營經驗的推廣效率。
ClickHouse 正在退出開源世界？
棄亞馬遜轉戴爾，徹底下雲、去 K8s 後，我們已經節省了 100 萬美元
高通回應「大規模裁員」「撤離上海」；TikTok 員工吐槽管理層過於年輕；Java 21 正式發布 | Q資訊
取代 Vue 和 React？25 年碼齡程式設計師不滿 Web 現狀創建新框架 Nue JS，能將代碼量減少 10 倍！