微信公眾招商銀行賬號開發的示例分析

這篇文章給大家分享的是有關微信公眾招商銀行賬號開發的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

規劃要超前

大部分企業在規劃時，抱著試試看的態度，投入不足，僅是因為領導說要做微信而做微信，并未做長遠打算，導致淺嘗即止。很多微信公眾賬號只是掛了個鏈接鏈到頁面，做個微網站，沒有深入考慮怎樣通過良好的體驗把企業的服務提供給客戶。一個超前的規劃，首先必須選好平臺——具有穩定合理的架構，足夠的業務靈活性和開放性，可以逐步疊加和發展業務，可以靈活調整體驗，可以對接后端的各種系統資源等。

架構要合理

微信平臺不是一個單純的鏈接入口，它更是連接企業服務與用戶之間的管道。因此微信平臺需要有合理的架構設計，使平臺能在不同的交互模式以及各種形態的服務資源之間靈活地進行切換，并保持良好的體驗。總的來說，微信的交互包括：點擊菜單的輕App體驗、聊天窗口的消息交互、頁面的交互三大類，其中消息交互又包括自動消息交互和人工消息交互。從長遠的規劃看，平臺需要滿足以下要求：

1. 高性能和高可用；

2. 容量的可擴展性；

3. 可監控、可管理；

4. 業務可擴展，可以靈活進行業務變更和加載；

5. 開放性，可由客戶進行業務流程的二次開發，提供標準化的接口與第三方系統進行對接，包括接入多種IM渠道等。

我們很多客戶都已在應用或規劃全渠道接入，可以實現微信、微博、QQ、WebChat、郵件等多種模式。

平臺架構上很多細節的設計，都是來自業務及運營的需求，如下所示。

1. 對并發量的要求，決定了接口設計的模式，采用異步、無狀態、多線程的接口模式，才能滿足超大并發量的處理，并且易于擴展。招行目前每天發出的消費提醒，就達到400萬條，高峰期半個小時可達20多萬條。

2. 對可靠性的要求，決定了緩存的持久化，保證了即使某個節點的程序宕機甚至物理故障，也不會丟失交易數據。我們早期的方案也存在缺陷，在特殊的情況下如果接口程序崩潰或者重啟，就會使發送隊列中的數據丟失。雖然量不大，但對銀行業務卻很重要，會導致用戶的投訴。

3. 數據庫性能對DB交易量的支持，以及對分布式架構的要求，決定了數據庫中間層的存在。一個好的架構，不僅要支持單個數據庫把性能發揮到極致，還要考慮服務器硬件如果出現瓶頸也能進行擴展，因為數據庫由于計算能力、I/O吞吐、存儲等多方面的原因，始終會在某個點達到無法超越的瓶頸，就像12306，當海量的用戶請求在短時間內涌入時，會給系統帶來極大的壓力，整個系統的最后瓶頸往往就是數據庫，解決的辦法就是采用分布式解決方案。云軟IMCC在架構上支持橫向和縱向的擴展，理論上只要網絡帶寬許可，就可支撐無限容量。

4. 通信連接的效率，微信的協議是HTTP雙向POST的協議，采用短連接方式。這種通信方式其實效率是很低，每次請求都需要建立連接、釋放連接。對于單個服務節點，其性能遠低于TCP長連接，協議的字節冗余也比較多，對傳輸帶寬要求較高，但好處在于可以方便地通過多節點進行擴展，開發的難度也較低。隨著計算機性能和網絡帶寬的提高，以前要按字節來節省的傳輸數據量已可被忽略，短連接方式以后會得到廣泛的應用。雖然我們平臺內部的通信采用TCP長連接，在百兆網絡環境下最高可以達到每秒數萬次的消息量，效率高很多，但缺點是對開發的要求比較高，需要處理很多網絡異常事件，也不便于多節點擴展。

招行輕體驗、重后臺的體驗設計

招行在微客服產品上的設計充分體現了“關注用戶體驗，重視服務細節”的用心服務理念。雖然招行在微信平臺上實現了其傳統客服和App上超過70%的業務服務功能，但在用戶體驗上你會覺得很清爽，很多功能你不用的時候都是躲在后面的，展示出來的只是最常用的功能，而一旦你需要，通過簡單直接的操作，就能獲得，正所謂呼之即來，揮之則去，不用的時候絕不占你眼球。比如你對小招說：“境外消費”，小招就能很快找到所對應的答案以及兌換手續費等相關問題。配合招行后來提供的語音識別功能，更是將操作簡化到說到就能做到的程度。這種模式我們稱為平鋪模式，相對以往需要通過多級菜單、多次交互才能找到自己想要的功能，平鋪模式可以做到所想即所得，特別對于微信這樣的移動終端，展示的容量有限、操作輸入不方便的情況下顯得更加方便。

應用了很多跨界的方法來解決問題

在通信行業，流量控制是非常常見的，它可以阻擋系統能力以外的請求，不至于將系統弄垮，用戶可能會得到“系統正忙”之類的提示，但在計算機和互聯網行業，流控的概念還沒有得到廣泛應用。以微信為例，微信自己有提供對外的流控，超過一定頻次就予以拒絕，卻沒有考慮外部系統的流控，當超過系統處理能力的請求涌入時，就只能丟棄，因此提供的是有損服務。對于有損服務，我們就需要采用緩存重發的機制來保障數據的有效送達，對日常聊天還沒太大影響，但對一些要求嚴格的金融服務，就會造成客戶投訴。

再比如我們參考了NGN中業務與承載分離的設計理念，把消息傳輸、會話控制與業務流程引擎分離，分層次的軟件架構設計，不僅是滿足業務靈活度的關鍵，也是進行軟件架構擴展的核心。作為一個千萬級用戶的運營平臺，在追求穩定服務的同時，還要能不斷推出靈活的新業務，而不是每次業務發生變化都要去更新升級軟件，甚至重啟服務才能加載新的業務功能。招行所使用的云軟IMCC平臺，從設計之初就考慮了這點，通過將消息承載與業務流程分離，使基礎平臺變成與業務無關的底層平臺，而各種業務流程則通過流程引擎進行解析，實現業務的動態加載。

招行平臺的業務流程引擎設計工具，也參考了傳統呼叫中心的可視化流程開發方法，將各種常用的流程處理組件封裝，稱為“元件”，使后期進行業務的二次開發效率得以大幅提升，并且降低了對開發人員的技能要求，只要稍有編程基礎的開發人員就可以快速完成業務流程的定義和發布。而且這套引擎不是一個封閉的系統，通過自定義節點，我們可以調用外部系統接口，實現與其他系統的對接，并且可以調用自定義功能，具有很強的靈活性。

專業的多客服體系

招行微信平臺最早的出發點就是建一個基于互聯網渠道的在線客服平臺。因此，在平臺選型時首選已在中國電信集團IM客服上有了沉淀和積累的IMCC平臺，于2010年建設的基于營銷QQ的800010000平臺已經有了5000萬好友，上百臺服務器的集群架構。IMCC有很多針對呼叫中心專業客服而設計的功能，所謂多客服，其實跟電話的呼叫中心很類似，用戶從一個號碼（電話、QQ、微信等）呼入，后臺有一個呼叫中心團隊來處理用戶的聊天請求。因此系統需要有ACD服務器來實現不同的路由及排隊策略，比如先來先服務、平均分配或者按比例分配、上次服務優先、VIP插隊等。另外，呼叫中心團隊要能按技能組進行排隊和路由，比如咨詢的是一組，VIP服務是另一組，還要允許一個工號有多種技能，可以作為不同技能隊列的資源放到資源池排隊。

專業的呼叫中心業務十分密集，在操作效率上要求很高，坐席在操作上要求盡可能減少低效的動作。例如重要消息置頂功能，可以避免重要的聊天信息在窗口滾動中難以查找，還有來話原因采集，只需要在采集樹上簡單點擊，就可以完成。除此之外，為了提高話務員知識檢索的效率，我們設置了在聊天消息中觸發知識庫自動檢索的功能，只要維護得當，從用戶的輸入中就可直接觸發檢索出答案，大大降低了話務員的工作強度。

微信、QQ等個人聊天軟件，都是無狀態的，用戶可以不用管對方是否在線，不計較什么時候回復，但這給專業客服帶來了很大麻煩。例如戶可能發了一句話就走開了，但會話窗口就一直掛在那里，客服每天可能會接入數百個會話，如果一直占用，會使客服無法專注處理，后臺的各種KPI考核也無法進行。因此，專業的人工客服應用場景，一定是有狀態的會話，就像一通電話，有接入有掛斷。但考慮到用戶體驗，我們也在研究是否有可能實現無狀態會話的無縫兼容，即在用戶側感覺是無狀態的，什么時候都可以發消息，但在客服側處理稱為有狀態的，能保證會話效率和質檢考核，這套系統目前還在研發中。

客觀看待智能客服的應用

招行是微信智能機器人最成功的案例，雖然同是IMCC基礎平臺加小艾機器人，電信和聯通在應用時效果卻并不十分理想。原因在于，電信和聯通的業務太過復雜，產品數千種，知識庫數10萬條，問題過于開放。而招行信用卡業務領域相對比較窄，而且投入了大量人力進行人工知識識別和添加，才使得小招招人喜愛。由于技術局限，智能機器人目前存在兩個一直未能解決的問題：1. 自動學習能力；2. 真正的語義理解能力。如果有哪家公司能在這兩方面有所突破，將會給智能機器人應用帶來極為廣闊的前景。

對實際應用而言，我們認為，如果坐席數量沒有到達10人以上，那么應用智能機器人的投入和收益并不匹配，反而不如通過關鍵字應答等簡單方法來。根據我們統計的招行微信數據，用戶70%的操作是菜單操作，25%是5個字以內的短詞，剩下的是與人工客服的對話。新研制的關鍵字匹配方法具備模糊匹配、最長匹配優先、自動分揀未命中等方法，已經可以在很大程度上替代智能機器人。

招行的安全措施

“安全”是金融類微信應用的基本要求，在保障安全性方面，招行采用專線接入的方式，保證了數據不在公網傳輸。最新消息顯示，騰訊已在進行加密協議的研發測試，未來會使銀行的信息安全更有保障。

其他安全方面采取的措施包括：應用HTTPS協議，頁面傳遞參數加密防止中間人攻擊，應用動態密碼鍵盤防止黑客截獲密碼，后臺安全策略等。除此之外，應用安全掃描工具對系統進行模擬攻擊和漏洞掃描，也是必要的工作。

新高級接口應用

【群發的挑戰】

招行已有1300萬粉絲，群發一條消息到全量客戶，將給系統帶來極大的壓力。騰訊的消息下發能力非常強，1000多萬的消息只需要幾個小時就可以全部送達，這些客戶收到消息后必然會作出反應，簡單的有查詢余額、瀏覽頁面，如果是互動式的活動，將會產生致命沖擊，在微信沒有提供高級群發接口之前，招行試過群發，基本上每次都導致系統的阻塞甚至宕機。因此，理想的群發模式，必須是流量可控，可按照目標用戶清單進行精確定位的模式。即包含兩種模式：1. 需要全量通知所有用戶的，根據活動的性質（純告知、互動）；2. 根據客戶群細分結果，按照目標用戶清單進行定時定向發送。

騰訊提供的分組群發高級接口，限制是每天100次，每次1萬條，也就是說每天最多100萬（實際是99萬），無法滿足全量用戶通知的需求，但又不能采用MP后臺進行全量群發，這種情況就需要使用騰訊提供的分組功能，將用戶分成多個批次。我們很多客戶把這個分組功能與客戶群分組搞混了，使用分組功能實現客戶群細分。其實，客戶群細分是經常變動的，不斷通過接口同步騰訊的數據，既不合理也不科學，而應盡可能將客戶群細分的工作放在企業一側的CRM系統，通過客戶標簽的方法維護，才能保證基于CRM的精確營銷得以實施。

【矩陣賬號、分權分域管理和UnionID】

現在很多集團級企業都存在多賬號的管理需求，但是由于微信OpenID只能跟一個公眾賬號對應，導致各個賬號上積累的用戶沒辦法統一管理。UnionID實現了多個賬號之間相同用戶關聯，可以把分散在多個公眾賬號的用戶統一識別、管理，既能體現子賬號的個性化，又能將好友資源集中管理。

雖然招行平臺可以支持多賬號，每個賬號單獨管理，但并非賬號開得越多越好。因為分權分域的管理，如果粒度過細，會給使用和管理帶來過重負擔，開發的工作量也相應加大。對于集團級的矩陣賬號應用，我的建議是：子賬號的粒度最小是城市，更小的粒度，如支行、分店等，建議通過參數二維碼的方式進行客戶渠道的區分識別，在后臺標識出客戶的歸屬，以便后續可以提供針對性的營銷和服務。

感謝各位的閱讀！關于“微信公眾招商銀行賬號開發的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！